Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
CRITICAL severity

CVE-2026-104252 — vitess

CRITICALFix: vitessio/vitess@3140c18

CVE-2026-104252 is a critical-severity (CVSS 9.8) Cross-site Scripting (XSS) vulnerability in vitess.io/vitess. A fix is available for vitess.io/vitess — see the affected versions and patch details below.

Vitess vttablet /twopcz reflected XSS

Also known asGHSA-v75v-6fpf-gvw8
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-104252.

EPSS Exploitation Probability

via FIRST.org ↗
0.9%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs59th percentile — riskier than 59% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-104252 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected
🐹vitess.io/vitess🐹vitess.io/vitess

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

From: xylove21 To: [email protected] Subject: [Security Report] Vitess vttablet /twopcz reflected XSS Date: Tue, 24 Jun 2026 14:30:00 +0800

Summary

The twopczHandler in go/vt/vttablet/tabletserver/twopcz.go (line 185) reflects the Action and dtid form values directly into the HTML response body via fmt.Fprintln(w, msg) — without HTML escaping. The response is served as text/html; charset=utf-8, and Vitess's default acl policy is allow-all, so the endpoint is reachable by anyone who can hit the vttablet's HTTP port (default 15999, multiplexed with gRPC and MySQL wire-protocol ports).

A crafted Action or dtid value yields a reflected XSS that executes in the operator's browser with same-origin access to the vttablet's debug endpoints. This includes /queryz (live query plans), /querylogz (recent queries with bound values), /txlogz (transactions), /debug/env (environment variables — may include MySQL/topology credentials), /debug/vars (expvar stats), and /debug/pprof/* if enabled.

The bug was introduced before v20.0.0 (long-standing) and was silently fixed in commit 3140c1846c (merged 2026-06-09, PR #20255, "tabletserver: escape reflected form values in twopcz handler"). The fix replaces fmt.Fprintln(w, msg) with fmt.Fprintln(w, html.EscapeString(msg)). No released version of Vitess contains the fix — the fix lives only on main (current tip 33a3c0fafe69, 2026-06-23). There is no CVE, GHSA, or OSV entry for this specific bug (verified 2026-06-24 against GitHub Advisory Database, OSV.dev, and NVD).

Impact

FieldValue
TypeReflected Cross-Site Scripting (XSS)
CVSS 3.1AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N = 7.7 HIGH
Attack VectorNetwork (vttablet HTTP port 15999, multiplexed with gRPC/MySQL)
Attack ComplexityLow (craft URL, send to operator)
Privileges RequiredNone (default acl policy is allow-all)
User InteractionRequired (operator must visit crafted URL)
ScopeChanged (XSS chain reaction to other vttablet debug endpoints)
ConfidentialityHigh (query text, env vars, expvar stats)
IntegrityNone (XSS itself doesn't change state)
AvailabilityNone (XSS itself doesn't disrupt service)

Affected versions (verified)

All released versions are vulnerable. The fix lives only on main:

TagReleasedtwopcz.go line 185Status
v20.0.02024-06-27fmt.Fprintln(w, msg)BUGGY
v20.0.1 - v20.0.62024fmt.Fprintln(w, msg)BUGGY
v22.0.42026-02-27fmt.Fprintln(w, msg)BUGGY
v23.0.3, v23.0.42026-02 / 2026-05fmt.Fprintln(w, msg)BUGGY
v24.0.0, v24.0.12026-04 / 2026-05fmt.Fprintln(w, msg)BUGGY
main (33a3c0fafe69)2026-06-23fmt.Fprintln(w, html.EscapeString(msg))FIXED

Sensitive data exposed via the same-origin XSS chain

A successful XSS lands in the vttablet's origin. From there, the attacker can fetch (via fetch() from injected JavaScript) the following same-origin endpoints, all of which are unauthenticated by default:

  • /twopcz — in-flight 2PC transactions (query text, parameters, dtid)
  • /queryz — live query plans
  • /querylogz — recent queries with bound values
  • /txlogz — transactions
  • /debug/env — environment variables (may include MySQL creds, topology credentials, encryption keys)
  • /debug/vars — expvar stats
  • /debug/pprof/* — CPU/memory profiles (if enabled)

Reproduction (independent, runnable PoC)

The PoC is a self-contained Go HTTP server that replicates the buggy twopczHandler from Vitess v20.0.0 verbatim (using the same line-185 code). It runs on 127.0.0.1:15080 and returns the same response shape as the real Vitess endpoint.

# 1) Build the PoC (Go 1.23+)
cd /path/to/finding/CVE-pending-twopcz-xss
go build -o /tmp/vitess-twopcz-poc ./poc.go

# 2) Start the buggy server
ADDR=127.0.0.1:15080 /tmp/vitess-twopcz-poc &

# 3) Reproduce — Test 1: bare GET (no params)
curl -sS -i "http://127.0.0.1:15080/twopcz"
# → Content-Type: text/html; charset=utf-8, status 200

# 4) Test 2: XSS via Action param (URL-encode the script tag)
curl -sS -i "http://127.0.0.1:15080/twopcz?Action=%3Cscript%3Ealert(1)%3C%2Fscript%3E&dtid=zz"
# → Response body contains literal "<script>alert(1)</script>(zz): completed."
# → Browser executes the script as same-origin code

# 5) Test 3: XSS via dtid param (attribute-context payload)
curl -sS -i "http://127.0.0.1:15080/twopcz?Action=Demo&dtid=%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E"
# → Response body contains literal "<img src=x onerror=alert(1)>"
# → Browser fires the onerror handler as same-origin code

# 6) Run the 3x automated runner (writes evidence/run-{1,2,3}.log)
bash ./poc/run.sh

PoC result excerpt (from evidence/run-1.log):

--- Test 2: XSS via Action=<script>alert(1)</script> ---
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
...
<h2>WARNING: Actions on this page can jeopardize data integrity.</h2>
<script>alert(1)</script>(zz): completed.

PASS: payload reflected UNESCAPED (XSS exploitable in browser)

The PoC was run 3 times on the buggy server (all 3/3 PASS) and the same code is byte-identical to the v20.0.0 commit 8aeb274f6c8e line 185.

Root cause (technical detail)

go/vt/vttablet/tabletserver/twopcz.go (v20.0.0 through v24.0.1):

// Line 185
fmt.Fprintln(w, msg)

msg is constructed earlier in the handler as:

msg := fmt.Sprintf("%s(%s): completed.", action, dtid)

with action and dtid coming from the form values r.FormValue("Action") and r.FormValue("dtid"). The form values are URL-decoded (so a + becomes a space, %3C becomes <) but never HTML-escaped. The handler explicitly sets Content-Type: text/html; charset=utf-8 (via the <!DOCTYPE html> it writes first), so the browser executes any injected <script> or attribute-context payload.

The fix in main (fmt.Fprintln(w, html.EscapeString(msg))) closes the hole by HTML-escaping both action and dtid before reflection.

Suggested fix (already in main)

// Recommended minimal patch (already in main, needs backport to all release branches):
import "html"

func twopczHandler(w http.ResponseWriter, r *http.Request) {
    // ... existing logic ...
    msg := fmt.Sprintf("%s(%s): completed.", action, dtid)
    fmt.Fprintln(w, html.EscapeString(msg))  // ← was: fmt.Fprintln(w, msg)
}

Backport the fix to v20.0.x, v22.0.x, v23.0.x, and v24.0.x as patch releases. The fix is one line and a one-line import "html" addition, so the backport risk is minimal.

Workaround / mitigation (no patch available)

If you cannot upgrade to a fixed release immediately:

  1. Restrict the vttablet HTTP port (default 15999) to localhost only. vttablet can run with --tablet-allow-stats=false and --tablet-grpc-port configured separately from the HTTP port, or you can firewall the HTTP port at the network layer. The debug endpoints are not needed by production traffic.

  2. Set a non-default ACL policy. Vitess supports an acl policy that defaults to allow-all. Setting it to a JSON file that denies unauthenticated access to debug endpoints (see go/acl/acl.go::savePolicy) would block the XSS, but the default policy is currently "" (allow-all) and many users don't override it.

  3. Use a reverse proxy (nginx, envoy) in front of the vttablet HTTP port with a strict allowlist of clients.

Cross-references

  • The bug is not related to:
    • CVE-2024-53257 (/debug/querylogz HTML injection, fixed in v20.0.4 — different endpoint)
    • CVE-2026-27969 (backup MANIFEST path traversal)
    • CVE-2026-27965 / GHSA-8g8j-r87h-p36x (backup external decompressor RCE)
  • PR #20255 is the fix commit; PR #19486 (defense-in-depth) is a separate hardening change

Contact

  • GitHub: @xylove21

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐹Govitess.io/vitessall versions0.23.5go get vitess.io/vitess@v0.23.5
🐹Govitess.io/vitess≥ 0.24.0&&< 0.24.20.24.2go get vitess.io/vitess@v0.24.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vitess.io/vitess, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update vitess.io/vitess to 0.23.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-104252 is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

From: xylove21 To: [email protected] Subject: [Security Report] Vitess vttablet /twopcz reflected XSS Date: Tue, 24 Jun 2026 14:30:00 +0800 ## Summary The `twopczHandler` in `go/vt/vttablet/tabletserver/twopcz.go` (line 185) reflects the `Action` and `dtid` form values directly into the HTML response body via `fmt.Fprintln(w, msg)` — **without HTML escaping**. The response is served as `text/html; charset=utf-8`, and Vitess's default `acl` policy is **allow-all**, so the endpoint is reachable by anyone who can hit the vttablet's HTTP port (default `15999`, multiplexed with gRPC and MySQL wi
O3 Security · Impact-Aware SCA

Is CVE-2026-104252 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-104252: vitess RCE — Fixed in 0.23.5