CVE-2026-39826

What it actually does

This is a cross-site scripting issue in Go template handling involving trusted template authors who create a <script> tag with an empty type attribute, or a type attribute containing ASCII whitespace. In that edge case, data passed into the script block can be escaped incorrectly, potentially allowing attacker-controlled content rendered through the template to execute in a user’s browser. The CVSS vector indicates network reachability, low attack complexity, no attacker authentication requirement, required user interaction, and a changed scope because successful exploitation affects the browser security context of users consuming the rendered page.

Why it matters to the business

Applications that render HTML using affected Go template behavior may expose users to browser-based compromise if vulnerable templates include the specific malformed script type pattern and render untrusted data into the script block. Business consequences can include session theft, unauthorized actions performed as users, data exposure visible to the victim, defacement, phishing within the trusted application, and loss of user trust. The current public exploitation signal is low: EPSS is 0.00371 with no 30-day increase, it is not listed in CISA KEV, is not associated with ransomware, and no mature exploit is reported; however, internet-facing applications using affected Go versions should still be reviewed because XSS issues are often easy to weaponize once a vulnerable rendering path is identified.

How an attack unfolds

An attacker first identifies a web application that renders HTML using affected Go template behavior and includes a script tag authored with an empty type attribute, such as <script type="">, or a type attribute containing only ASCII whitespace. The attacker then finds an input field, URL parameter, stored profile value, comment, name, metadata field, or other data source that is inserted into that script block. Because the template engine handles escaping incorrectly in this edge case, the attacker crafts a payload that survives template rendering and is interpreted by the victim’s browser as executable script. The attacker then delivers the malicious content by storing it in the application, sending a crafted link, or otherwise causing a victim to view the affected page. When the victim opens the page, the browser executes the injected script in the context of the trusted site, allowing theft of page data, session-related tokens accessible to JavaScript, user impersonation actions, or redirection to malicious content.

How to fix it

Upgrade Go to a version that includes the upstream fix once available from the Go project or the relevant operating system/package distribution. Because no fixed versions were provided in the input, track the official Go security advisories and vendor package channels for corrected releases. Rebuild and redeploy all Go applications that render HTML/templates after upgrading the toolchain or standard library dependency. As compensating controls, review templates for <script> tags with empty type attributes or type attributes containing only ASCII whitespace and change them to either omit the type attribute entirely for JavaScript, use a valid JavaScript MIME type consistently, or avoid rendering untrusted data inside script blocks. Prefer external JavaScript files with data passed through safe JSON serialization, strict contextual escaping, and Content Security Policy controls that block inline script execution where feasible.

How to confirm the fix worked

Confirm the Go version used to build affected applications has been updated to a fixed release when available, then rebuild binaries and redeploy them. Search application templates for risky script tags, including empty type attributes and whitespace-only type attributes. Test representative pages by injecting harmless XSS probe strings into fields that are rendered into script blocks and verify the output is safely encoded and does not execute. Browser developer tools, automated dynamic application security testing, and unit tests around template rendering can validate that untrusted data remains inert. Also verify that Content Security Policy is applied and, where possible, blocks inline script execution or requires nonces/hashes.

Typical attack path

1. Identify an application built with affected Go template functionality that renders HTML pages containing <script> tags with an empty or whitespace-only type attribute.
2. Locate an input path whose value is rendered into the affected script block.
3. Craft a JavaScript or HTML-breaking payload that takes advantage of the incorrect escaping behavior.
4. Deliver the payload through a reflected URL, stored application content, or another user-controlled field.
5. Trick or wait for a target user to open the vulnerable rendered page.
6. Execute script in the victim’s browser under the trusted application origin.
7. Use the browser execution context to steal accessible data, perform actions as the user, alter page content, or redirect the user.

How to detect it

To assess prior exploitation, review web access logs, WAF logs, application request logs, reverse proxy logs, and any client-side error reporting or Content Security Policy violation reports for XSS probes targeting pages that render Go templates. Focus on requests containing script-breaking sequences, encoded JavaScript, event-handler attributes, HTML closing tags followed by script tags, and suspicious payloads in parameters or stored content later rendered to users. In source and template repositories, identify pages containing <script type=""> or <script type=" "> patterns and correlate access to those pages with suspicious input submissions. If CSP reporting is enabled, look for blocked inline script execution, unexpected script-src violations, or connections to unfamiliar domains immediately after users accessed affected pages. For stored-XSS scenarios, examine application audit logs for edits to user-generated content containing script-like payloads, then identify downstream users who viewed the affected content. Browser telemetry, EDR web protection logs, and proxy logs may show follow-on requests to attacker-controlled domains, credential collection endpoints, or unusual redirects after viewing vulnerable pages.

• <script type="">
• <script type=" ">
• <script type=''>
• <script type=' '>
• ></script><script>
• %3C%2Fscript%3E%3Cscript%3E
• <script>alert(
• %3Cscript%3Ealert%28
• javascript:alert(
• onerror=alert(
• onload=alert(
• document.cookie
• fetch(document.cookie
• new Image().src
• eval(atob(
• String.fromCharCode(
• script-src
• violated-directive: script-src
• blocked-uri: inline

What your security team should do

• Inventory Go-based web applications that render HTML using Go templates, prioritizing internet-facing and authenticated high-value applications.
• Search source repositories and compiled template assets for <script> tags with empty or whitespace-only type attributes.
• Upgrade to the fixed Go release as soon as it is available from upstream or OS/package vendors, then rebuild and redeploy affected applications.
• Prioritize remediation for applications that render user-controlled data into script blocks or support stored user-generated content.
• Add regression tests for template rendering around script contexts and user-controlled data.
• Deploy or tighten Content Security Policy to reduce the impact of inline script execution.
• Monitor web logs, application logs, and security tooling for XSS probing and suspicious encoded script payloads.
• Because EPSS is low, not in KEV, and no mature exploit is reported, handle through normal vulnerability remediation processes unless vulnerable templates are confirmed in exposed applications.