| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been identified in armeria versions 0.80.0 through 1.42.0, where attackers who control file names can cause stored cross-site scripting (XSS) when directory listing is enabled and a user views the listing. |
| A vulnerability has been identified in armeria versions 0.84.0 through 1.42.0, where any-origin CORS policies do not enforce configured path restrictions, allowing an attacker-controlled website visited by an authenticated victim to read sensitive responses from excluded paths when credentials are enabled and the victim's browser sends authentication credentials. |
| A vulnerability has been identified in armeria-saml versions prior to 1.43.0, where the HTTP-Redirect binding decoder decompresses attacker-supplied SAML messages without limiting the output size before signature validation, allowing an unauthenticated remote attacker to exhaust server memory and cause a denial of service. |
| A vulnerability has been identified in armeria-xds versions 1.40.0 through 1.42.0, where DataSourcePolicy checks filename containment without resolving symbolic links, allowing a compromised or semi-trusted xDS control plane to cause the xDS client to read files outside configured allowed root directories when a symbolic link inside an allowed directory points outside it. In deployments using a credential injector, header-compatible text secrets may be exposed to an attacker-observable upstream. |
| A flaw was found in GStreamer's gst-plugins-bad package. A use of uninitialized memory vulnerability exists in the H.265 (HEVC) bitstream parser when processing Video Parameter Sets that declare more than one HRD (Hypothetical Reference Decoder) parameter set. A remote attacker could exploit this by providing a crafted H.265 media file or stream that, when processed by an application using GStreamer, causes unpredictable parser behavior and may crash the application. This can lead to a denial of service for any application using GStreamer to play back H.265 content. |
| HTTP::Body versions before 1.24_02 for Perl parse the trailer in quadratic time.
Everything after the last chunk in the same call to add() is parsed with HTTP::Headers, which takes time quadratic in the number of fields of one name. For example, it takes several seconds to parse 16 KiB of "a:" lines.
A remote attackercan exhause the CPU with a single request.
HTTP::Body version 1.25 limits the size and number of lines in the trailer. |
| undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, when the redirect interceptor and a shared response cache are used together, an authenticated request that is redirected to a same-origin target has the final response stored under the original request's cache key. That key omits the credential and carries no Vary header, so a later anonymous or different user can be served the first user's private response body. This results in cross-user disclosure of cached private responses. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. |
| undici is an HTTP client for Node.js. In versions 7.15.0 through 7.30.1 and 8.0.0 through 8.12.3, fetch verifies Subresource Integrity metadata by splitting the integrity string on a single space, but the SRI grammar separates metadata by ASCII whitespace, which also includes the horizontal tab. An integrity value whose digest is preceded by a tab or other ASCII whitespace is parsed as a single unrecognized token and skipped, and when no recognized algorithm remains undici treats the integrity list as empty and accepts the response, so a server returning a body different from the pinned digest passes the check. An application that pins a response with a valid but whitespace-surrounded SRI value receives attacker-controlled bytes with no integrity error, and the attacker needs only to control the response body, not the integrity metadata. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, supply SRI integrity metadata without surrounding whitespace, using a single space to separate multiple digests. |
| undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, the redirect interceptor strips sensitive headers such as Authorization, Cookie, Proxy-Authorization, and Host when a request is redirected to a different origin, but when request headers are supplied as an array of name and value tuples (a valid documented input, for example from Object.entries), the redirect handler misreads them as a flat list so the header names never match and the sensitive headers are not removed. If a header-normalizing interceptor such as cache or deduplicate is composed outside the redirect interceptor, it then serializes the retained headers onto the cross-origin request, disclosing the caller's origin-bound credentials to the unrelated redirect destination. This is a representation-dependent bypass of the cross-origin header stripping added in CVE-2024-30260. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, supply request headers as a plain object or a flat name and value array rather than an array of tuples, or compose the redirect interceptor outside the normalizing interceptor. |
| undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, when the cache interceptor is composed with a downstream handler that throws during response processing (such as the built-in dump interceptor exceeding its maxSize, or the decompress interceptor rejecting more than five Content-Encoding values), a throw raised asynchronously while a cached response is replayed escapes as an uncaught exception or unhandled promise rejection and terminates the Node.js process. A malicious or compromised HTTP server can crash any such client by serving a cacheable response that triggers the throw on replay, including on a 304 revalidation of a stale entry, so the impact is availability only. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, avoid composing the cache interceptor with a response handler that throws during response processing until upgrading. |
| undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, when an Agent composes the redirect and shared cache interceptors, a cached response that is revalidated with a conditional request can be validated by a 304 Not Modified from a different origin. When the origin that stored the response redirects the conditional revalidation request to another origin, the redirect handler strips origin-bound credential headers but not the cache-generated If-None-Match or If-Modified-Since validators, so the redirect destination receives the original origin's validator and undici treats its 304 as successful revalidation of the stored representation. As a result, a shared cache can serve the original origin's stored authenticated response, including one gated by Authorization, to a later unauthenticated caller. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, compose the interceptors as cache then redirect, use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests. |
| undici is an HTTP client for Node.js. In versions 7.30.1 and 8.12.2 through 8.12.3, when an originless Agent composes the redirect and shared cache interceptors, undici decides whether to store the final response under the original request key by inspecting only the final redirect hop, which bypasses the earlier fix for CVE-2026-109829 that compared only the initial and final origins. A redirect that bounces through an untrusted origin and returns to the trusted origin is still cached under the trusted key, an intermediate hop's Vary is dropped so a response that varies on Authorization or Cookie can be served to a different user, and an intermediate hop's no-cache or default-uncacheable status is ignored so a non-storable redirect is laundered into a cacheable entry. An attacker who controls a redirect target from a trusted URL can poison the cached entry for that URL or have a private, per-user response served to a later caller. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, compose the interceptors as cache then redirect, use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests. |
| The BigFix MCM admin portal is directly accessible from the internet without VPN or network restriction. A client-side configuration file discloses non-sensitive environment details. Exposing the configuration file publicly increases the attack surface and the risk of unauthorized access attempts. |
| Invocation of the Jolokia special agent with the login password in the command line in Checkmk versions 2.5.0 before 2.5.0p16 allows a local user on the Checkmk server to read the Jolokia login password from the process list while the special agent is running. This affects both explicitly configured passwords and passwords from the password store. |
| Invocation of the NetApp ONTAP special agent with the login password in the command line in Checkmk version 2.5.0 before 2.5.0p16 allows a local user on the Checkmk server to read the NetApp login password from the process list while the special agent is running. This affects both explicitly configured passwords and passwords from the password store. |
| Issue summary: Setting an AES-GCM-SIV IV shorter than the expected nonce
length via EVP_CipherInit_ex() may trigger a heap out-of-bounds read.
Supplying a longer IV is silently truncated instead of rejected.
Impact summary: An application passing a caller-supplied IV of the wrong
length may crash or read beyond its buffer. Because trailing IV bytes are
ignored, an attacker who knows one message and tag may forge messages under a
different IV.
CWE: CWE-125: Out-of-bounds Read
Description: AES-GCM-SIV copies the caller-supplied IV or nonce into its
internal state using a copy whose length is taken from the expected nonce size
rather than from the length the caller actually provided. When the caller
passes a shorter IV, the copy reads past the end of the caller's buffer;
AddressSanitizer confirms a heap out-of-bounds read reached through
EVP_CipherInit_ex() into ossl_aes_gcm_siv_init(). When the caller passes a
longer IV, the implementation silently discards the trailing bytes instead of
rejecting the length.
The truncation breaks the binding between the IV and the computed
authentication tag. An attacker who has observed a message and its tag under
one IV can produce a message and tag that verify under a different IV whose
first bytes match, since the surplus bytes never influence the computation.
The message itself is unchanged, so this is a failure of IV commitment rather
than a classic existential forgery.
Only applications that call EVP_CipherInit_ex() (or the equivalent provider
cipher initialization) with an IV length other than the standard 12 bytes for
AES-GCM-SIV are affected. The severity is limited because the out-of-bounds
read is small and attacker-controlled only in length, and the forgery requires
an unusual IV length choice by the application.
FIPS impact: no
The FIPS modules are not affected by this issue, as AES-GCM-SIV is not an
approved algorithm. |
| Issue summary: A retransmitted QUIC CRYPTO frame can release packet storage
while the TLS record layer retains a direct pointer into that storage causing
use after free.
Impact summary: A malicious QUIC server can cause a heap-use-after-free read
in the OpenSSL QUIC client. The server can also identify one allocator-adjacent
byte through the client's protected Handshake response.
CWE: CWE-416: Use After Free
Description: During CRYPTO stream processing, a pointer into the first frame's
memory on the stream is lent to the TLS handshake processing. The memory
must remain stable until it is processed and released. However the processing
of retransmitted CRYPTO frames could release the memory if the retransmitted
frame fully overlapped the existing frame. This then causes use-after-free read
when the TLS handshake processing continues.
The use-after-free read can lead to a Denial-of-Service of the client
application or a minor leak of information about the heap memory contents
that might be overwritten with other data, subsequently allocated by
the application, to the peer.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
| Issue summary: The AES-GCM-SIV implementation treats a zero-length Additional
Authenticated Data (AAD) update as a reset of all the AAD supplied so far,
instead of leaving the AAD unchanged. An application that supplies its AAD in
several fragments, one of which is empty, therefore produces or verifies
messages whose authentication tag does not cover the AAD supplied before
the empty fragment.
Impact summary: Data an application intended to authenticate alongside a
message is silently left unauthenticated. An attacker can forge the AAD of such
a message.
CWE: CWE-325: Missing Cryptographic Step
Description: An application passing AAD in multiple chunks of which some have
zero length will have the previous AAD chunks effectively unauthenticated. Also,
on context re-initialisation, the AAD was not reset, which meant that any AAD
accumulated from the previous context usage were also included in the AAD of the
new message.
The fix makes a zero-length AAD update a no-op and clears any accumulated AAD
whenever the context is re-initialised with a key or a nonce.
A re-initialisation that only changes parameters keeps the AAD.
FIPS impact: no
The FIPS modules are not affected, as AES-GCM-SIV is not a FIPS approved
algorithm and is implemented only in the default provider, outside the
OpenSSL FIPS module boundary. |
| Issue summary: QUIC, when performing automated peer detection, may allow
uninitialized stack data to leak into the received address which is then used
as the destination for outgoing packets.
Impact summary: Applications using QUIC's automated peer detection mechanism
may receive an invalid address, leading to connection loss and disclosure of
uninitialized stack data to an attacker observing the outgoing network traffic.
CWE: CWE-457 (Use of Uninitialized Variable)
Description: The OpenSSL QUIC stack contains a feature in which, when using an
already connected socket, it will auto-detect the peer address during the SSL
handshake. This feature uses the getpeername() function, passing a buffer of
sufficient length to hold any supported address family, but passes a buffer
length that is only sized such that larger addresses, such as IPv6, cannot be
retrieved. The getpeername() function however, still returns the full address
length, which is accepted as the valid input buffer length, leading to the
address buffer containing uninitialized stack data instead of the actual peer
address. The invalid peer address is then used as destination for the outgoing
packets which leads to a connectivity breakage and a leakage of the
uninitialized stack data to passive network observers.
FIPS impact: no
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this CVE as
the affected protocol is not implemented in the FIPS module. |
| In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker in skb_zerocopy()
skb_zerocopy() moves frag descriptors from @from into @to and takes a
reference on each frag, but it does not copy skb_shinfo(from)->flags into
skb_shinfo(to)->flags. A destination skb holding the same page-cache
backed frags as the source therefore reports skb_has_shared_frag() as
false.
That breaks the invariant relied on by later in-place writers. ESP input
checks skb_has_shared_frag() before deciding whether an uncloned
nonlinear skb can skip skb_cow_data(); with the marker lost, an skb that
skb_zerocopy() built for nfnetlink_queue or for an openvswitch upcall is
decrypted in place, letting an unprivileged user write into the page
cache of a root-owned read-only file.
Propagate SKBFL_SHARED_FRAG when frag descriptors are copied, as done for
the other frag-transfer helpers. |
