| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Mongoose is an embedded web server and network library. Priro to version 7.22, a remote unauthenticated attacker can send an HTTP request containing both Content-Length and Transfer-Encoding: chunked. The cl_count and te_count checks in the mg_http_parse() and http_cb() paths in src/http.c accept both headers and prioritize chunked encoding, while a Content-Length-preferring reverse proxy can use a different request boundary. This CL.TE desynchronization can inject requests that access or modify resources in another user context. This issue is fixed in version 7.22. |
| Mongoose is an embedded web server and network library. Prior to 7.22, a remote unauthenticated attacker can exploit an HTTP/1.0 reverse-proxy deployment by sending a request with Transfer-Encoding: chunked and conflicting framing. The http_cb() function in src/http.c tests hm.proto.len with an impossible greater-than-eight condition even though mg_http_parse() requires an eight-byte protocol string, so is_http_1_0 is never set. Mongoose consequently processes chunked encoding that an HTTP/1.0 proxy can ignore, enabling request smuggling and unauthorized access or state changes. This issue is fixed in version 7.22. |
| Mongoose is an embedded web server and network library. Prior to 7.22, an attacker who can control an SSI-enabled file can place directory traversal sequences in an #include file or #include virtual directive. The mg_ssi() function in src/ssi.c concatenates the directive argument into a filesystem path without calling mg_path_is_sane(), allowing an MG_ENABLE_SSI deployment with ssi_pattern configured to disclose files readable by the Mongoose process. This issue is fixed in version 7.22. |
| Mongoose is an embedded web server and network library. Prior to 7.22, an attacker who can create a file with an HTML payload in its name can trigger stored cross-site scripting when a user browses a directory served with MG_ENABLE_DIRLIST. The printdirentry() path called by listdir() in src/http.c URL-encodes the href but inserts the raw filesystem filename into the HTML link text. The browser executes the injected markup in the Mongoose origin, which can expose session data or permit actions as the victim. This issue is fixed in version 7.22. |
| Mongoose is an embedded web server and network library. Prior to version 7.22, an on-path network attacker with a wildcard certificate for a parent domain can impersonate deeper subdomains to a client using the built-in TLS stack. The mg_tls_verify_cert_san() and mg_tls_verify_cert_cn() functions in src/tls_builtin.c call mg_match(), whose wildcard can cross DNS label boundaries, so a pattern such as *.example.com can match foo.bar.example.com. The resulting hostname verification bypass permits interception and modification of TLS traffic. This issue is fixed in version 7.22. |
| Mongoose is an embedded web server and network library. Prior to 7.23, a network attacker can impersonate a TLS server to a Mongoose client configured with a multi-certificate CA bundle. In src/tls_builtin.c, the mg_tls_init() function stores the bundle in tls->ca_bundle_der while tls->ca_der.len remains zero, and mg_tls_recv_cert() uses tls_bundle_find() to accept a Common Name match without calling mg_tls_verify_cert_signature(). A forged self-signed certificate can therefore satisfy hostname and CertificateVerify checks and enable interception, credential disclosure, traffic modification, and malicious responses. This issue is fixed in version 7.23. |
| urllib3 is an HTTP client library for Python. From 1.10.3 until 2.8.0, the HTTPResponse.read_chunked and HTTPResponse.stream methods can allocate unbounded memory because the streaming chunk parser buffers the chunk-size field until newline or EOF without a length bound. The trigger is that a malicious server returns Transfer-Encoding: chunked followed by a very long run of bytes without a newline. The attack mechanism is that a malicious HTTP server sends a very long unterminated chunk-size line. The impact is that unbounded memory allocation can exhaust the client process. This issue is fixed in version 2.8.0. |
| Missing authorization in the data source settings API in Devolutions Server 2026.3.5.0 and earlier allows an authenticated non-administrative user to disclose integration secrets via a crafted API request. |
| MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, ENABLED_TOOLS and TOOLSETS are applied when tools are listed but are not rechecked when a tools/call request is dispatched. A client that knows a hidden tool name can directly invoke excluded read, write, or delete tools despite the operator's configured least-privilege restrictions. The advisory traces the vulnerable input and processing flow through ENABLED_TOOLS, TOOLSETS, tools/list, tools/call, and _call_tool_mcp, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0. |
| Issue summary: A malicious remote peer may flood the local QUIC
stack with NEW_CONNECTION_ID frames by avoiding a limit check on
how many connection IDs the remote QUIC stack can use.
Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame
for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID
frame is dispatched via the Control Frame Queue (CFQ). If the remote
peer also withholds ACKs, then it can force the local stack
to allocate ~400MB (depending on ACK delay).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism
by which a remote peer can notify the local QUIC stack to change the
destination connection ID (a.k.a. CID) the local stack uses to
identify the connection at the remote peer. Each CID is associated
with a sequence number. The sequence number is transmitted
in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID
which is being either associated with a connection or retired.
The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know
a new CID is being associated with an existing connection. The
NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the
retire-prior-to number. The retire-prior-to identifies existing
CIDs that are to be retired. The local QUIC stack must send a
RETIRE_CONNECTION_ID for every destination CID whose sequence number
is less than retire-prior-to. The CID becomes retired after the
local stack receives an ACK for its RETIRE_CONNECTION_ID frame.
Although the OpenSSL QUIC stack supports at most one destination CID
for every connection, it can be tricked into processing more than
one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC
stack currently retires the destination CID as soon as it receives
the NEW_CONNECTION_ID, while in fact the destination CID must
be retired after an ACK for the RETIRE_CONNECTION_ID frame is received.
Correcting the flawed logic also fixes the backlog growth.
[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
| Issue summary: The first concurrent use of the same X.509 certificate by
several threads may cause its cached extension data to be freed while
another thread is still using it.
Impact summary: A remote, unauthenticated peer could crash a multi-threaded
TLS client, or a multi-threaded TLS server that requests client
certificates, if the first certificate chains built to the same trusted CA
certificate are built by several connections at the same time. This is a
use-after-free read, which is likely to crash the process, resulting in a
Denial of Service.
CWE: CWE-416: Use After Free
Description: OpenSSL caches the decoded values of a certificate's X.509v3
extensions inside the X509 object the first time they are needed. In
OpenSSL 4.0 this cache is built in two phases: the extension values are
computed while holding a read lock on the certificate, and the results are
then installed into the certificate under a write lock. Because a read lock
does not exclude other readers, several threads can compute the cache for
the same certificate at the same time. Each thread that subsequently
acquires the write lock installs its own results and frees the values
installed by the thread before it, even though that earlier thread has
already marked the cache as complete and may have returned pointers into it
to its caller. A caller still using those pointers then reads freed memory.
Any certificate shared between threads is exposed the first time its
extensions are decoded. In TLS the certificates at risk are the trusted CA
certificates supplied for chain verification, by whatever means, since these
are shared by every connection and their extensions are decoded and cached
the first time a chain is built to them. Certificates sent by the peer are
decoded separately for each connection and are not shared, so they are not
affected. In a TLS client verifying server certificates, or a TLS server
that requests and verifies client certificates, the use-after-free could
only occur if the first chains built to the same trusted CA are built by
several connections at the same time.
FIPS impact: no
The FIPS module is not affected as X.509 certificate handling is outside
of the OpenSSL FIPS module boundary.
OpenSSL 4.0 is vulnerable to this issue.
OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.
This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and
independently in a public report on 31 August 2026 by aydinmercan.
The fix has been developed by Bob Beck.
-- cut (non-publishing metadata for internal use) --
Reported by: Tim Becker (Xint.io), aydinmercan
Fixed by: Bob Beck |
| Issue summary: The DTLS retransmission logic does not correctly handle
a handshake message write that is suspended part-way through.
The retransmitted message can be read past the message buffer and
the retransmission overwrites the internal state the suspended write
needs to resume correctly.
Impact summary: The retransmitted message can disclose a heap memory
to the peer as plaintext handshake data or cause a crash and a Denial
of Service when the read reaches an unmapped memory region.
CWE: CWE-125: Out-of-bounds Read
Description: DTLS handshake messages can be written out in multiple
fragments, and a write can suspend mid-message (returning WANT_WRITE)
if the underlying transport temporarily cannot accept more data. While
such a write is suspended, the DTLS retransmission timer may
independently fire and ask the retransmission logic to resend an
earlier, already-acknowledged-as-sent message from its retransmit
queue.
The retransmission logic reused the same internal buffer and position
tracking as the message that was still being written, without
resetting the position back to the start of the message being
retransmitted. As a result the retransmission was read starting from
wherever the suspended write had left off, producing a mislabelled
message whose body was leftover bytes from the other, larger message
still in flight - content that was never meant to be sent at that
point, and which could run past the end of the allocated buffer.
Separately, even when the retransmission is positioned correctly,
allowing it to run to completion while another write is suspended
overwrites the same shared bookkeeping that the suspended write
depends on to resume. When the application later resumes the
suspended write (via a subsequent SSL_read(), SSL_write(),
SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a
state inconsistent with the message and aborts the process in
a debugging build.
The fix resets the retransmission's read position to the start of the
message before resending, and skips retransmission entirely whenever a
handshake write is still suspended, deferring to the next call that
resumes it instead.
FIPS impact: no
The affected code is outside the FIPS module boundary. |
| Issue summary: SM2 signature generation uses non-constant-time arithmetic
on secret values, forming a timing side-channel.
Impact summary: An attacker able to measure SM2 signing times may learn
information about the per-signature secret nonce, which over many signatures
can, via a lattice / Hidden Number Problem attack, lead to recovery of the
private key.
CWE: CWE-208: Observable Timing Discrepancy
Description: SM2 signature generation computes the signature value using
variable-time BIGNUM operations on the secret nonce and the private key, so
the time taken to produce an SM2 signature depends on these secret values,
forming a timing side-channel.
Applications performing SM2 signature generation are affected on all
platforms.
FIPS Impact: no
SM2 is not a FIPS algorithm. |
| Issue summary: An established DTLS 1.2 association using an AEAD cipher suite
can be terminated by a single unauthenticated datagram whose encrypted
fragment is shorter than the mandatory explicit IV and authentication tag
overhead.
Impact summary: An attacker who can send a datagram that is routed to an
existing DTLS 1.2 association can tear that association down without knowing
any key material. This is a Denial of Service limited to the targeted
association. There is no memory safety or confidentiality impact.
CWE: CWE-1284: Improper Validation of Specified Quantity in Input
Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher
suite carries an explicit IV followed by the ciphertext and an authentication
tag. When decrypting such a record the record layer passed the record length to
the cipher implementation before checking that the record was long enough to
contain the explicit IV and the tag. For a record shorter than that overhead the
cipher implementation rejected the impossible length, and the record layer
treated this as an internal failure and raised a fatal internal_error alert
instead of treating the record as one that failed authentication.
In TLS 1.2 the same record causes a fatal internal_error alert instead of the
expected bad_record_mac alert. Since any undecryptable record already
terminates a TLS connection, this is a protocol conformance issue rather than
a security issue in TLS.
The fix validates the record length against the explicit IV and tag length
before any AEAD processing, so that TLS reports bad_record_mac and DTLS
silently discards the record.
FIPS impact: no
The affected code is outside the FIPS module boundary. |
| Issue summary: A CMP client that requests certificate revocation on the basis
of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when
processing a crafted revocation response.
Impact summary: The NULL pointer dereference happens on a read which
leads to a crash and a Denial of Service for the affected client application.
CWE: CWE-476: NULL-pointer dereference
Description: A CMP client revoking a certificate has to tell the server which
certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the
certificate itself or its issuer name and serial number. This is
'openssl cmp -cmd rr -csr <file>' on the command line, or
OSSL_CMP_exec_RR_ses() with the certificate supplied via
OSSL_CMP_CTX_set1_p10CSR() through the API.
A CSR does not contain the issuer name and serial number of the certificate,
so the client does not send them. A server may optionally name the
certificate it revoked in its response, and the client then compares that
name against what it sent. Having sent neither an issuer name nor a serial
number, it has nothing to compare against, and a server returning a specially
crafted name causes the client to read from a NULL pointer and crash.
The revocation response is checked for valid message protection before
the affected code is reached, so an attacker must be a malicious or
compromised CMP server, or a man-in-the-middle in possession of the
secret used for message protection. Clients that identify the certificate
to be revoked by a certificate or by issuer and serial number rather
than by a PKCS#10 CSR are not affected.
FIPS impact: no
No FIPS modules are affected by this issue, as the CMP protocol
implementation is outside the OpenSSL FIPS module boundary. |
| Issue summary: OpenSSL QUIC stack does not enforce connection
level flow control for streams. Remote peers may send more bytes
as long as they fit within the stream flow control limits.
Impact summary: A malicious remote peer may exploit the lack of connection
flow control for streams to make the QUIC stack receive ~100MB of memory
instead of 768 KiB (default flow control window size).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The local QUIC stack advertises two flow control limits
to its remote peer: stream flow control limit and connection flow
control limit. The remote peer must follow both limits when transmitting
stream data.
Whenever the local QUIC stack receives a stream frame, it validates
that the size of the received stream frame stays within flow control limits.
If either limit is exceeded (stream level or connection level), then
the QUIC stack must close the connection with a flow control error.
The vulnerable OpenSSL QUIC stack enforces the stream-level but not
the connection-level limit. To exploit the issue, three conditions must be met:
- the remote peer opens several streams
- each stream must stay within the stream-level flow control limit
- there must be no zero-offset byte sent on any of the streams
(to prevent the vulnerable QUIC stack from consuming data).
By meeting the conditions above, the remote peer may make the local stack
allocate 2 x MAX_STREAMS x (stream flow control limit) bytes
of memory. MAX_STREAMS defaults to 100, and the limit applies to both
bidirectional and unidirectional streams, making it 200 in total. The default
flow control window for a stream is 512kB. The remote peer may
force the vulnerable QUIC stack to allocate 100MB of heap per connection.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
| Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a
connection to a different SSL_CTX part way through a handshake may access
memory beyond the end of an internal array if the replacement context knows
about more provider signature algorithms than the context the connection was
created from. Applications which never call SSL_set_SSL_CTX() are not
affected.
Impact summary: A remote peer may be able to cause a small out-of-bounds
read, and in some circumstances a fixed-value out-of-bounds write, on the
server heap. This may lead to a Denial of Service.
CWE: CWE-787: Out-of-bounds Write
Description: A TLS connection records how many certificate slots it has
when it is created, taken from the SSL_CTX that created it: the built-in
certificate types plus one slot for each provider TLS-SIGALG entry that
context was aware of. That count sizes an internal array of per-slot
certificate validity flags.
An application may replace a connection's SSL_CTX part way through the
handshake by calling SSL_set_SSL_CTX(), most commonly from a servername
callback in order to serve a different virtual host. Doing so did not
refresh the recorded count. A provider signature algorithm's slot index is
its position in the list of whichever context resolves it, so if the
replacement context is aware of more of them than the original, an
algorithm offered by the peer can resolve to an index beyond the end of the
array. Processing the peer's signature algorithms then reads one four byte
word past the end for each such algorithm and, where the word read is zero,
writes a fixed value over it. A peer offering many of them can corrupt heap
metadata and abort the process.
Only provider signature algorithms which occupy one of the excess slots,
and which the server also has configured, have this effect. Codepoints the
replacement context does not recognise are discarded without being resolved
to a slot, and provider signature algorithms are usable only from TLS 1.3.
The two contexts must therefore be aware of different numbers of provider
signature algorithms, which requires separate library contexts, a provider
loaded between the two being created, or providers which differ in what
they advertise - in 4.0, for example, the default provider advertises SM2
where the FIPS provider does not. A deployment meeting the condition is
also unable to negotiate the affected algorithms with legitimate clients,
since the same stale count hides the corresponding certificates, so the
misconfiguration is likely to be noticed. For that reason, and because the
configuration is not the default, this issue has been assessed as Low
severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary. |
| urllib3 is an HTTP client library for Python. From 2.6.2 until 2.8.0, HTTPResponse.stream and HTTPResponse.read_chunked can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes, specifically a response with Transfer-Encoding: chunked and Content-Encoding: deflate, content decoding enabled, and the positive finite amt=N streaming chunk size. The attack mechanism is that a malicious server returns a compressed chunked response with trailing bytes after the Deflate stream. The impact is excessive CPU usage and a request that does not complete, and network read timeouts do not interrupt the loop because no further socket read occurs. This issue is fixed in version 2.8.0. |
| Issue summary: A non-constant-time optimized implementation of scalar
point multiplication is used for SM2 private key operations on ARM64 and
RISC-V platforms.
Impact summary: An attacker able to measure the time taken by, or to observe
the cache-line access pattern of SM2 signing or decryption on an affected
platform can learn information about the secret scalar.
CWE: CWE-208: Observable Timing Discrepancy
Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized
scalar multiplication implementation whose conditional branches and table
look ups are chosen according to the bits of the secret scalar. The execution
time and the cache-access pattern therefore depend on the long-term private
key (during SM2 decryption) or the per-signature nonce (during SM2 signature
generation), forming a timing and cache side-channel.
FIPS Impact: no
SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part
of the FIPS module.
OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and
RISC-V.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8.
This issue was reported on 2 May 2026 by Abhinav Agarwal.
It was independently reported on 6 June 2026 by Feng Xue.
The fix was developed by Igor Ustinov.
-- cut (non-publishing metadata for internal use) --
Reported by: Abhinav Agarwal, Feng Xue
Fixed by: Igor Ustinov |
| Issue summary: QUIC process may keep memory for QUIC packet
buffer for much longer period than necessary.
Impact summary: Remote peer can exploit this vulnerability
by sending maliciously crafted packets, making the local
QUIC stack to keep the memory for packet buffers allocated.
The time for which the memory remains allocated is entirely
under the control of the potentially malicious remote peer.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: To save copy operation from the packet buffer to the
stream reassemble buffer the QUIC stack leaves the stream data
on the packet buffer waiting to be copied to a buffer provided
by the local receiving application. The QUIC stack releases
a reference to the packet buffer only after the data are copied
to the application buffer. This design is more efficient for
legitimate data transfers but enables an attacker to allocate a lot
more memory than actually required by the data kept in the receiving
stream buffer.
To mitigate the vulnerability, the QUIC stack now calculates
and monitors memory overhead for every stream. The memory overhead
for a single stream frame is calculated as a difference between the
size of the whole packet that carries the stream frame and the size
of the stream frame itself. The memory overhead for a single stream
frame is added to the total (cumulative) memory overhead QUIC stack
keeps for each stream. Once the cumulative memory overhead exceeds
64kB, the QUIC stack moves the stream frame data from the packet
buffer to the stream buffer, starting with the next packet received.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
