CVE-2021-30618 - Chrome Headless Remote Debugging RCE via XSS

While investigating Chrome’s remote debugging interface, @DanAmodio and I discovered a critical vulnerability that allows an attacker to achieve remote code execution on a victim’s machine by leveraging a combination of Cross-site Scripting (XSS) on the chrome-devtools-frontend.appspot.com domain and clickjacking the DevTools HTTP handler. This vulnerability, reported as Chromium Issue 40084203, enables an attacker to obtain the GUID for a WebSocket connection to the local Remote Debugger and arbitrarily read and write local files, including startup scripts that will automatically execute on user login.

The Vulnerability #

The vulnerability exists when Chrome is running in headless mode with remote debugging enabled. The attack combines two separate issues:

Cross-site Scripting (XSS) on the chrome-devtools-frontend.appspot.com domain, which has been documented in multiple Chromium bug reports since at least 2016
Clickjacking of the DevTools HTTP handler to navigate the remote debugging UI

Together, these vulnerabilities allow an attacker to:

Extract the WebSocket GUID from the remote debugging interface
Connect to the local Chrome Remote Debugging Protocol
Read arbitrary local files (including sensitive files like SSH keys, AWS credentials, etc.)
Write arbitrary files to the local filesystem (including Launch Agents that execute on login)

The root cause is a combination of factors:

Chrome’s remote debugging interface exposes a web-based UI that can be embedded in iframes
The XSS vulnerability on chrome-devtools-frontend.appspot.com allows JavaScript execution in the same origin context
The remote debugging protocol provides powerful file system access capabilities
The ability to write files to sensitive locations like ~/Library/LaunchAgents/ enables persistent code execution

Affected Versions #

Affected versions: Chrome versions with remote debugging enabled (tested on Chrome 94.0.4583.1 canary and likely affects earlier versions)
Status: This vulnerability leverages a known XSS issue that has been reported multiple times but remains unpatched in the DevTools frontend

The vulnerability affects any Chrome instance running with --headless --remote-debugging-port flags, which is commonly used for:

Automated testing and web scraping
Headless browser automation
Development and debugging workflows

How It Works #

The attack chain works as follows:

Victim Setup: A user launches Chrome in headless mode with remote debugging enabled:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --remote-debugging-port=9222

Frame #1 - Clickjacking: The attacker hosts a malicious webpage that creates an iframe pointing to the local remote debugging interface:
```
<iframe src="http://127.0.0.1:9222"></iframe>
```
The iframe is made 100% transparent, and a button is positioned over it to clickjack the user. When clicked, this navigates the frame to the DevTools UI hosted on chrome-devtools-frontend.appspot.com, which includes the WebSocket GUID in the URL:
```
https://chrome-devtools-frontend.appspot.com/serve_file/@1ea76e193b4fadb723bfea2a19a66c93a1bc0ca6/inspector.html?ws=127.0.0.1:9222/devtools/page/A375BA1BB436B2ADE802B44A94C934D6&remoteFrontend=true
```
Frame #2 - XSS / Bridge: A second iframe is created that leverages the XSS vulnerability on chrome-devtools-frontend.appspot.com:
```
<iframe src="https://chrome-devtools-frontend.appspot.com/serve_rev/@191797/devtools.html?remoteFrontendUrl=javascript:alert(1)"></iframe>
```
The XSS payload can access top.frames[0] and extract the location.href from Frame #1 (since they’re now on the same origin). The WebSocket GUID is then transmitted to the parent exploit page via top.postMessage.
Exploitation: The parent page now has the WebSocket GUID and can connect to the local Chrome Remote Debugging Protocol using libraries like chrome-remote-interface or puppeteer-web.
File Operations:
- Reading files: The attacker opens and parses file:// URLs to read arbitrary local files
- Writing files: The attacker uses Page.setDownloadBehavior in the debugging API to write files to arbitrary locations, such as ~/Library/LaunchAgents/ on macOS

Proof of Concept #

To reproduce the vulnerability:

Launch Chrome in headless mode with remote debugging:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless --remote-debugging-port=9222

Open the exploit HTML file (chrome.html) in a browser and click the button on the page
Observe the JavaScript alert boxes showing:
- Identified system users
- Contents of sensitive files if they exist locally:
  - /etc/passwd
  - ~/.aws/credentials
  - ~/.ssh/id_rsa
Observe that a Launch Agent configuration has been downloaded to ~/Library/LaunchAgents/chromeRCE.plist, which will execute on user login

The exploit demonstrates reading sensitive system files and writing a persistent backdoor that executes on login, but the same technique could be used to:

Exfiltrate authentication tokens and credentials
Install persistent malware
Execute arbitrary commands with the user’s permissions
Access and steal sensitive data from the local filesystem

The Impact #

This vulnerability is particularly dangerous because:

Full system compromise: An attacker can execute arbitrary commands on the victim’s system with the same permissions as the user running Chrome
Persistent access: Files can be written to ~/Library/LaunchAgents/ (macOS) or equivalent startup directories on other platforms, enabling persistent code execution across reboots
Credential theft: An attacker can read sensitive files including SSH keys, AWS credentials, password files, and other authentication tokens
Data exfiltration: An attacker can steal sensitive code, files, or other private data from the victim’s system
Low user interaction: The attack requires minimal user interaction, just visiting a malicious webpage and clicking a button

The attack is especially concerning because it targets developers and security professionals who commonly use Chrome with remote debugging enabled for testing and automation purposes. These users often have elevated permissions and access to sensitive systems, making them high-value targets.

The XSS Vector #

The XSS vulnerability on chrome-devtools-frontend.appspot.com has been documented in multiple Chromium bug reports:

The XSS vector allows JavaScript execution through the remoteFrontendUrl parameter, which can be exploited to bridge the origin boundary and extract sensitive information from the remote debugging interface.

Why This Matters #

According to Google’s security impact guidelines, XSS vulnerabilities in Chrome that require additional flags (like --remote-debugging) are typically considered to have no security impact since Chrome requires these flags to be explicitly enabled. However, this vulnerability demonstrates that when combined with other attack vectors (clickjacking) and powerful APIs (remote debugging protocol), these “low-impact” issues can lead to critical security vulnerabilities.

This vulnerability highlights the importance of:

Defense in depth: Even “low-impact” vulnerabilities can be chained together for critical impact
Secure defaults: Remote debugging interfaces should be designed with security as a primary consideration
File system access: Powerful debugging APIs should have additional security controls to prevent arbitrary file access
Origin isolation: The remote debugging UI should be properly isolated to prevent XSS from accessing sensitive debugging information

Disclosure #

This vulnerability was reported to the Chromium security team as Issue 40084203. I worked with @DanAmodio on this issue.

Takeaways #

This vulnerability highlights several important security lessons:

Vulnerability chaining: Multiple “low-impact” vulnerabilities can be combined to achieve critical impact. The XSS vulnerability alone might be considered low-impact, but when combined with clickjacking and powerful debugging APIs, it enables full system compromise.
Remote debugging security: Remote debugging interfaces provide powerful capabilities that should be protected with additional security controls. The ability to read and write arbitrary files through a debugging protocol is particularly dangerous.
Origin isolation: The remote debugging UI should be properly isolated to prevent cross-origin attacks from accessing sensitive debugging information like WebSocket GUIDs.
File system access controls: Debugging APIs that provide file system access should implement additional validation and restrictions to prevent writing to sensitive locations like startup directories.
Clickjacking protection: Interfaces that handle sensitive operations should implement proper clickjacking protections (like X-Frame-Options headers).

The fact that this vulnerability affects a common development and testing workflow serves as a reminder that security tools and debugging interfaces need to be designed with security as a primary consideration, not an afterthought.