Dangerous Arbitrary File Read Vulnerability in Yelp (CVE-2025-3155)

I don’t normally blog about particular CVEs, but Yelp CVE-2025-3155 is noteworthy because it is quite severe, public for several weeks now, and not yet fixed upstream. In short, help files can read your filesystem and execute arbitrary JavaScript code, allowing an attacker to exfiltrate any files your Unix user has access to. Thank you to parrot409 for responsibly disclosing this issue and going above and beyond to provide patches.

• By default, all major browsers allow websites to download files automatically, without user interaction, so installing a malicious help file into your Downloads directory is simple. (If you ever find an unexpected file in your Downloads directory, be careful and maybe don’t open it. Cautious users may wish to configure their browsers to prompt before saving a download.)
• The malicious website would next attempt to open the special URL ghelp:///proc/self/cwd/Downloads. This relies on the assumption that the web browser runs with your home directory as current working directory, which in practice will generally be true when launched from your desktop environment.
• Chrome and Firefox prompt the user for permission before launching Yelp. If you grant permission, then Yelp launches and you lose. Don’t grant permission. Beware: both browsers have an “always allow” checkbox, and you won’t be prompted for permission if you’ve ever checked it when opening a ghelp URL in the past.
• Epiphany does not prompt the user for permission before opening the URL. Minimal user interaction is required for the attacker to win. If you use Epiphany or any other browser that opens links in external programs without user confirmation, you should immediately uninstall Yelp, or at least change your Downloads directory to something nonstandard.

Timeline:

• December 25: Bug is reported to GNOME Security.
• February 24: The reporter proposes these patches to fix the issue.
• March 26: The 90 day disclosure deadline is reached, so I make the issue report public even though it is not yet fixed. At this point, due to insufficient creativity, I incorrectly assume the issue is likely to be used only in targeted attacks, because it seems to require the attacker to know the path to your downloads directory, which will normally include your Unix username.
• April 5: The bug reporter posts a detailed write-up including a nice GIF to demonstrate the attack exfiltrating ~/.ssh/id_rsa in Chrome. This attack uses /proc/self/cwd/Downloads, bypassing the requirement to know your Unix username.
• April 13: GNOME Security is notified of the write-up.

If you are a Linux operating system vendor, please consider applying the provided patches even though they have not yet been accepted upstream. They’re probably not worse than the status quo!