Cloudanix VulnDB

CVE-2026-32289

Medium · 6.1

CVSS

6.1

EPSS

0.3%

Published

Apr 8, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some Go-based websites may accidentally turn user-supplied text into browser code, letting attackers act through a victim's session if the victim opens a crafted page.

Exploitation
Requires User Interaction
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
Library
Class
XSS
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This vulnerability affects Go's template escaping behavior when using JavaScript template literals in templates. The template engine may lose track of escaping context across conditional or branching template paths, and may also mis-handle brace depth inside JavaScript template literal expressions. As a result, data that should be safely escaped for a JavaScript context may be emitted with insufficient or incorrect escaping. If attacker-controlled input reaches one of these affected template locations, it can become executable script in the victim's browser, resulting in cross-site scripting. The CVSS characteristics indicate network exploitability, low attack complexity, no required attacker privileges, and required user interaction, with impact primarily to confidentiality and integrity in the user's browser session.

Why it matters to the business

Applications built with affected Go template functionality may unintentionally expose users to browser-based attacks when rendering untrusted content inside JavaScript template literals. Successful exploitation can allow attackers to run script in a user's browser, steal session data or sensitive page content, perform actions as the user, alter displayed content, or pivot into broader account abuse depending on the application's permissions model. The current EPSS score is low and stable, the issue is not listed in CISA KEV, and no exploit maturity is reported, so broad active exploitation is not currently indicated; however, the impact can still be significant for internet-facing applications that render user-supplied data into JavaScript-heavy pages.

How an attack unfolds

An attacker first identifies a Go-based web application that renders user-controllable values through templates containing JavaScript template literals, especially templates using backtick-delimited JavaScript strings, embedded template actions, conditionals, ranges, or other branching constructs. The attacker submits crafted input designed to break out of the intended JavaScript string or expression context after the template engine applies incorrect escaping. A victim then views a page that includes the rendered template. Because the escaping context was tracked incorrectly, the attacker's payload is interpreted by the browser as JavaScript rather than inert text. The injected script executes in the victim's browser under the vulnerable application's origin, allowing the attacker to read accessible page data, interact with the application as the victim, exfiltrate tokens or non-HttpOnly cookies where available, or perform unauthorized state-changing actions through the user's session.

How to fix it

Upgrade Go to a version that includes the vendor fix for this vulnerability when available for the affected release line. Because no fixed version was provided in the input, consult official Go security advisories and release notes for the exact corrected versions before deploying. Rebuild and redeploy all applications compiled with affected Go toolchains or using affected standard-library template behavior. As an immediate mitigation, review templates that render untrusted data inside JavaScript template literals and refactor them to avoid placing user-controlled values directly inside backtick-delimited JavaScript strings or JavaScript expressions. Prefer passing data as JSON generated by a safe encoder, using data attributes or script tags with safely serialized JSON, and consuming those values from client-side code. Avoid marking untrusted data as trusted template types such as safe JavaScript, HTML, or URL content. Apply a restrictive Content Security Policy that disallows inline script where feasible, uses nonces or hashes, and limits script sources; CSP should be treated as defense-in-depth, not a substitute for patching.

How to confirm the fix worked

Confirm the installed Go version against the official fixed versions once published, and verify that all deployed services have been rebuilt with a fixed Go toolchain. Inventory server-rendered templates and search for JavaScript template literals containing Go template actions, conditionals, ranges, or user-controlled values. Review code paths where request parameters, stored user content, or external data are rendered into JavaScript contexts. Use dynamic testing with benign XSS probes containing backticks, interpolation markers, braces, and quote-breaking sequences to confirm the rendered output remains inert text and does not execute. Validate that CSP is present and effective by checking response headers and browser console enforcement. In CI/CD, add regression tests for templates that render untrusted values in JavaScript contexts and assert the exact escaped output.

Typical attack path

  1. Find a Go web application that uses affected template rendering paths and includes JavaScript template literals in server-rendered pages.
  2. Identify input fields, URL parameters, profile fields, comments, names, labels, or other user-controlled values that are reflected into those templates.
  3. Craft payloads using JavaScript template literal syntax, braces, backticks, interpolation markers, or branch-dependent content to trigger incorrect escaping.
  4. Store or deliver the payload through a reflected URL, stored application field, or user-generated content path.
  5. Induce a victim to load the affected page or wait for users/admins to view the stored content.
  6. Execute JavaScript in the victim's browser under the trusted application origin.
  7. Use the browser context to steal accessible data, perform unauthorized actions, or modify page content.

How to detect it

To determine whether exploitation already occurred, review web access logs, application logs, WAF events, reverse-proxy logs, and stored-content audit logs for XSS payloads that use JavaScript template literal syntax. Focus on parameters or content fields that are later rendered into server-side templates. Look for encoded or raw backticks, dollar-brace interpolation sequences, nested braces, common JavaScript execution functions, event-handler attributes, script tags, and attempts to close or escape out of JavaScript string contexts. For stored XSS risk, inspect recent user-generated content, profile fields, comments, names, labels, and rich-text fields for payloads containing template literal syntax or script execution patterns. Browser-side exploitation may not leave a direct server artifact beyond the original payload delivery and subsequent victim requests, so also review authentication logs, session telemetry, CSRF-sensitive actions, profile or email changes, administrative actions, and unusual API calls shortly after suspicious page views. If CSP reporting is enabled, review CSP violation reports for blocked inline script execution, unexpected script sources, or eval-like behavior associated with pages rendered by Go templates.

  • %60%24%7B
  • `$\{
  • ${alert(
  • ${confirm(
  • ${prompt(
  • ${fetch(
  • ${eval(
  • ${Function(
  • </script>
  • %3C/script%3E
  • <script
  • %3Cscript
  • onerror=
  • onload=
  • javascript:
  • document.cookie
  • localStorage
  • sessionStorage
  • new Image().src
  • fetch(`
  • fetch('
  • fetch("
  • String.fromCharCode(
  • atob(
  • eval(atob(
  • <img src=x onerror=
  • <svg onload=

What your security team should do

  • Prioritize internet-facing Go applications that render server-side HTML and include JavaScript template literals in templates.
  • Track the official Go advisory and patch all affected Go installations and build images as soon as fixed versions are available.
  • Rebuild and redeploy affected applications after upgrading the Go toolchain; runtime patching alone may not update already-built binaries.
  • Perform targeted code review for backtick-delimited JavaScript strings in templates, especially where template branches or embedded actions are present.
  • Temporarily refactor high-risk templates to avoid untrusted data inside JavaScript template literals until patching is complete.
  • Add or tighten Content Security Policy controls to reduce the impact of any residual XSS.
  • Search application logs and WAF telemetry for JavaScript template literal XSS probes and unusual reflected/stored input containing backticks, interpolation markers, and script execution functions.
  • Increase monitoring for account abuse, suspicious session activity, and anomalous administrative actions that could follow successful browser-session compromise.

The record

Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied. These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Leap 16.0 go1.25 0 1.25.9-160000.1.1
openSUSE:Leap 16.0 go1.26 0 1.26.2-160000.1.1
openSUSE:Tumbleweed go1.25 0 1.25.9-1.1
openSUSE:Tumbleweed go1.26 0 1.26.2-1.1

Related vulnerabilities