v1.4.2

Security release — stop archived pages writing files outside the output directory

Everyone should upgrade. Anyone on 1.4.1 or earlier who archives a page they do not control is exposed.

The problem

A ../ in an archived page's asset URL — say <img src="http://site/%2e%2e/evil.txt"> — was decoded and joined straight onto OUTPUT_DIR with nothing checking the result stayed inside it. Since the tool exists to replay third-party content, that let whoever influenced the archived page create or overwrite files anywhere the process could write.

Tracked as GHSA-mw6m-6mxq-gmj5 (CVSS 3.1 8.1, CWE-22). Affects <= 1.4.1, fixed in 1.4.2.

What changed

• Every URL-derived path now goes through one chokepoint that collapses . and .. the way a web server does before serving a file, then asserts the result is inside OUTPUT_DIR. A path that still escapes is refused and that single file is skipped, so a hostile URL cannot abort an archive run.
• Three further routes to the same sink are closed alongside the reported one: a plain unencoded .. in an absolute URL, a percent-encoded backslash (a path separator on Windows), and the Google Fonts / Squarespace branches, which build their own paths.
• Link rewriting collapses paths identically, so a rewritten link keeps pointing at the file that actually gets written.

Legitimate paths are unaffected — directory URLs, spaces, dotfiles, double slashes and the Google Fonts layout all resolve exactly where they did in 1.4.1.

Credits

• @EQSTLab — found and privately reported the vulnerability, with a reproducible proof of concept. Thank you.