CVE-2026-42502

What it actually does

The flaw is a cross-site scripting issue in the HTML parsing and rendering behavior of the Go golang.org/x/net HTML handling code. Applications that accept untrusted HTML, parse it for sanitization, and then render it back to HTML may produce an unexpected HTML tree or serialized output that differs from what the sanitizer intended. If the sanitizer makes security decisions based on the parsed tree but the rendered output is later interpreted differently by a browser, attacker-controlled markup can survive the sanitization process and execute script in a victim’s browser. The impact is primarily loss of confidentiality and integrity in the browser context of the affected application; availability impact is not expected.

Why it matters to the business

An affected application may allow attackers to inject malicious content into web pages, which can lead to account takeover, theft of session tokens or sensitive page data, unauthorized actions performed as users, phishing overlays, or tampering with displayed content. Because the affected component is a common Go networking/HTML module, the operational risk depends on whether the application uses it to process untrusted HTML before displaying it. This issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS with no observed upward trend, but exposure can still be serious for internet-facing applications that render user-supplied HTML.

How an attack unfolds

An attacker identifies a feature that accepts HTML-like input, such as comments, profile fields, rich text, message bodies, support tickets, CMS content, or imported documents. They submit crafted malformed or ambiguous HTML designed to be parsed one way by the server-side sanitizer and interpreted another way after being rendered and loaded by a browser. The application parses the attacker input using the affected Go HTML functionality, applies sanitization logic to the resulting tree, and then serializes it using Render. Due to the parser/render mismatch, the final HTML can contain executable script behavior or dangerous attributes that the sanitizer failed to remove. When another user views the affected page, the browser executes the injected script in the security context of the vulnerable application.

How to fix it

Upgrade the affected golang.org/x/net package to a version that contains the vendor fix as soon as a fixed version is available from the Go project or your distribution. Because no exact fixed version was provided in the input, track the upstream Go security advisory and update all direct and transitive uses of golang.org/x/net, especially golang.org/x/net/html. Rebuild and redeploy all affected Go applications after updating dependencies. As a mitigation, avoid relying on custom parse-then-render sanitization for untrusted HTML; use a mature allowlist-based sanitizer designed for browser output, sanitize after any transformation that can change document structure, and encode output according to context. Where rich HTML is not required, store and display user input as plain text. Add or tighten Content Security Policy controls to reduce XSS impact, such as disallowing inline scripts and restricting script sources, but do not treat CSP as a complete fix.

How to confirm the fix worked

Inventory Go applications and libraries that depend on golang.org/x/net, especially code importing golang.org/x/net/html or calling html.Parse, html.ParseFragment, or html.Render on untrusted input. Use dependency tooling such as go list -m all, go version -m on built binaries, govulncheck, and software composition analysis to identify affected versions once the advisory data is available. Confirm that rebuilt binaries include the patched module version. Functionally validate by adding regression tests for malformed HTML inputs that previously bypassed sanitization and confirming the final browser-rendered output contains no executable script, dangerous event-handler attributes, javascript: URLs, unsafe SVG/MathML behavior, or unexpected tag reconstruction. Also verify that CSP and output-encoding controls remain effective in deployed environments.

Typical attack path

1. Find an application endpoint that accepts user-controlled HTML or rich text and later displays it to other users.
2. Submit crafted malformed HTML intended to confuse server-side parse/sanitize/render logic.
3. Allow the application to parse and sanitize the content using the affected HTML processing behavior.
4. Have the application render and store or return the transformed HTML.
5. Wait for a victim user, administrator, or service operator to view the rendered content in a browser.
6. Execute JavaScript in the victim’s browser context to steal data, perform actions as the user, or alter page content.

How to detect it

To determine whether exploitation already occurred, focus on places where untrusted HTML enters the application and where rendered content is viewed. Review web access logs, application request logs, WAF logs, API gateway logs, moderation/audit logs, CMS revision history, comment or message histories, and stored rich-text content for suspicious HTML payloads. Look for malformed tags, encoded script blocks, event-handler attributes, javascript: URLs, SVG or MathML payloads, and payloads submitted shortly before an administrator or other user viewed the same content. Correlate suspicious submissions with subsequent browser-side errors, CSP violation reports, unusual outbound requests from user browsers, unexpected account setting changes, unauthorized administrative actions, or session anomalies. Because this is client-side code execution, server logs may only show the initial payload submission and any follow-on actions performed with the victim’s authenticated session.

• <script
• </script
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• <svg
• </svg
• <math
• </math
• <iframe
• srcdoc=
• data:text/html
• &#x3c;script
• &lt;script
• alert(
• document.cookie
• localStorage
• sessionStorage
• new Image().src
• fetch(
• XMLHttpRequest
• eval(
• atob(

What your security team should do

• Prioritize review of internet-facing Go applications that accept and render user-supplied HTML, rich text, Markdown with embedded HTML, CMS content, or imported HTML documents.
• Inventory all uses of golang.org/x/net/html and determine whether untrusted input is parsed, sanitized, rendered, stored, or displayed.
• Patch golang.org/x/net to the vendor-fixed release as soon as it is published, then rebuild and redeploy affected applications.
• Replace custom HTML sanitization logic with a well-maintained allowlist sanitizer and add regression tests for parser/rendering edge cases.
• Apply defense-in-depth browser controls, including a restrictive Content Security Policy, HttpOnly and SameSite cookies, and output encoding by context.
• Search historical application logs and content stores for suspicious HTML payloads, especially in fields that are later displayed to privileged users.
• Monitor Go security advisories, distribution advisories, and SCA tooling for the exact fixed version and update guidance.