CVE-2026-42338

What it actually does

This is a reflected or stored cross-site scripting vulnerability in the JavaScript ip-address library before version 10.1.1. The affected Address6.group(), Address6.link(), and one AddressError.parseMessage code path can place attacker-controlled IPv6-related input into returned HTML or error-message strings without HTML escaping. If an application passes untrusted input into Address6 and then renders those returned strings as HTML, such as with innerHTML or an equivalent unsafe sink, attacker-supplied JavaScript can execute in a user's browser. The flaw does not directly provide server-side code execution; impact depends on how the consuming application displays the library output.

Why it matters to the business

Applications using vulnerable versions of the ip-address package may expose users or administrators to browser-based account compromise, data theft, session abuse, unauthorized actions, or phishing within a trusted application. The risk is highest where untrusted users can submit IPv6 address values that are later rendered in web pages, dashboards, validation errors, logs, reports, or admin consoles. Although this issue is not in the CISA KEV catalog, has low current EPSS, and has no reported mature public exploit in the provided data, the package is a reusable library and vulnerable patterns may be present across many downstream applications.

How an attack unfolds

An attacker first identifies an application feature that accepts IPv6 address input or displays IPv6 parsing results generated by the ip-address library. They then submit a crafted value containing HTML or JavaScript payload content that reaches Address6.group(), Address6.link(), or an affected AddressError.parseMessage path. If the application takes the returned string or parse error message and inserts it into a web page as HTML rather than text, the browser interprets the payload as markup or script. A victim must view the affected page or error output. Successful exploitation can allow the attacker to run JavaScript in the victim's browser in the context of the vulnerable application, enabling actions such as session theft where protections are weak, credential phishing, data extraction from the page, or unauthorized requests using the victim's privileges.

How to fix it

Upgrade the beaugunderson ip-address package to version 10.1.1 or later wherever it is used. Because this is a library flaw, update both direct and transitive dependencies by refreshing lockfiles and rebuilding affected applications and container images. If immediate upgrade is not possible, do not render Address6.group(), Address6.link(), or AddressError.parseMessage output as HTML when any portion is derived from untrusted input; render as textContent or equivalent, apply contextual HTML escaping, and sanitize output before insertion into the DOM. Avoid exposing raw parser error messages to end users. Enforce a Content Security Policy to reduce script execution impact, but do not treat CSP as a substitute for upgrading or output encoding.

How to confirm the fix worked

Confirm dependency resolution shows ip-address version 10.1.1 or later in package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, built artifacts, and container images. Search application code for use of Address6.group(), Address6.link(), AddressError.parseMessage, and unsafe HTML sinks such as innerHTML, outerHTML, insertAdjacentHTML, dangerouslySetInnerHTML, or template rendering that disables escaping. Test affected input paths with benign XSS canary payloads and verify the payload is displayed as escaped text rather than executed or interpreted as HTML. Re-run software composition analysis after dependency updates and confirm no vulnerable transitive copy remains.

Typical attack path

1. Find an application endpoint, form, API, report, or admin page that accepts or displays IPv6 address values.
2. Submit crafted IPv6-related input containing HTML or JavaScript special characters or event-handler payloads.
3. Trigger application logic that calls Address6.group(), Address6.link(), or exposes AddressError.parseMessage from the vulnerable ip-address package.
4. Cause the application to render the returned value or error message through an unsafe HTML sink such as innerHTML.
5. Wait for a user or administrator to view the affected page or error output.
6. Execute JavaScript in the victim's browser within the origin of the vulnerable application and abuse the victim's session or displayed data.

How to detect it

To determine whether exploitation already occurred, review web server, CDN, WAF, reverse proxy, and application logs for requests to IPv6 address submission or lookup endpoints containing HTML metacharacters, script tags, JavaScript event handlers, or URL-encoded equivalents. Correlate suspicious submissions with subsequent page views by other users, especially administrators, and with unusual authenticated actions shortly after those views. Inspect application error logs for Address6 parsing errors or parseMessage output that includes unescaped HTML. In browser telemetry, CSP violation reports, EDR browser events, or RUM/session replay systems, look for inline script execution, blocked script violations, unexpected outbound requests, or DOM injection after pages that render IP address data or validation errors. Because exploitation depends on application-specific rendering, there are no universal host artifacts; detection should focus on suspicious payloads in input logs and evidence of script execution in affected web pages.

• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• onerror=
• onload=
• onclick=
• javascript:
• <img
• %3Cimg
• <svg
• %3Csvg
• innerHTML
• Address6.group(
• Address6.link(
• parseMessage
• node_modules/ip-address/package.json

What your security team should do

• Inventory applications and packages that include beaugunderson ip-address, especially JavaScript front-end, Node.js, API, dashboard, logging, and admin-console components.
• Prioritize upgrading all instances of ip-address to 10.1.1 or later and rebuild/redeploy affected artifacts.
• Search code for Address6.group(), Address6.link(), and parseMessage being passed into unsafe HTML rendering sinks.
• Add regression tests that submit IPv6-like input containing HTML metacharacters and verify output is escaped.
• Review web access logs and application logs for suspicious IPv6 input containing script tags, event handlers, encoded HTML, or javascript: URLs.
• Ensure CSP, HttpOnly cookies, SameSite cookies, and anti-CSRF controls are in place to reduce XSS blast radius.
• Educate developers that library-generated strings are not automatically safe for HTML rendering when derived from untrusted input.