wkhtmltopdf has been read-only since 2023, and your scanner will only accept migration

A vulnerability scanner does not care that the binary still renders. It matches an installed package against an advisory, and CVE-2022-35583 has no fixed version to match against, because there will never be another release ^[1][2]. That is the whole mechanism: the remediation field on the ticket cannot be filled with a version number, so it gets filled with either an exception that returns at the next audit or a migration ^[3]. The advisory identifier carries a 2022 prefix, so it was already outstanding when the repository went read-only on 2 January 2023 ^[8].

The cost of that migration is not in the engine call. It is in the documents. Vitalii, the PDFik founder who wrote the field guide, is direct about the part a vendor post could easily skip: no Chromium-based engine reproduces wkhtmltopdf output pixel for pixel, because line breaking and font fallback differ, so golden files get re-approved ^[4][6]. The systems most likely to be running the old binary are invoice, report and ticket generators older than five years ^[11]. Those are the documents somebody formally signed off on, quite possibly the same function now demanding the CVE be closed. Templates using `--toc` or `--outline` need a separate line item, since there is no first-class Chromium equivalent and outlines are either rebuilt in post-processing or abandoned ^[5].

The engine question then collapses to whether templates need JavaScript to render. If they do not, and the stack is Python, WeasyPrint is a CSS `@page` engine with no browser process at all and active maintenance ^[12]. If they do, Playwright's five lines of `page.pdf()` arrive with a browser fleet attached: per-tab memory ceilings, crash-looping renderers under load, sandboxing, fonts in the image, pool scaling ^[13]. Gotenberg packages Chromium and LibreOffice behind an HTTP API in a container, which keeps document content inside your own network and leaves you owning capacity planning, upgrades and availability ^[14].

The rot on the old path is quieter than the CVE but harder to argue with over time. The engine is a patched Qt WebKit from another era, so CSS grid, flexbox gaps and custom properties misrender without error ^[9]. Distributions have been dropping the package, official builds do not cover current Debian and Ubuntu releases or arm64 well, and Docker images increasingly depend on third-party rebuilds of an unmaintained binary ^[10]. Anyone moving to arm64 instances hits that before any auditor does.

Treat the guide as what it says it is, a post by the founder of a competing hosted API ^[6]. The reason to read it anyway is that it sends compliance-heavy document generation to DocRaptor's PrinceXML engine and its SOC 2 and HIPAA-BAA posture rather than to his own product ^[15], and lists PDFShift, Api2Pdf and PDFMonkey as Chromium-based shortlist candidates with different pricing shapes ^[16]. Its own framing is that nothing breaks on a schedule, and the gap widens with each new deployment target, audit and CSS feature ^[7]. What changed is that one of those pressures now generates a ticket no patch can close.