RHSA-2026:92378HighCVSS 8.1

Red Hat Security Advisory: nodejs:24 security, bug fix, and enhancement update

Published
October 29, 2026
Last Modified
November 12, 2026

🔗 CVE IDs covered (13)

📋 Description

CVE-2026-101911 — ip-address: ip-address: Denial of Service via unbounded IPv6 address parsing CVE-2026-102276 — brace-expansion: brace-expansion: Denial of Service via stack exhaustion from crafted brace patterns CVE-2026-102277 — brace-expansion: brace-expansion: Denial of Service via crafted brace patterns CVE-2026-102278 — brace-expansion: brace-expansion: Denial of Service via uncontrolled recursion in nested brace patterns CVE-2026-105481 — nodejs: nodejs: Response desynchronization via improper HTTP keep-alive connection reuse CVE-2026-105482 — nodejs: nodejs: dns.resolve truncates hostnames containing a NUL character CVE-2026-105483 — nodejs: nodejs: TLS certificate hostname bypass via fullwidth-digit IP hostnames CVE-2026-106069 — nodejs: nodejs: TLS certificate hostname bypass via non-canonical IP hostnames CVE-2026-106071 — nodejs: nodejs: Permission model bypass via wildcard path matching flaw CVE-2026-106072 — nodejs: nodejs: Authentication bypass via non-canonical IPv4 hostname verification CVE-2026-106073 — nodejs: Node.js: Filesystem read permission bypass via fs.realpathSync() CVE-2026-106074 — nodejs: nodejs: predictable random values via snapshot entropy cache reuse CVE-2026-111497 — brotli: Out-of-Bounds Write in Google Brotli Decoder

🎯 Affected products41

  • Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.src (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.x86_64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.x86_64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debugsource-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debugsource-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debugsource-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-debugsource-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.x86_64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-devel-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-devel-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-devel-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-devel-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.x86_64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-docs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.noarch (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-full-i18n-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-full-i18n-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-full-i18n-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-full-i18n-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.x86_64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.x86_64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.aarch64 (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.ppc64le (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • nodejs-libs-debuginfo-1:24.22.1-3.module+el9.8.0+25216+afa2a4a4.s390x (nodejs:24) as a component of Red Hat Enterprise Linux AppStream (v. 9)
  • +11 more not shown

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Updating the bundled brace-expansion dependency to a version that contains the upstream fix (1.1.21, 2.1.7, 3.0.9, or 5.0.12, depending on the major version in use) resolves the issue. Workaround: Restrict Node.js clients so outbound HTTP/1.1 keep-alive pools only reach trusted backends. Where operationally feasible, disable connection reuse to untrusted hosts (for example short-lived agents or agents with keepAlive disabled). Prefer authenticated TLS backends and avoid sending security-sensitive requests over keep-alive pools shared with untrusted peers. Workaround: To mitigate, do not pass untrusted strings into dns.resolve; reject hostnames that contain embedded NUL bytes before DNS resolution. Limit which components may perform DNS lookups on attacker-influenced names, and restrict network reachability of those services. --- CME Mitigation Guidance (2026-11-02) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to reject hostnames containing embedded NUL bytes before passing them to Node.js DNS resolution APIs or underlying c-ares C strings: upgrade to Node.js 22.23.4, 24.22.1, and 26.12.1 (or the fixed Nodejs/Hi/Nodejs/Nodejs:24/Nodejs/Nodejs:22/Nodejs/Nodejs:26/Nodejs/Cloudservices/Subscription Central Automation builds), which validate resolve inputs and reject hostnames containing null bytes before passing them to c-ares, closing all 2 injection vectors (embedded NUL byte hostname truncation, domain allowlist validation bypass). Until patched, this is a concern on Applications running Node.js that resolve untrusted, attacker-influenced hostnames via dns.resolve or dns.reverse APIs, so Reject hostnames containing embedded NUL characters before calling dns.resolve or dns.reverse, and restrict which components perform DNS lookups on untrusted input. As a compensating measure, Enforce outbound network egress filtering to restrict unauthorized application connections if a truncated hostname resolves to external destinations and Implement certificate pinning to prevent establishing TLS sessions when connecting to unintended hosts that do not match expected pinned certificates. These controls limit blast radius and contain exploitation, but they do not fix the underlying embedded NUL byte hostname truncation defect — apply the upstream patch to fully remediate. Highest-impact CME: CME-1315 Allowlist-Preferred Input Validation (Deny-by-Default Filtering) (high) Workaround: To mitigate do not pass untrusted hostnames that may contain non-ASCII or fullwidth digits into TLS clients such as tls.connect, https.request, or fetch. Restrict outbound TLS connections to trusted destinations only, and segment services that initiate TLS client connections from untrusted networks. --- CME Mitigation Guidance (2026-11-02) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to normalize hostnames and IP representations to standard ASCII before passing destination strings to TLS client calls such as tls.connect, https.request, or fetch: upgrade to Node.js v24.22.1, v26.12.1 (or the fixed Nodejs/Nodejs:24/Nodejs/Nodejs:26/Nodejs/Cloudservices/Subscription Central Automation builds), which fix IP normalization regression in TLS hostname validation to ensure fullwidth digit hostnames are recognized as IP addresses, closing all 2 injection vectors (fullwidth Unicode digit IPv4 connection strings, DNS SAN matching on numeric hostnames). Until patched, this is only a concern on Node.js applications running on 24.x and 26.x runtimes establishing TLS client connections — Node.js 22.x deployments are unaffected — so Do not pass untrusted hostnames or URLs that may contain non-ASCII or fullwidth digits into TLS clients, and restrict outbound TLS connections to trusted destinations. As a compensating measure, Restrict outbound requests to a validated destination allowlist to prevent arbitrary attacker-controlled host strings from reaching Node.js TLS clients and Segment services initiating TLS client connections from untrusted networks to prevent attackers from intercepting or impersonating connections. These controls limit blast radius and contain exploitation, but they do not fix the underlying TLS IP hostname normalization defect — apply the upstream patch to fully remediate. Highest-impact CME: CME-1315 Allowlist-Preferred Input Validation (Deny-by-Default Filtering) (high) Workaround: To mitigate, reject non-canonical numeric hostnames before opening TLS connections. Restrict outbound TLS to trusted destinations only, and isolate services that make TLS client connections based on untrusted input. --- CME Mitigation Guidance (2026-11-02) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to validate and canonicalize numeric hostnames prior to TLS client connection setup to eliminate normalization discrepancies against the platform resolver: upgrade to Node.js 22.23.4, 24.22.1, 26.12.1 (or the fixed Nodejs/Nodejs:22/Nodejs/Nodejs:24/Nodejs/Nodejs:26/Nodejs/Cloudservices/Subscription Central Automation builds), which reject non-canonical IP addresses during hostname verification, closing all 2 injection vectors (IPv4 literal with leading zero octal notation, abbreviated numeric IPv4 address format). Until patched, this is a concern on Node.js TLS client applications connecting to untrusted hostnames across supported platforms, so reject non-canonical numeric hostnames before initiating TLS connections, restrict outbound TLS requests to trusted destinations, and isolate client services handling untrusted connection targets. As a compensating measure, pin expected server certificates or public keys to reject unauthorized peer certificates even if hostname verification is deceived by address normalization differences. These controls limit blast radius and contain exploitation, but they do not fix the underlying hostname normalization discrepancy defect — apply the upstream patch to fully remediate. Highest-impact CME: CME-1304 SSRF Prevention (Outbound Request Allowlist) (high) Workaround: If the Permission Model is unused, do not enable --permission. When using --allow-fs-read/--allow-fs-write, avoid wildcard grants placed as the sole root-level rule; prefer explicit directory prefixes without ambiguous wildcards. Combine application allowlists with OS confinement such as SELinux or container filesystem restrictions . Workaround: Use only canonical IPv4 literals or DNS names …

🔗 References (16)