Scrolling through the GitHub Advisory Database, trawling for CVEs like the CVE Archeologist’s Field Guide recommends, I ran into CVE-2026-34529. After my first few OSS security reports the other week that resulted in 3 CVEs I wanted to continue on this journey of getting deeper into open source secure code review and continue to practice and improve my methodology.
Review
CVE: CVE-2026-34529 Name: File Browser is vulnerable to Stored Cross-site Scripting via crafted EPUB file URL: https://github.com/advisories/GHSA-5vpr-4fgw-f69h Severity: High Similar Vulnerabilities:
How to Find It Again
Manually
Finding this exact vulnerability across the ecosystem in regards to this package would only require two things:
- Ensuring the repo uses the
epub.jslibrary. - Check if
allowScriptedContent: trueis set anywhere.
More broadly it’d be about hunting for package/library-specific misconfigurations that are called out in their respective documentation as things not to do. A lot of packages will support specific functionality that isn’t inherently safe, but it needs to exist to ensure flexibility and/or backwards compatibility.
- Read through the documentation. Check the security sections, and keep an eye out for anything involving scripted content or features that need to be turned on but users are warned against doing.
- Hunt for that configuration in projects using that package.
Even more broadly speaking, anything that processes and/or renders filetypes like epub, js, html, etc. should be checked for potential cross-site scripting (or other injection issues). Of course impact must be achieved, so if they’re stuck in a sandbox in any way, it must be proven that they can break out of that sandbox, or at most have some type of valid impact within the sandbox. The epub filetype by design needs to be able to execute scripting, as it’s one of the features of it.
W3 has a good section on scripting within EPUBs that essentially boils down the recommendation of not enabling it unless it’s absolutely necessary. Another thing to consider is this:
For example, typical same-origin policies are not applicable to content that has been downloaded to a user’s local system.
Checking Other Repos
I threw a dead simple query ("allowScriptedContent: true") into the GitHub search bar to get an initial grasp on other repos that are potentially affected by a similar misconfiguration. Leveraging Claude Code I had it build an epub with escalating test cases in an attempt to quickly test the most common attack surfaces they may be reached within this file format, no matter where it’s executed.
There weren’t too many other large-scale projects with an active security policy that appeared to be using that configuration from the code search, mainly two, but one hadn’t seen an update in two years and the others Docker install wasn’t functioning. I’m currently trying to re-download it to another machine and set it up that way, so if that succeeds I’ll come back and update this post.
This is a collection of my cybersecurity notes & projects.
I graduated from Dakota State University with a MS in Cyber Defense & BS in Cyber Operations. Since then I've worked as a Malware Analyst with the U.S. Army Cyber Command, and am now a Web Application Security Consultant.
I'm a big fan of open security standards for applications and workflow automation when it comes to security testing. The easier it is to identify and replicate, the more secure everyone's apps can be! My other writings and projects are scattered across the web, but can be found in the links page.
Contact me: