There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - undici's cache interceptor does not handle the Set-Cookie response header anywhere in its cache path, so
    it neither refuses to store nor strips that header. In shared cache mode, which is the default, an
    otherwise cacheable response that carries a Set-Cookie header, for example one marked with a public and
    max-age directive, is stored and then re-served to a later caller that matches the same cache key. As a
    result one caller's cookie is disclosed to a different caller, and an untrusted server can inject cookies
    into cached responses served to all subsequent callers. This violates the requirement that a shared cache
    must not store cookies. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2.
    Users should upgrade to undici 7.29.1 or 8.10.2. (CVE-2026-84933)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - undici's cache interceptor does not handle the Set-Cookie response header anywhere in its cache path, so     it neither refuses to store nor strips that header. In shared cache mode, which is the default, an     otherwise cacheable response that carries a Set-Cookie header, for example one marked with a public and     max-age directive, is stored and then re-served to a later caller that matches the same cache key. As a     result one caller's cookie is disclosed to a different caller, and an untrusted server can inject cookies     into cached responses served to all subsequent callers. This violates the requirement that a shared cache     must not store cookies. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2.
    Users should upgrade to undici 7.29.1 or 8.10.2. (CVE-2026-84933)

Note that Nessus relies on the presence of the package as reported by the vendor.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-3107 advisory.

    undici's retry handler can leave an already-exposed response body pending forever. When a server returns a     successful response that declares a Content-Length, sends only part of the body, and closes the     connection, the retry handler retries the request. If the retry returns a non-retryable status such as     400, the handler forwards that new response downstream and replaces its internal response stream, but the     original response body that the application still holds is never ended or destroyed. As a result calls     that read that body never settle, and the configured body timeout does not fire because its timer is tied     to the connection parser rather than the orphaned body. An attacker-controlled server can trigger this     with two short responses without keeping a connection open, and repeated requests accumulate pending     promises and streams that can exhaust application concurrency or memory. This affects undici versions from     7.11.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.
    (CVE-2026-18149)

    undici's retry interceptor can append the body of a ranged retry response to bytes already delivered from     an earlier partial response while still presenting the original response's status and headers. This     happens when an upstream server delivers part of a body without a trustworthy resume checkpoint, for     example a non-success response whose headers were already sent or a partial-content response with an     unusable content range, then closes the connection and answers the resumed range request with more bytes.
    As a result the response body can be longer than the Content-Length that the application observes. An     application that relays such a response to a downstream HTTP/1.1 peer without normalizing the framing can     emit a body that exceeds the forwarded Content-Length, and the excess bytes can be interpreted as the     start of a following response, which enables downstream response splitting or desynchronization.
    Exploitation requires an attacker-controlled upstream server and an application that forwards the response     through a framing-sensitive path. This affects undici versions before 6.28.1, from 7.0.0 up to 7.29.1, and     from 8.0.0 up to 8.10.2. Users should upgrade to undici 6.28.1, 7.29.1, or 8.10.2. (CVE-2026-18540)

    undici's WebSocket client crashes the whole Node.js process during the opening handshake when a server     responds with a subprotocol that the client never requested. A default WebSocket connection sends no     subprotocol, but if the server's 101 response includes a Sec-WebSocket-Protocol header, undici     dereferences a null value while checking it against the requested list and throws an uncaught TypeError.
    Because that code runs inside a microtask with no surrounding error handling, the exception propagates and     terminates the process under Node's default behavior, instead of gracefully failing the connection as     required by the WebSocket protocol. Any application that opens a WebSocket to an attacker-controlled or     compromised server, or over a plaintext connection subject to a machine-in-the-middle, can be crashed     remotely without authentication in the default configuration. This affects undici versions from 6.7.0 up     to 6.28.1, from 7.0.0 up to 7.29.1, and from 8.0.0 up to 8.10.2. Users should upgrade to undici 6.28.1,     7.29.1, or 8.10.2. (CVE-2026-19534)

    undici's decompress interceptor decompresses response bodies according to the untrusted Content-Encoding     header. While the number of content-encoding layers is capped, the total decompressed output size is     unbounded and there is no configuration option to limit it. A malicious or faulty upstream can therefore     return a small compressed payload, a compression bomb, that expands to hundreds of megabytes or more in     client memory, an asymmetric resource consumption that can exhaust memory and crash the process. This     affects undici versions from 7.15.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to     undici 7.29.1 or 8.10.2. (CVE-2026-84890)

    undici's cache interceptor does not handle the Set-Cookie response header anywhere in its cache path, so     it neither refuses to store nor strips that header. In shared cache mode, which is the default, an     otherwise cacheable response that carries a Set-Cookie header, for example one marked with a public and     max-age directive, is stored and then re-served to a later caller that matches the same cache key. As a     result one caller's cookie is disclosed to a different caller, and an untrusted server can inject cookies     into cached responses served to all subsequent callers. This violates the requirement that a shared cache     must not store cookies. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2.
    Users should upgrade to undici 7.29.1 or 8.10.2. (CVE-2026-84933)

    undici's dump interceptor reads and discards a response body up to a configurable maximum size. When a     response declares a Content-Length that exceeds the maximum, the interceptor aborts cleanly, but when a     response has no Content-Length and is chunked, the interceptor instead signals completion early once the     accumulated size reaches the maximum, without pausing or aborting the request. Because the underlying     parser keeps delivering body bytes, a second completion signal fires and trips an internal assertion,     which aborts the request and tears down the connection. The application is left observing a misleading     successful status with an empty or truncated body while the connection has actually been disconnected.
    This affects undici versions from 7.1.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to     undici 7.29.1 or 8.10.2. (CVE-2026-84947)

    undici's BalancedPool constructor passes its entire options object through an internal deep-clone that     serializes and reparses the value as JSON. Because JSON cannot represent functions, any function-valued     TLS option, such as a caller-supplied checkServerIdentity callback or a custom connector inside the     connect option, is silently discarded before it reaches the TLS layer. As a result a peer whose     certificate the application's custom checkServerIdentity was written to reject, but which still passes     Node's default hostname and chain checks, is accepted when reached through BalancedPool. The Client, Pool,     and Agent dispatchers are not affected because they extract the connect and tls options before cloning.
    This affects undici versions from 7.24.1 up to 7.29.1 and from 8.0.0 up to 8.10.2, and only when the     application supplies a function-valued connect or tls option to BalancedPool. Users should upgrade to     undici 7.29.1 or 8.10.2. (CVE-2026-84961)

    undici's cache interceptor documents that only safe HTTP methods are cached, but its logic to skip caching     is built by subtracting the configured methods from the set of safe methods, so an unsafe method such as     POST, PUT, or DELETE is never placed in the skip list and instead falls through to the full cache-read     path. The response-storage gate also lacked a method check, so a response to an unsafe request that is     heuristically cacheable or carries an explicit Cache-Control directive is stored and later replayed from     cache. Because response headers from a remote origin are untrusted, an origin can answer once with a     cacheable status and then have the client's own subsequent state-changing requests to that path served     from the stale cache entry without ever reaching the origin, an integrity failure that occurs under the     interceptor's default configuration. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0     up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2. (CVE-2026-85008)

    undici bundles a WebSocket client whose permessage-deflate size-limit cleanup removes all listeners from     the internal zlib inflate stream, including its error listener, while that stream can still emit. When a     remote peer sends a compressed payload that crosses the built-in 128 MiB decompressed-payload limit and     then contains a malformed DEFLATE byte, the inflate stream emits a data error with no listener attached,     which Node.js treats as a fatal unhandled error and terminates the entire process. Exploitation is remote     and unauthenticated, requires no application mistake, and is asymmetric, since roughly 130 KB on the wire     expands past the limit and crashes the process, and reconnecting can repeat the crash. This affects undici     versions from 6.25.0 up to 6.28.1, from 7.28.0 up to 7.29.1, and from 8.1.0 up to 8.10.2. Users should     upgrade to undici 6.28.1, 7.29.1, or 8.10.2. (CVE-2026-85024)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Published	Updated	Severity
448482	SCA: security update for undici (GHSA-2jfj-6hjv-fm6j)	Tenable Cloud Security	SCA Checks	9/29/2026	9/29/2026	high
448482	SCA: security update for undici (GHSA-2jfj-6hjv-fm6j)	Tenable Self-Hosted Container Security	SCA Checks	9/29/2026	9/29/2026	high
342942	Linux Distros Unpatched Vulnerability : CVE-2026-84933	Nessus	Misc.	9/4/2026	11/6/2026	high
351057	Amazon Linux 2023 : nodejs24, nodejs24-devel, nodejs24-full-i18n (ALAS2023-2026-3107)	Nessus	Amazon Linux Local Security Checks	9/29/2026	10/2/2026	critical

Detections

Analytics

Plugins Search

high

high

high

critical