Summary
Vitess contains a reflected cross-site scripting vulnerability in the /twopcz HTTP debug endpoint, where attacker-controlled form values are returned in an HTML response without escaping. Under the default allow-all access policy, an unauthenticated attacker may convince an operator to open a crafted request, causing script execution that can access diagnostic data exposed by the vttablet debug origin.
Vitess contains a reflected cross-site scripting vulnerability in the /twopcz HTTP debug endpoint, where attacker-controlled form values are returned in an HTML response without escaping. Under the default allow-all access policy, an unauthenticated attacker may convince an operator to open a crafted request, causing script execution that can access diagnostic data exposed by the vttablet debug origin.
Affected context
The issue occurs in Vitess deployments that expose the vttablet or vtcombo /twopcz debug endpoint and use an access policy that permits unauthenticated requests. It is relevant when the endpoint reflects the Action or dtid form values into a text/html response without context-appropriate HTML escaping, particularly when an operator opens the resulting URL or response in a browser.
The issue occurs in Vitess deployments that expose the vttablet or vtcombo /twopcz debug endpoint and use an access policy that permits unauthenticated requests. It is relevant when the endpoint reflects the Action or dtid form values into a text/html response without context-appropriate HTML escaping, particularly when an operator opens the resulting URL or response in a browser.
Exploit preconditions
- Attack surface: The vttablet or vtcombo
/twopczHTTP debug endpoint - Required access: Ability to send requests to the endpoint; authentication may not be required under the default allow-all ACL policy
- Trigger point: An operator opens or views a crafted endpoint response in a browser
- Why exploitation is possible: User-controlled form values are reflected into an HTML response without output encoding, allowing browser-interpreted script content to execute in the debug origin
- Attack surface: The vttablet or vtcombo
/twopczHTTP debug endpoint - Required access: Ability to send requests to the endpoint; authentication may not be required under the default allow-all ACL policy
- Trigger point: An operator opens or views a crafted endpoint response in a browser
- Why exploitation is possible: User-controlled form values are reflected into an HTML response without output encoding, allowing browser-interpreted script content to execute in the debug origin
Why this happens
The vulnerability is caused by reflecting untrusted HTTP form values into an HTML response without applying context-appropriate output encoding.
This is a classic CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting. Because the browser interprets the response as HTML, attacker-controlled content can become executable script rather than remaining inert data.
The vulnerability is caused by reflecting untrusted HTTP form values into an HTML response without applying context-appropriate output encoding.
This is a classic CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting. Because the browser interprets the response as HTML, attacker-controlled content can become executable script rather than remaining inert data.
Potential impact
- An attacker may execute script in an operator's browser
- The script could read same-origin diagnostic endpoints exposed by the deployment
- Query, transaction, environment, variable, or profiling data could be disclosed
- Operator browser sessions or diagnostic workflows could be manipulated
- Sensitive operational information could be sent to an attacker-controlled destination
- An attacker may execute script in an operator's browser
- The script could read same-origin diagnostic endpoints exposed by the deployment
- Query, transaction, environment, variable, or profiling data could be disclosed
- Operator browser sessions or diagnostic workflows could be manipulated
- Sensitive operational information could be sent to an attacker-controlled destination
General mitigation guidance
Mitigation generally focuses on treating all request parameters as untrusted data and ensuring that debug responses cannot interpret them as markup.
Common defensive patterns include:
- Applying context-aware HTML escaping to every reflected value
- Returning structured data such as JSON where HTML rendering is unnecessary
- Using templating systems with auto-escaping enabled by default
- Restricting debug endpoints through authentication, authorization, and narrowly scoped network policies
- Avoiding allow-all access policies for operational interfaces
- Limiting diagnostic endpoints and processes to the minimum data and privileges required
- Using browser security controls such as an appropriate Content Security Policy as defense in depth
Mitigation generally focuses on treating all request parameters as untrusted data and ensuring that debug responses cannot interpret them as markup.
Common defensive patterns include:
- Applying context-aware HTML escaping to every reflected value
- Returning structured data such as JSON where HTML rendering is unnecessary
- Using templating systems with auto-escaping enabled by default
- Restricting debug endpoints through authentication, authorization, and narrowly scoped network policies
- Avoiding allow-all access policies for operational interfaces
- Limiting diagnostic endpoints and processes to the minimum data and privileges required
- Using browser security controls such as an appropriate Content Security Policy as defense in depth
How teams detect issues like this
Detection can include static analysis for request parameters written directly into HTML responses, code review checks for missing output encoding, and tests that submit HTML and script-like marker values to debug endpoints and verify that they are rendered inert.
Policy enforcement can require authentication for administrative and diagnostic endpoints, prohibit allow-all ACLs in production, and scan response templates for auto-escaping bypasses. Automated application security testing and code review tools may help identify reflected input flows.
Detection can include static analysis for request parameters written directly into HTML responses, code review checks for missing output encoding, and tests that submit HTML and script-like marker values to debug endpoints and verify that they are rendered inert.
Policy enforcement can require authentication for administrative and diagnostic endpoints, prohibit allow-all ACLs in production, and scan response templates for auto-escaping bypasses. Automated application security testing and code review tools may help identify reflected input flows.
