Exploit Database
145,273 exploits tracked across all sources.
Mbed TLS < 3.6.4 - Use-After-Free in mbedtls_x509_string_to_names()
Mbed TLS before 3.6.4 allows a use-after-free in certain situations of applications that are developed in accordance with the documentation. The function mbedtls_x509_string_to_names() takes a head argument that is documented as an output argument. The documentation does not suggest that the function will free that pointer; however, the function does call mbedtls_asn1_free_named_data_list() on that argument, which performs a deep free(). As a result, application code that uses this function (relying only on documented behavior) is likely to still hold pointers to the memory blocks that were freed, resulting in a high risk of use-after-free or double-free. In particular, the two sample programs x509/cert_write and x509/cert_req are affected (use-after-free if the san string contains more than one DN).
CVSS 8.9
Spotipy GitHub Actions - pull_request_target Secret Exfiltration
Spotipy is a Python library for the Spotify Web API. As of commit 4f5759dbfb4506c7b6280572a4db1aabc1ac778d, using `pull_request_target` on `.github/workflows/integration_tests.yml` followed by the checking out the head.sha of a forked PR can be exploited by attackers, since untrusted code can be executed having full access to secrets (from the base repo). By exploiting the vulnerability is possible to exfiltrate `GITHUB_TOKEN` and secrets `SPOTIPY_CLIENT_ID`, `SPOTIPY_CLIENT_SECRET`. In particular `GITHUB_TOKEN` which can be used to completely overtake the repo since the token has content write privileges. The `pull_request_target` in GitHub Actions is a major security concern—especially in public repositories—because it executes untrusted code from a PR, but with the context of the base repository, including access to its secrets. Commit 9dfb7177b8d7bb98a5a6014f8e6436812a47576f reverted the change that caused the issue.
CVSS 9.1
OpenPGP.js 5.0.1-5.11.2 & 6.0.0-alpha.0-6.1.0 Signature Verification Spoofing
OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`. When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`.
donetick < 0.1.44 - Unauthenticated Account Takeover via Weak JWT Signing Secret
Donetick an open-source app for managing tasks and chores. Prior to version 0.1.44, the application uses JSON Web Tokens (JWT) for authentication, but the signing secret has a weak default value. While the responsibility is left to the system administrator to change it, this approach is inadequate. The vulnerability is proven by existence of the issue in the live version as well. This issue can result in full account takeover of any user. Version 0.1.44 contains a patch.
CVSS 9.1
quic-go < 0.57.0 - Memory Exhaustion via QPACK-Encoded HEADERS Frame
quic-go is an implementation of the QUIC protocol in Go. Versions 0.56.0 and below are vulnerable to excessive memory allocation through quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an http.Header (used on the http.Request and http.Response, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion. This issue is fixed in version 0.57.0.
CVSS 5.3
quic-go < 0.49.0, 0.54.1 - Unauthenticated Denial of Service via Premature HANDSHAKE_DONE Frame
quic-go is an implementation of the QUIC protocol in Go. In versions prior to 0.49.0, 0.54.1, and 0.55.0, a misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. This was observed in the wild with certain server implementations. quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. Versions 0.49.0, 0.54.1, and 0.55.0 discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames.
CVSS 7.5
quic-go < 0.49.0, 0.54.1 - Unauthenticated Denial of Service via Premature HANDSHAKE_DONE Frame
quic-go is an implementation of the QUIC protocol in Go. In versions prior to 0.49.0, 0.54.1, and 0.55.0, a misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. This was observed in the wild with certain server implementations. quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. Versions 0.49.0, 0.54.1, and 0.55.0 discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames.
CVSS 7.5
CoreDNS < 1.12.2 - Unauthenticated Denial of Service via Unbounded QUIC Stream Goroutines
CoreDNS is a DNS server that chains plugins. In versions prior to 1.12.2, a Denial of Service (DoS) vulnerability exists in the CoreDNS DNS-over-QUIC (DoQ) server implementation. The server previously created a new goroutine for every incoming QUIC stream without imposing any limits on the number of concurrent streams or goroutines. A remote, unauthenticated attacker could open a large number of streams, leading to uncontrolled memory consumption and eventually causing an Out Of Memory (OOM) crash — especially in containerized or memory-constrained environments. The patch in version 1.12.2 introduces two key mitigation mechanisms: `max_streams`, which caps the number of concurrent QUIC streams per connection with a default value of `256`; and `worker_pool_size`, which Introduces a server-wide, bounded worker pool to process incoming streams with a default value of `1024`. This eliminates the 1:1 stream-to-goroutine model and ensures that CoreDNS remains resilient under high concurrency. Some workarounds are available for those who are unable to upgrade. Disable QUIC support by removing or commenting out the `quic://` block in the Corefile, use container runtime resource limits to detect and isolate excessive memory usage, and/or monitor QUIC connection patterns and alert on anomalies.
CVSS 7.5
quic-go 0.50.0 - Denial of Service via Path Probe Packet Handling
quic-go is an implementation of the QUIC protocol in Go. The loss recovery logic for path probe packets that was added in the v0.50.0 release can be used to trigger a nil-pointer dereference by a malicious QUIC client. In order to do so, the attacker first sends valid QUIC packets from different remote addresses (thereby triggering the newly added path validation logic: the server sends path probe packets), and then sending ACKs for packets received from the server specifically crafted to trigger the nil-pointer dereference. v0.50.1 contains a patch that fixes the vulnerability. This release contains a test that generates random sequences of sent packets (both regular and path probe packets), that was used to verify that the patch actually covers all corner cases. No known workarounds are available.
CVSS 7.5
quic-go 0.50.0 - Denial of Service via Path Probe Packet Handling
quic-go is an implementation of the QUIC protocol in Go. The loss recovery logic for path probe packets that was added in the v0.50.0 release can be used to trigger a nil-pointer dereference by a malicious QUIC client. In order to do so, the attacker first sends valid QUIC packets from different remote addresses (thereby triggering the newly added path validation logic: the server sends path probe packets), and then sending ACKs for packets received from the server specifically crafted to trigger the nil-pointer dereference. v0.50.1 contains a patch that fixes the vulnerability. This release contains a test that generates random sequences of sent packets (both regular and path probe packets), that was used to verify that the patch actually covers all corner cases. No known workarounds are available.
CVSS 7.5
quic-go < 0.48.2 - Denial of Service via ICMP Packet Too Large Injection
quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2.
CVSS 6.5
quic-go < 0.48.2 - Denial of Service via ICMP Packet Too Large Injection
quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2.
CVSS 6.5
quic-go < 0.48.2 - Denial of Service via ICMP Packet Too Large Injection
quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2.
CVSS 6.5
quic-go < 0.48.2 - Denial of Service via ICMP Packet Too Large Injection
quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2.
CVSS 6.5
quic-go < 0.42.0 - Denial of Service via NEW_CONNECTION_ID Frame Flood
quic-go is an implementation of the QUIC protocol in Go. Prior to version 0.42.0, an attacker can cause its peer to run out of memory sending a large number of `NEW_CONNECTION_ID` frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a `RETIRE_CONNECTION_ID` frame. The attacker can prevent the receiver from sending out (the vast majority of) these `RETIRE_CONNECTION_ID` frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. Version 0.42.0 contains a patch for the issue. No known workarounds are available.
CVSS 7.5
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
quic-go 0.37.0-0.37.3 - Denial of Service via Handshake Packet Number Space
quic-go is an implementation of the QUIC protocol in Go. Starting in version 0.37.0 and prior to version 0.37.3, by serializing an ACK frame after the CRYTPO that allows a node to complete the handshake, a remote node could trigger a nil pointer dereference (leading to a panic) when the node attempted to drop the Handshake packet number space. An attacker can bring down a quic-go node with very minimal effort. Completing the QUIC handshake only requires sending and receiving a few packets. Version 0.37.3 contains a patch. Versions before 0.37.0 are not affected.
CVSS 7.5
quic-go 0.37.0-0.37.3 - Denial of Service via Handshake Packet Number Space
quic-go is an implementation of the QUIC protocol in Go. Starting in version 0.37.0 and prior to version 0.37.3, by serializing an ACK frame after the CRYTPO that allows a node to complete the handshake, a remote node could trigger a nil pointer dereference (leading to a panic) when the node attempted to drop the Handshake packet number space. An attacker can bring down a quic-go node with very minimal effort. Completing the QUIC handshake only requires sending and receiving a few packets. Version 0.37.3 contains a patch. Versions before 0.37.0 are not affected.
CVSS 7.5
By Source