Vitess Debug Endpoint XSS Allows Script Execution in Operator Browsers

A remote attacker can force security operators to execute arbitrary scripts simply by opening a crafted link, according to the National Vulnerability Database record for CVE-2026-104252. This cross-site scripting flaw in the Vitess database clustering system allows adversaries to bypass standard authentication requirements. The vulnerability exists within the /twopcz HTTP debug endpoint of vttablet and vtcombo services.

By sending a malicious request, an attacker can inject code that runs with the privileges of the debug interface. This gives them access to same-origin diagnostic endpoints that reveal query logs, transaction details, environment variables, and profiling data. The exploit works because the system fails to escape HTML input before rendering it in the browser.

In plain English

The Vitess system provides a debug page intended for internal troubleshooting. This page accepts input from users to display diagnostic information. However, it does not sanitize the data it receives. If a user enters special characters or script commands, the system displays them as active code rather than plain text. An attacker can create a link that contains these malicious scripts. When a database administrator or operator clicks the link, their browser executes the hidden code. This happens within the context of the Vitess debug interface, granting the script access to sensitive internal data.

The background

Vitess is designed to help organizations scale MySQL databases horizontally. It manages clusters of database servers to handle large volumes of data. The twopczHandler component processes requests related to two-phase commit transactions. This specific handler is part of the vttablet and vtcombo services. The vulnerability was present in versions older than 23.0.5 and those in the 24.0.0 series before 24.0.2. The National Vulnerability Database assigns this issue a CVSS score of 9.8, indicating a critical severity level. The weakness is classified under CWE-79, which covers improper neutralization of input during web page generation.

What changes now

The Vitess development team has released patches to address this cross-site scripting vulnerability. Versions 23.0.5 and 24.0.2 contain the necessary fixes to properly escape HTML output. Users running affected versions should upgrade to these patched releases immediately. The fix ensures that form values submitted to the debug endpoint are treated as text rather than executable code. This prevents the injection of malicious scripts into the browser session. Organizations relying on Vitess for database scaling need to verify their current version numbers against the affected range.

What made it possible

Cross-site scripting flaws typically arise when applications trust user input without validation. In this scenario, the debug endpoint treated external data as safe content. This weakness serves the initial access stage of an intrusion, allowing attackers to pivot from a simple link click to active code execution. Teams usually encounter these issues in administrative interfaces that lack strict output encoding. Check whether your debug endpoints sanitize all dynamic content before rendering. Ensure that input fields cannot inject scripts that run in the context of the application. This kind of oversight often exposes internal diagnostics to unauthorized parties.

Background: Cross-site scripting (XSS)

Cross-site scripting injects malicious scripts into trusted sites to steal data from the victim. Cross-site request forgery tricks the victim’s browser into performing unwanted actions on a site where they are authenticated. XSS targets confidentiality; CSRF targets integrity.

Read the full guide: Cross Site Scripting vs CSRF: How to Tell Them Apart and Stop Both

What to do and how to stay safe: Vitess

• Verify your current Vitess version and upgrade to 23.0.5 or 24.0.2 if you are running an affected release.
• Restrict access to debug endpoints like /twopcz using firewall rules or strict access control lists, disabling the default allow-all policy.
• Monitor browser logs and network traffic for unexpected script executions or requests to diagnostic endpoints from unauthorized sources.
• Review all custom or third-party debug interfaces for similar input validation issues, ensuring all output is properly escaped.

Step-by-step guide: Automatic Updates Mistakes That Leave Systems Exposed

General security guidance from the RedTeam Monitor newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Vitess are affected by CVE-2026-104252?

The vulnerability affects Vitess versions prior to 23.0.5 and versions 24.0.0 up to 24.0.2.

Do attackers need credentials to exploit this flaw?

No, the National Vulnerability Database states that remote unauthenticated attackers can exploit this issue under the default allow-all ACL policy.

What data can an attacker access through this vulnerability?

An attacker can access same-origin diagnostic endpoints that expose query, transaction, environment, variable, or profiling data.