Arbitrary remote code execution within wrangler dev Workers sandbox
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.19.0, 2.20.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The V8 inspector intentionally allows arbitrary code execution within the Workers sandbox for debugging. wrangler dev would previously start an inspector server listening on all network interfaces. This would allow an attacker on the local network to connect to the inspector and run arbitrary code. Additionally, the inspector server did not validate Origin/Host headers, granting an attacker that can trick any user on the local network into opening a malicious website the ability to run code. If wrangler dev --remote was being used, an attacker could access production resources if they were bound to the worker. This issue was fixed in wrangler@3.19.0 and wrangler@2.20.2. Whilst wrangler dev's inspector server listens on local interfaces by default as of wrangler@3.16.0, an SSRF vulnerability in miniflare https://github.com/cloudflare/workers-sdk/security/advisories/GHSA-fwvg-2739-22v7 (CVE-2023-7078) allowed access from the local network until wrangler@3.18.0. wrangler@3.19.0 and wrangler@2.20.2 introduced validation for the Origin/Host headers.
Timeline
- CVE published
- Record last updated
Affected versions
- wrangler
through 3.0.0; fixed in 3.19.0; through 2.0.0; fixed in 2.20.2
- wranglernpm
From 3.0.0 · fixed in 3.19.0
- wranglernpm
From 2.0.0 · fixed in 2.20.2