Security release
Three advisories closed, no behavior changes for the common HTTP scraping path. Upgrade is recommended for anyone running obscura serve against untrusted input or on a network-reachable port.
Fixed
-
GHSA-6pj9-j389-226p: a page on http(s) could set
window.onload, assignlocation.href = "file:///..."and readdocument.bodyfrom the loaded local file because the JS runtime was reused across navigations.JS-initiated cross-scheme nav into
file://is now refused, and the V8 realm is rebuilt per navigation so window state from the prior page does not survive.Reported by @byte16384.
-
GHSA-4789-rq5x-jv3c: three findings.
-
Sub-resource fetches (
<script src>,<link rel=stylesheet href>) had no scheme gate, so an http page could include<script src="file:///etc/passwd">and the body came back as script source. Sub-resources now have to match the page's scheme family. -
CSS pulled from the network was string-formatted into a JS template literal with a partial escaper that did not handle U+2028 / U+2029, letting attacker CSS break out and run arbitrary code in V8. Escape is now thorough.
-
JS-driven navigation chains capped at ten steps but returned
Ok(())when the limit was hit. They now returnPageError::TooManyRedirects.
Reported by @linuxdevel.
-
-
GHSA-q55h-vfv9-qcr5: anyone able to reach the CDP port could send:
Page.navigate {"url":"file:///etc/shadow"}and read any file the obscura process can read.
The CDP path now refuses
file://by default. Pass--allow-file-accesstoobscura servewhen local-HTML testing is the intended workflow.The CLI
obscura fetch file://...path is unaffected because it does not go through the CDP server.Reported by @UserB1ank.
Upgrade notes
If you currently rely on a CDP client (Playwright, Puppeteer, custom) to navigate to file:// URLs against obscura serve, add --allow-file-access to your serve command.
The flag prints a startup warning so the relaxed posture is visible in logs.
Thanks
Three independent security researchers found and reported these: