CVE-2026-42338: ip-address: XSS in Address6 HTML-emitting methods
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.1.1, Address6.group() and Address6.link() do not HTML-escape attacker-controlled content before embedding it in the HTML strings they return, and AddressError.parseMessage (emitted by the Address6 constructor for invalid input) can contain unescaped attacker-controlled content in one branch. An application that (1) passes untrusted input to Address6 and (2) renders the output of these methods, or the thrown error's parseMessage, as HTML (e.g. via innerHTML) is vulnerable to cross-site scripting. This vulnerability is fixed in 10.1.1.
Security readout for executives and security teams
Plain-English summary
A widely used JavaScript library called ip-address can pass attacker-supplied text into web pages without safely escaping it. If an application feeds untrusted input into the library and then displays the result as HTML, an attacker can inject scripts that run in a user's browser, potentially stealing sessions or altering the page.
Executive priority
Treat as a prompt patching item, not an emergency. CVSS 8.1 with no confirmed active exploitation, but the ip-address package is common in Node.js stacks and multiple Red Hat products already have vendor fixes. Schedule remediation in the current sprint and prioritize customer-facing web assets.
Technical view
In ip-address before 10.1.1, Address6.group() and Address6.link() return HTML strings that embed unescaped, attacker-controlled content. One branch of AddressError.parseMessage, thrown by the Address6 constructor for invalid input, also carries unescaped input. Applications that render these outputs via innerHTML or similar sinks are exposed to reflected or stored XSS (CWE-79). Fixed in version 10.1.1.
Likely exposure
Web applications, admin consoles, and dashboards that use ip-address to format IPv6 output and then insert the result into the DOM as HTML. Node.js services echoing Address6 errors back to browsers without escaping are also exposed. Red Hat has shipped errata for multiple products, indicating downstream exposure across the ecosystem.
Exploitation context
Not listed in CISA KEV and no public in-the-wild exploitation is cited in the bundle. Exploitation requires an application path that passes untrusted input to Address6 and renders the affected methods' output or error text as HTML. User interaction is required per CVSS (UI:R), but the attack is network-reachable with no privileges. Impact is standard XSS: session theft, UI tampering, and pivoting.
Researcher notes
Confirm whether your application reaches the vulnerable sinks: Address6.group(), Address6.link(), or the specific parseMessage branch. Static usage may exist without a DOM sink, in which case risk is low. Because Red Hat published a broad set of RHSA errata (33xxx-36xxx range) and a CSAF VEX file, map your Red Hat SBOM inventory against those advisories to catch bundled copies inside container platforms and middleware.
Mitigation direction
Upgrade ip-address to 10.1.1 or later across all direct and transitive dependencies.
Apply Red Hat RHSA errata for affected products such as RHSA-2026:35842, 35841, 35892, and 34374.
Where upgrade is delayed, HTML-escape any Address6 output before passing to innerHTML sinks.
Avoid rendering AddressError.parseMessage directly to users; sanitize or use textContent instead.
Add or tighten a Content Security Policy that blocks inline script execution as defense in depth.
Validation and detection
Run npm ls ip-address (and yarn/pnpm equivalents) to find every version resolved in your builds.
Grep for Address6, .group(, .link(, and parseMessage usage in application code and vendored bundles.
Confirm fixed version 10.1.1+ is deployed in production images and container layers.
Review affected Red Hat product inventory against RHSA advisories and the CSAF VEX document.
Test known XSS payloads against IPv6 input fields in a controlled environment to confirm remediation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-79: User-session and phishing behavior lookup
Client-side and session-facing weaknesses should be reviewed alongside initial-access and user-execution behaviors. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-79 · source CWE mapping
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.