| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST
matches exact sequence") keeps an established conntrack entry in
ESTABLISHED when an in-window RST does not match the expected sequence
number exactly, so the endpoint can validate the RST with a challenge
ACK.
The timeout selection nevertheless uses the CLOSE timeout for every RST
packet. The bug is that timeout selection is based on the packet type,
not on the state transition result: even when RST validation keeps
new_state in ESTABLISHED, the timeout is still forced to
TCP_CONNTRACK_CLOSE.
Linux TCP independently rate limits challenge ACKs per socket. A second
non-exact RST can therefore arrive after the first challenge ACK has
restored the timeout but before the rate limit expires. The second RST
lowers the timeout to 10 seconds again while the endpoint suppresses the
second challenge ACK, allowing the conntrack entry to expire while both
TCP endpoints remain established.
Using the ESTABLISHED timeout for such RSTs would avoid this short
expiration window, but it could also retain stale entries for the
five-day default because conntrack cannot reliably match the endpoint's
exact TCP state.
Use the UNACK timeout for RST packets that leave the conntrack entry in
TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet
trains still fall through to timeouts[new_state], which preserves the
CLOSE timeout when conntrack accepts the RST as closing the flow.
This avoids the aggressive 10-second expiration window for non-exact
RSTs while preserving the short timeout for RSTs that conntrack accepts
as closing the flow. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_teql: fix use-after-free on lower qdisc drop
The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return
value against NETDEV_TX_OK alone. A slave that consumes the skb but
returns an error code (rc < NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated
as if the skb were still owned, so the loop restores skb->dev and calls
__skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit()
from its ndo_start_xmit() (propagated since cbbef5e18307), and when the
lower qdisc drops the packet that value is NET_XMIT_DROP after the skb
has been freed, giving a use-after-free in teql_master_xmit().
The Fix: test for consumption with dev_xmit_complete(), which accepts
NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that
need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps
the packet counted in tx_packets/tx_bytes and advances the slave; a
consumed result that is neither a success nor NET_XMIT_CN ends the
attempt and is charged to tx_dropped, so lower-qdisc drops are no longer
reported as good transmits. NET_XMIT_CN is counted like success because
it can accompany acceptance of the current packet: pfifo_head_drop drops
the old head, enqueues the current skb and returns NET_XMIT_CN.
Conditions to recreate the bug:
With CONFIG_NET_SCH_TEQL,
CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and
lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0
and a teql0 root on lkrvlan0; bring teql0 up with an address and send one
UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower
qdisc while holding a freed skb. |
| In the Linux kernel, the following vulnerability has been resolved:
tun: Require CAP_NET_ADMIN to attach to an ownerless device
Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN
in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap
devices.")
The idea was to allow the permissions on /dev/net/tun to be relaxed to
0666 and thus allow owners of tun devices assigned with TUNSETOWNER to
actually open it and get at their devices.
What we missed at the time was that persistent devices with *no* owner
were already essentially world-consumable, and anyone who could open
the device node could also attach to those.
Even then, using persistent devices with no explicitly set owner — on
the (false) presumption that CAP_NET_ADMIN would be required to open
them — wasn't an egregious userspace bug. There are cases where it does
make sense to separate the creation/configuration of the netdevice, from
the process which shovels packets into it.
Since then, TUNSETGROUP was added a year later in commit 8c644623fe7e
("[NET]: Allow group ownership of TUN/TAP devices."). Its commit message
noted that if both uid and gid are set, both have to match (in itself a
bizarre choice) — but still not that with *neither* set, no permission
at all was required.
Then in 2012 commit c8d68e6be1c3 ("tuntap: multiqueue support") allowed
new queues to be attached to a device from the moment of its creation,
with no way for userspace to close the race between creation and a
subsequent TUNSET{OWNER,GROUP}.
In 2024, commit 3ca459eaba1bf ("tun: fix group permission check") tried
to fix things to be saner: only require the user *or* the group to
match, in line with standard POSIX permissions, and require
CAP_NET_ADMIN if neither the user nor group authorised the access
(although it put the CAP_NET_ADMIN check first, and would wrongly have
reported the capability as having been used even when it was not).
That fix was reverted in commit a70c7b3cbc06 ("tun: revert fix group
permission check") due to allegedly causing a regression in an selinux
test suite which *expected* the attachment to succeed when authorised
by none of user, group, nor CAP_NET_ADMIN:
https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/
We should not break UAPI. But we don't have to consider an selinux test
case which deliberately exercises a security flaw to be UAPI worth
preserving either. To which end, I have fixed it in selinux-testsuite
commit b2f894f0016b ("tests/tun_tap: set an owner on the device for the
relabel tests").
So: fix the lack of CAP_NET_ADMIN check on devices which *haven't* been
assigned an owner or group, while leaving the weird tun ownership model
as it was (user *and* group have to match, if both are set). If someone
still wants to fix the latter (which wasn't actually the reason the
previous attempt was reverted), they can do it under separate cover.
Permit attaching to an existing device only if an owner and/or group was
set and the caller matches all that were set, or if the caller has
CAP_NET_ADMIN. The only behavioural change is that a device with no
owner or group now requires CAP_NET_ADMIN to attach — precisely the
loophole we want to close.
And put the CAP_NET_ADMIN check in the right place this time. |
