CVE-2026-104252 in Vitess
Summary
by MITRE • 10/14/2026
Vitess is a database clustering system for horizontal scaling of MySQL. Prior to 23.0.5 and 24.0.2, twopczHandler in go/vt/vttablet/tabletserver/twopcz.go writes the Action and dtid form values from the vttablet and vtcombo /twopcz HTTP debug endpoint into a text/html response without HTML escaping. Under the default allow-all ACL policy, a remote unauthenticated attacker can send an operator a crafted request that executes script in the operator's browser after the request is opened. The script runs with the vttablet debug origin and can read same-origin diagnostic endpoints that expose query, transaction, environment, variable, or profiling data available in that deployment. This issue is fixed in versions 23.0.5 and 24.0.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
Vitess serves as a critical database clustering system designed to facilitate the horizontal scaling of MySQL deployments across distributed environments. Within this architecture, vttablet components manage individual shards or tablets, exposing various diagnostic endpoints for operational monitoring and debugging purposes. One such endpoint is the /twopcz HTTP debug interface, which handles two-phase commit operations involving Action and dtid form values. Prior to versions 23.0.5 and 24.0.2, this handler exhibited a significant input validation deficiency by writing these user-supplied parameters directly into an HTML response body without performing any necessary HTML escaping or sanitization procedures. This technical flaw constitutes a classic Stored Cross-Site Scripting vulnerability where malicious payloads embedded in the request are persisted within the server's response structure rather than being dynamically injected during rendering, thereby ensuring that every subsequent access to this endpoint triggers the execution of the embedded code.
The operational impact of this vulnerability is severe due to the default configuration settings often found in development or internal testing environments. Under the default allow-all Access Control List policy, which permits unauthenticated access to diagnostic tools for convenience, a remote attacker can craft specific HTTP requests containing malicious JavaScript payloads within the Action or dtid parameters. When an operator with administrative privileges views this response through their browser, the script executes automatically in the context of the vttablet debug origin. This execution environment grants the injected code significant power because it operates under the same-origin policy relative to other sensitive diagnostic endpoints exposed by the vttablet service. Consequently, the malicious script can programmatically access and exfiltrate data from these internal endpoints without triggering cross-domain restrictions that would typically apply in public-facing web applications.
The scope of compromised data includes highly sensitive operational intelligence such as active SQL queries, transaction states, environment variables, configuration settings, and profiling metrics. This information leakage poses a substantial risk to database security and integrity. Attackers can leverage the extracted query logs to understand application logic, identify potential injection points in upstream applications, or discover table structures that facilitate further exploitation attempts. Furthermore, access to environment variables may reveal internal network configurations, authentication tokens, or connection strings for backend databases, effectively allowing an unauthenticated remote actor to map the entire infrastructure and potentially escalate privileges within the database cluster. The ability to read profiling data also aids in performance analysis by adversaries seeking to identify bottlenecks or specific high-value transactions worth targeting with subsequent attacks such as SQL injection or denial-of-service efforts.
To mitigate this vulnerability, organizations must immediately upgrade their Vitess deployments to version 23.0.5 or later for the v23 branch and version 24.0.2 or later for the v24 branch. These releases implement proper output encoding mechanisms that ensure special characters in user-supplied input are escaped before being rendered into HTML responses, thereby neutralizing any embedded script tags. In addition to upgrading software components, it is imperative to review and restrict access control policies on diagnostic endpoints. The default allow-all ACL policy should be replaced with a restrictive configuration that limits access to the /twopcz endpoint and other debug interfaces exclusively to trusted internal IP addresses or authenticated administrative users. This principle of least privilege ensures that even if similar vulnerabilities exist in future releases, they cannot be exploited by remote unauthenticated attackers.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting and specifically falls under the category of Stored XSS due to the persistence of the payload within server-generated responses. In terms of adversary tactics, this flaw facilitates initial access and credential harvesting techniques documented in the MITRE ATT&CK framework, particularly those related to Collection via Browser-based Exfiltration or Data from Information Repositories. Security teams should also consider implementing Content Security Policy headers where applicable to add an additional layer of defense against script execution, although strict input sanitization remains the primary remediation strategy for this specific code-level defect. Regular auditing of debug endpoints and disabling them in production environments unless absolutely necessary further reduces the attack surface available to potential adversaries targeting Vitess-based database clusters.