H1 2026 produced ten notable security advisories across the PDF toolchain: two Chromium engine bugs that hit every headless PDF pipeline, an actively exploited Adobe zero-day, a CVSS 9.8 command injection in an npm converter package, a Gotenberg disclosure batch with no immediate fix, and library-level bugs in jsPDF, LibreOffice, ChromeDriver, PlaywrightCapture, and Foxit Cloud. Two packages people keep searching for, pdf-lib and browserless, had no CVE at all, and this recap explains what their real risk is instead.
Every PDF-stack CVE from H1 2026
The table lists each advisory, what it breaks, and the version that fixes it. Deep-dive links go to our full write-ups with detection and hardening steps.
| Component | CVE | What it is | Fixed in |
|---|---|---|---|
| Chromium (all headless stacks) | CVE-2026-2441 | CSS use-after-free, exploited in the wild | Chrome 145.0.7632.75 |
| Chromium PDF engine | CVE-2026-5287 | High-severity use-after-free in the PDF code path | Chrome 146.0.7680.178 |
| ChromeDriver on Windows | CVE-2026-8000 | RCE from a crafted page in Selenium Grid CI, APT exploitation confirmed | Chrome 148.0.7778.96 |
| Adobe Acrobat / Reader | CVE-2026-34621 | Prototype pollution zero-day, on the CISA KEV list | Adobe April 2026 patch |
| jsPDF (npm) | CVE-2026-25755 | PDF object injection via addJS(), CVSS 8.8 | jspdf 4.2.0 |
| pdf-image (npm) | CVE-2026-26830 | Unauthenticated OS command injection, CVSS 9.8 | None published; migrate off |
| Gotenberg | CVE-2026-42593 | Unauthenticated arbitrary PDF read via stamp/watermark routes (plus CVE-2026-42597, CVE-2026-42589) | No fixed version at disclosure |
| LibreOffice | CVE-2026-4430 | OOXML salt-mismatch out-of-bounds write, hits headless converters | 26.2.3 / 25.8.7 |
| PlaywrightCapture (PyPI) | CVE-2026-44439 | SSRF and file:// reads during page capture | Patched upstream, see advisory |
| Foxit PDF Editor Cloud | CVE-2026-1592 | Stored XSS via Create New Layer, CVSS 6.3 | Patched Feb 2026 (cloud) |
Three clusters stand out. Engine bugs (the two Chromium CVEs) affect every team rendering PDFs with Puppeteer, Playwright, browserless, or any wrapper, because the vulnerable code is the browser, not the wrapper. Converter bugs (LibreOffice, pdf-image, Gotenberg) affect pipelines that accept files from users. Library bugs (jsPDF) affect code that passes user input into PDF-building APIs.
Does pdf-lib have a CVE in 2026?
No. As of July 2026 there is no published CVE against the pdf-lib npm package, and Snyk's database lists no direct vulnerabilities for it. If you landed here from a search like "pdf-lib CVE-2026", the answer is that the advisory you are looking for does not exist.
The absence of CVEs is not the same as active security maintenance. pdf-lib's latest release, 1.17.1, is years old and the project is effectively unmaintained. That cuts both ways: a small, dependency-light, pure-TypeScript codebase has little attack surface, but a vulnerability found tomorrow has no obvious release path. Practical guidance for teams using pdf-lib:
- Audit what reaches it. pdf-lib parses PDFs you load with
PDFDocument.load(). Treat user-uploaded PDFs as untrusted input and parse them in an isolated context if the stakes are high. - Watch the ecosystem, not the headlines.
npm auditin CI plus an osv.dev watch onpdf-libcosts nothing and catches an advisory the day it publishes. - Check your actual exposure. Many "pdf-lib" hits in dependency trees are transitive via tooling, where untrusted input never reaches it.
Is there a browserless CVE in 2026?
No CVE was published against browserless itself in H1 2026. The two real risks for browserless deployments this year came from elsewhere.
First, exposure scanning. In April 2026, ProjectDiscovery added detection for publicly reachable Browserless API instances to its Nuclei template library. That means unauthenticated instances are being enumerated at internet scale. A browserless container was never meant to be public: it executes arbitrary page loads, which is the SSRF problem CVE-2026-44439 illustrates for the whole HTML-to-PDF class. Put a token on it, bind it to a private network, or both.
Second, the bundled Chromium. Browserless ships a Chromium build, and that build inherits CVE-2026-2441 and CVE-2026-5287 until you pull an updated image. If your image predates the fixed Chrome versions, rendering attacker-influenced HTML is running exploitable browser code on your infrastructure.
Which patches should you prioritize?
Patch in order of exploitation status, then exposure. Actively exploited engine bugs come first because attacker HTML is the input to most PDF pipelines.
| Priority | Action | Applies to |
|---|---|---|
| 1. Now | Update Chromium past 145.0.7632.75 and 146.0.7680.178 (CVE-2026-2441, CVE-2026-5287) | Puppeteer, Playwright, browserless, chromedp, any headless renderer |
| 1. Now | Apply Adobe's April patch (CVE-2026-34621, KEV-listed) | Desktop Acrobat/Reader fleets |
| 2. This week | Block or authenticate Gotenberg stamp/watermark routes (CVE-2026-42593 batch) | Self-hosted Gotenberg |
| 2. This week | Upgrade jsPDF to 4.2.0 (CVE-2026-25755) | Frontend and Node PDF generation |
| 2. This week | Replace pdf-image (CVE-2026-26830, no fix) with a maintained converter | Node upload pipelines |
| 3. This month | LibreOffice to 26.2.3 / 25.8.7 (CVE-2026-4430), Chrome 148+ on Windows CI (CVE-2026-8000) | Headless converters, Selenium CI |
The recurring lesson from the Chromium pair: wrapper libraries lag. Playwright and Puppeteer pin Chromium builds and roll them on their own cadence, so "Chrome patched it Tuesday" does not mean your node_modules is safe Wednesday. Teams that rebuild Docker images weekly and pin the newest library release close that gap; teams that install once and forget carry exploitable browsers for months.
How do you monitor PDF dependencies for new CVEs?
Automate three checks and you will hear about the next advisory before it trends: a dependency audit in CI, an OSV watch on your core packages, and a scheduled rebuild of any image that bundles a browser or office suite.
- CI audit.
npm audit --audit-level=highorpip-auditon every build. Both pull from the GitHub Advisory Database and PyPI advisories, which is where library CVEs like jsPDF's land first. - OSV queries. osv.dev aggregates ecosystems behind one API; a weekly job querying your ten core PDF packages is a 20-line script.
- Engine version pinning with a floor. Record which Chromium your Playwright/Puppeteer version bundles, and alert when Chrome stable ships a security release your pin predates.
- Rebuild cadence. Weekly image rebuilds pick up patched Chromium, LibreOffice, and base-OS packages without anyone reading an advisory.
For teams whose actual product is not PDF infrastructure, the alternative is making the engine someone else's patch queue. A managed API like PDF4.dev runs and patches its own Chromium fleet, so the two engine CVEs in this recap required zero action from its users, while a self-hosted renderer needed an emergency image rebuild each time. Client-side libraries in your own bundle and self-hosted converters stay on your list either way.
We will publish the same recap for H2 in January 2027. The individual write-ups above stay updated as fixed versions ship, starting with the Gotenberg batch, which still had no patched release at disclosure time.
Free tools mentioned:
Frequently asked questions
- Does pdf-lib have a CVE in 2026?
- No. As of July 2026, no CVE has been published against the pdf-lib npm package, and Snyk's vulnerability database lists no direct vulnerabilities for it. The real risk profile is different: pdf-lib's last release (1.17.1) is years old and the project is effectively unmaintained, so future issues may go unpatched. Audit transitive dependencies with npm audit and monitor osv.dev rather than waiting for a headline CVE.
- Is there a browserless CVE in 2026?
- No CVE was published against browserless itself in H1 2026. Two real exposures still apply to browserless deployments: publicly reachable instances are actively scanned for (ProjectDiscovery shipped Nuclei detection for exposed Browserless API instances in April 2026), and the bundled Chromium inherits every Chromium CVE, including CVE-2026-2441 and CVE-2026-5287. Patching browserless means updating its Chromium and never exposing the API unauthenticated.
- What was the most severe PDF-related CVE in H1 2026?
- By CVSS, CVE-2026-26830 in the pdf-image npm package (9.8, unauthenticated OS command injection). By real-world impact, CVE-2026-2441, the actively exploited Chromium CSS use-after-free, because every Puppeteer, Playwright, and browserless PDF pipeline runs Chromium, and bundled copies lag Chrome's patch by days to weeks.
- Which jsPDF version fixes CVE-2026-25755?
- jsPDF 4.2.0. The vulnerability (CVSS 8.8) lets attacker-controlled strings break out of addJS() and inject arbitrary PDF objects, bypassing the AcroJS sandbox assumptions. If user input reaches jsPDF APIs in your code, upgrade and audit what strings can reach addJS().
- Is Gotenberg CVE-2026-42593 fixed?
- At disclosure in May 2026, the advisory listed no fixed version for CVE-2026-42593, the unauthenticated arbitrary PDF read through stampExpression and watermarkExpression parameters on six routes. Self-hosters should block or authenticate those routes at the reverse proxy and check the project's releases for a patched build before re-exposing them. Two sibling advisories (CVE-2026-42597, CVE-2026-42589) shipped in the same batch and should be mitigated together.
- How do I check my PDF dependencies for known CVEs?
- Run npm audit (Node) or pip-audit (Python) in CI, and query osv.dev for each core package: it aggregates GitHub Security Advisories, PyPI advisories, and NVD. For Chromium-based stacks, the version that matters is the bundled browser, not the npm wrapper: check which Chromium your Playwright or Puppeteer version pins and compare it against the latest Chrome stable security release.
- Do managed PDF APIs remove CVE patching work?
- For the rendering engine, yes: a managed API like PDF4.dev patches its own Chromium fleet, so engine CVEs like CVE-2026-2441 or CVE-2026-5287 are the vendor's pager, not yours. Client-side libraries in your own code (jsPDF, pdf-lib) and document converters you self-host (LibreOffice, Gotenberg) remain your responsibility.
- Why do Playwright and Puppeteer lag Chrome security patches?
- Both pin a specific Chromium build per release and roll it forward on their own release cadence, typically days to weeks behind Chrome stable. When Chrome ships an emergency zero-day fix, the bundled Chromium in your node_modules stays vulnerable until the next Playwright or Puppeteer release, unless you point the library at a system Chrome you patch yourself.
Start generating PDFs
Build PDF templates with a visual editor. Render them via API from any language in ~300ms.
