Vitess vttablet /twopcz Reflected XSS Exposes Debug Endpoints on All Released Versions

What happened

A security report submitted to [email protected] on 2026-06-24 identifies a reflected cross-site scripting (XSS) flaw in the twopczHandler function in go/vt/vttablet/tabletserver/twopcz.go (line 185). The handler reflects the Action and dtid form values directly into the HTML response via fmt.Fprintln(w, msg) without HTML-escaping. Because Vitess's default acl policy is allow-all, the /twopcz endpoint on the vttablet HTTP port (default 15999, multiplexed with gRPC/MySQL traffic) is reachable without authentication by default.

The reporter confirms the bug has existed since before v20.0.0 and remains present in every released version through v24.0.1. A fix (commit 3140c1846c, PR #20255, HTML-escaping the reflected values) merged to Vitess's main branch on 2026-06-09, but as of the report date no released version — and at time of this writing, no official GHSA/CVE/OSV record was cross-referenced by the reporter as of 2026-06-24 — contains the backport. The item is tracked here under CVE-2026-104252 with a reported CVSS of 9.8, though the reporter's own CVSS 3.1 vector in the submission calculates to 7.7 (High); treat the exact score as unconfirmed pending official triage.

Why it matters

This is a same-origin XSS chain, not a standalone cosmetic bug. A successful injection executes in the operator's browser within the vttablet's own origin, giving the attacker's script access to other unauthenticated debug endpoints on that same host: /queryz (live query plans), /querylogz (recent queries with bound values), /txlogz (transaction logs), /debug/env (environment variables, which may include MySQL and topology credentials), /debug/vars, and /debug/pprof/* if enabled. Any organization running vttablet with default ACL settings and an operator who can be induced to click a crafted link is exposed to credential and query-data leakage. This affects any deployment of vitess.io/vitess across the versions enumerated in the report, since no patched release currently exists.

What defenders should do now

• Inventory vttablet deployments and confirm whether the HTTP debug port (default 15999) is reachable by anyone other than localhost or a tightly controlled operator network.
• Check whether a non-default acl policy is configured; the allow-all default is the root condition that makes this exploitable without authentication.
• Restrict or firewall the vttablet HTTP port to localhost/trusted admin networks, or front it with a reverse proxy enforcing a strict client allowlist, until a patched release is available.
• For hunting, review access logs on the vttablet HTTP port for requests to /twopcz containing suspicious Action or dtid parameter values (encoded <script>, onerror=, or similar HTML/JS fragments), and watch for anomalous outbound requests originating from operator browser sessions against /debug/env or other debug endpoints shortly after visiting a vttablet-hosted link.
• Track upstream for a backported fix across the v20.0.x, v22.0.x, v23.0.x, and v24.0.x branches — the reporter notes the fix is a minimal one-line change already merged to main.

Developing intel

This is based on a single security report and has not yet been independently verified against an official vendor advisory or patch release at the time of writing; treat version-specific and scoring details as provisional pending confirmation. For the full technical write-up, proof-of-concept, and reporter details, see the original GitHub Security Advisory.