Sourcehut account takeover via build logs (XSS in ansi2html)
A stored XSS vulnerability in the Python library ansi2html allowed unauthenticated attackers to execute arbitrary JavaScript via SourceHut build logs, leading to potential account takeover.
read it Provides a comprehensive security writeup complete with exploit payloads, timeline details, and lessons on terminal rendering edge cases.
summary
A security researcher discovered that the Python library ansi2html incorrectly handled OSC 8 hyperlinks and ANSI escape sequences, introducing a stored XSS vulnerability into SourceHut build logs. Because builds.sr.ht could be triggered anonymously via public mailing lists, attackers could inject malicious payloads that executed in the browser of anyone viewing the log. If an administrator viewed the page, the payload could hijack session tokens, submit fraudulent build manifests, and access internal deploy keys. The issue persisted for years due to an unmaintained upstream dependency before being mitigated locally and fixed upstream.
key points
- Attackers injected JavaScript by embedding malicious OSC 8 hyperlink escape sequences into build logs, which ansi2html rendered into executable HTML anchor tags.
- The vulnerability could be triggered without an account simply by sending a patch to a public mailing list configured with continuous integration.
- Compromising a SourceHut administrator via this XSS vector could expose sensitive infrastructure deploy keys and allow complete control over build jobs.
who should read it
Security engineers, platform developers, and maintainers of CI systems handling untrusted log output.
discussion positive
consensus
Commenters expressed astonishment at how easily the vulnerability could be triggered via anonymous mailing list patches and discussed the inherent security risks of parsing complex terminal escape sequences.
> The worse impact is that you have access to all the deploy keys, and on builds.sr.ht, there are deploy keys for sr.ht itself (probably not the case with other instances).
This is the most unexpected bit.
Circumstances made it so I got a new computer right around the time srht put out their anti-LLM policy. So I immediately started setting up a forgejo instance on my home network. With the latest waves of attacks on he AUR, I decided to keep that machine completely free from all AUR packages or helpers. So I also set up a package registry through the forgejo instance. With some work I have …
Points out the severe risk of exposed deploy keys in build logs and prompts a practical discussion on container hardening for CI environments.
Generated by an LLM from the article and thread. Check the sources before relying on it.