CVE-2026-110136: the Chromium PDF flaw and what to patch

CVE-2026-110136 is a critical use-after-free in Chrome's PDF component, disclosed on October 13, 2026. Google's published CVE record identifies versions before 155.0.8059.79 and describes possible code execution outside the sandbox through a crafted HTML page. For a PDF service, inspect the browser binary and the input path. A library version alone does not answer either question.

Sources checked on November 2, 2026. The version threshold below describes this specific October fix, rather than the newest secure browser release.

What does the Chromium PDF advisory establish?

Google's record establishes a memory-safety flaw in the PDF component. It does not establish that every HTML-to-PDF endpoint exposes that component's vulnerable path, or that a particular headless deployment has been exploited.

The CVE record is the factual boundary for this incident. Our deployment recommendations below follow from reviewing the service around that component; they are not evidence of a new exploit against a PDF API.

Use that distinction in your own incident ticket. Write down what is confirmed about the dependency and what remains unknown about your application. "Uses Chromium" is a useful inventory signal. It is not a complete description of reachability or impact.

Does an HTML-to-PDF service expose a PDF viewer flaw?

Generating a PDF and opening an existing PDF are different operations. Our recommended review separates workers that print trusted HTML, workers that visit arbitrary URLs, and workers that load uploaded PDF documents.

Trace a representative job from input to output. For an HTML template, identify remote assets, embedded content, redirects, and any post-processing stage. For a URL converter, record what destinations and content types the browser can encounter. For a PDF thumbnail service, identify which engine parses the incoming PDF.

Do not use the output filename as the security boundary. A worker that returns invoice.pdf may first visit a customer-supplied page. A thumbnail worker may never generate a PDF but still parse one. The relevant distinction is the code path that consumes the untrusted input.

Different Chromium distributions also need their own inventory. Our Chrome Headless Shell comparison explains the deployment choices. Check the actual browser configuration before transferring a statement about desktop Chrome to a headless binary or a remote browser provider.

For the wider architecture, see our HTML-to-PDF threat model. A free webpage-to-PDF conversion illustrates the URL input workflow; it is not a way to test whether your own workers are patched.

How do you identify the browser your worker actually launches?

Record the browser version from a process launched with the same settings as production. Playwright's browser documentation explains that each Playwright release expects specific browser binaries and that browser installation may need to be rerun after an update.

For a service using Playwright's default Chromium installation, this inventory command prints both the default executable path and the launched version:

node --input-type=module <<'JS'
import { chromium } from 'playwright';
 
console.log('Default executable:', chromium.executablePath());
const browser = await chromium.launch({ headless: true });
try {
  console.log('Launched browser:', browser.version());
} finally {
  await browser.close();
}
JS

Adapt the launch call to your deployment before relying on the output. If the service supplies executablePath, a browser channel, or a remote connection, inspect that configuration. The default executable path is irrelevant when the service launches another binary.

As a recommended acceptance record, retain the output with the image digest, the browser package version, and the source of the fix. A distribution may backport a patch, so use its advisory when a package version does not follow Google's upstream version string.

How should you rebuild and isolate a browser worker?

Update the browser through the installation path your worker actually uses, rebuild the artifact, and replace existing browser processes. Our recommended rollout ends with both a version check and a representative document conversion.

For Playwright-managed Chromium, follow the browser installation instructions after selecting a supported Playwright release. For system Chromium, use the distribution's patched package. For a remote provider, request its browser build and patch status. In all cases, verify the deployed process instead of assuming that a successful build replaced every worker.

Review isolation separately. Playwright's Docker documentation says its default root user disables the Chromium sandbox, and recommends a separate user plus an appropriate seccomp profile for crawling untrusted sites. Do not describe a Docker container as proof that the browser sandbox is enabled.

Our recommended worker boundary also excludes application secrets it does not need and limits reachable internal services. These controls reduce what an unexpected browser failure can reach. They do not remove the need for security updates.

Finally, test the normal render path with your own fixtures: a multipage template, remote assets where allowed, and an HTML-to-PDF conversion. Inspect layout and download behavior. Functional checks and patch verification answer separate acceptance questions.

Chromium is only one part of the October maintenance work. Review Node2Shell's Brotli fix and the Next.js October advisories independently. When PDF4.dev handles hosted rendering, keep that same separation between the rendering service and the application that calls it.