PDF library CVEs in 2026: every H1 advisory in one place

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 audit in CI plus an osv.dev watch on pdf-lib costs 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=high or pip-audit on 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.