Overview
In December 2023, I discovered a Universal XSS vulnerability in Google Translate.
The vulnerability allowed me to achieve JavaScript execution on domains where I could control simple reflected user input.
The interesting behavior appeared when the affected page was processed through Google Translate.
During my testing, I found that attacker-controlled Unicode characters could be transformed during translation and subsequently interpreted as HTML.
The vulnerable component was Google Translate. The resulting JavaScript execution occurred in the context of the translated origin.
Discovery
While testing Google Translate, I noticed interesting behavior around Unicode characters representing HTML delimiters.
The characters I focused on were:
U+FF1C <
U+FF1E >
These are the fullwidth variants of the normal HTML delimiters:
<
>
After the page was processed by Google Translate, I observed that these characters could be transformed into their ASCII equivalents:
< → <
> → >
This was the behavior that led me to investigate whether reflected user-controlled input could cross from the original text representation into an HTML parsing context.
Technical Details
The basic condition was simple: I needed a page where I could control input that was reflected into the response.
I then passed the page through Google Translate and observed how the translated representation differed from the original response.
Attacker-controlled input
↓
Page reflects input
↓
Google Translate processes page
↓
Unicode representation is transformed
↓
HTML is interpreted
↓
JavaScript execution
The important part of the research was the transformation performed by the translation layer before the resulting content was interpreted by the translated document.
Original Payload
The following section contains the original payload I used during my research.
I will add the original payload here directly from my research material.
; mycookie=你好 <img onerror=alert() 3 src=1你好 > 你好_ga=sGA1.1.15642435 mycokie=你好 <script/你好/onerror=alert();
3 你好 src=> 你好_ga=sGA1.1.15642435 mycokie=你好 </script/imgxss 你好>你好
The payload was used to verify that reflected, attacker-controlled input could survive the translation process and result in executable content.
Proof of Concept
I demonstrated the vulnerability in two separate contexts. The first PoC demonstrated JavaScript execution on a Google domain. I then demonstrated the same behavior in the context of instagram.com.
JavaScript Execution on Google
The first proof of concept demonstrated JavaScript execution on a Google domain through the Google Translate processing flow.
JavaScript Execution on instagram.com
I then demonstrated the behavior against instagram.com, showing that the JavaScript execution occurred in the context of the translated Instagram origin.
Why This Became UXSS
After confirming the behavior, I tested it against different domains.
I found that a target only needed a suitable location where user-controlled input was reflected.
The translation layer provided the behavior that transformed the reflected content into executable HTML.
Target page
↓
Reflected user input
↓
Google Translate
↓
Translated document
↓
JavaScript execution
↓
Target origin
The resulting JavaScript execution occurred on the origin domain of the translated page.
Impact: reflected attacker-controlled input could become executable content after being processed by Google Translate, resulting in JavaScript execution in the translated origin.
Auto-Translate
I also investigated whether the behavior required the victim to manually select the translation option.
I found that automatic translation could process the affected content without requiring an additional interaction.
Attacker-controlled content
↓
Victim opens page
↓
Automatic translation
↓
Google Translate processes content
↓
HTML interpretation
↓
JavaScript execution
I demonstrated this using a controlled email account. The attacker-controlled content was delivered to the account and processed when the page was automatically translated.
Testing & Scope
I tested the behavior across multiple environments and translation scenarios.
- Windows
- Linux
- macOS
- Android
- Chromium-based environments
- Multiple translation languages
I also tested the behavior against multiple websites containing attacker-controlled reflected input.
The research included demonstrations involving Google Accounts, Gmail, Instagram and Naver.
Disclosure Timeline
| Date | Event |
|---|---|
| Dec 16, 2023 | Vulnerability reported. |
| Dec 17, 2023 | Auto-Translate behavior demonstrated. |
| Dec 18, 2023 | Additional testing and impact validation. |
| Dec 20, 2023 | Google indicated that the issue was fixed. |
| Dec 22, 2023 | Issue marked as fixed. |
| Jan 2, 2024 | Google confirmed that the vulnerable component was Translate. |
| Jan 24, 2024 | $7,500 VRP reward awarded. |
| Jan 25, 2024 | $1,000 UXSS bonus awarded. |
| Mar 30, 2024 | Issue access restrictions removed. |
Reward
$7,500 base reward
+ $1,000 UXSS bonus
Google awarded me a total of $8,500 for the vulnerability.
References
Original vulnerability report and public disclosure record.
View Chromium Report →Closing
This was one of the more interesting browser-security issues I worked on because the behavior was not limited to a single website.
What initially looked like simple reflected input became much more interesting once the page passed through Google Translate.
The research demonstrated how a translation layer could transform attacker-controlled content into executable HTML and ultimately lead to JavaScript execution in the context of the translated origin.
— R3dpars3c