A dependency that stopped shipping releases in 2020 and had its repository archived in 2023 is still parsing HTML in a lot of .NET stacks. It usually shows up as wkhtmltopdf, or through DinkToPdf, the C# wrapper built around it, and we still meet it in migration reviews more often than you would expect. It was useful and simple in its day, which is why so much of it is still deployed. What changed is the calendar, not that early usefulness, and an archived wkhtmltopdf binary carrying open CVEs is a risk the person who owns the deployment now has to accept on purpose rather than inherit by default.
This is a decision-layer question more than a code question. A clean demo on a developer laptop is what keeps wkhtmltopdf in place, and it hides the one thing that matters, which is who patches the engine when the next HTML parser bug lands. For an archived project, the answer is nobody, and that gap does not show up until something in production depends on it being closed.
A quick disclosure. Our team at Iron Software builds IronPDF, and we point out below where the open-source alternatives are the better call.
What Actually Happened to the Project
The timeline sits in the project's own history, and none of it is in dispute. The last stable release was 0.12.6, back in June 2020. The last commit to the main branch landed in June 2022. In January 2023, the maintainer archived the repository himself. In July 2024, GitHub archived the entire wkhtmltopdf organization, all four repositories, read-only, including one named obsolete-downloads.
The maintainer's own status page does not soften it. The project runs on Qt 4, unsupported since 2015, on top of a WebKit engine frozen since 2012. That is the code parsing production HTML and CSS today, whether the team that shipped it knew that or not. The maintainer points anyone starting fresh at WeasyPrint or Prince for static documents, and Puppeteer where JavaScript rendering is needed. When the author of a tool is directing new users elsewhere, that is the clearest signal an architect gets about where the project is going.
The frozen wkhtmltopdf engine is a rendering problem as much as a security one. WebKit from 2012 predates most of the CSS a current template takes for granted, so grid layouts, flexbox behavior, and newer font handling drift or fail outright, and there is no wkhtmltopdf release coming to close the gap. Every rendering bug found from 2020 onward is permanent by definition. For a team maintaining document output over several years, that is a component whose behavior can only diverge further from the HTML the rest of the stack is written against, and the divergence is one-directional because only the frozen side has stopped moving.
The CVEs Still on the Record
Two vulnerabilities are logged against the binary, and neither has a fix on the way, because there is no longer anyone to ship one.
-
CVE-2020-21365- directory traversal, where crafted HTML can read local files under the default configuration in versions through 0.12.5, rated High at CVSS 7.5 in the GitHub Advisory Database. -
CVE-2022-35583- server-side request forgery through an injected iframe pointed at internal addresses, present in 0.12.6, rated Critical at CVSS 9.8 in the GitHub Advisory Database.
Both are wkhtmltopdf-specific, and both stay open. The moment any part of the HTML being rendered originates from a user, a customer-supplied field on an invoice template, a print-this-ticket button, a comment embedded in a generated report, these stop being historical footnotes and become live attack surface on an engine that will never be patched again.
Where DinkToPdf Inherits the Same Risk
DinkToPdf, the most common .NET wrapper, does not reimplement HTML rendering. It marshals into the same wkhtmltopdf binary underneath and layers a C# API on top. Same engine, same frozen WebKit, same two CVEs, same warning from the maintainer about untrusted HTML. A project that references DinkToPdf carries everything above even if its own code never names wkhtmltopdf once, which is exactly what makes this easy to miss in a dependency audit.
There is a deployment cost hiding in that arrangement as well. The native wkhtmltopdf library has to be present and correct on every target, which means the archived binary gets baked into container images and build artifacts and then travels with the application for as long as it lives. An unmaintained native dependency is not a line in a lockfile that quietly resolves itself. It is a payload someone has to keep shipping on purpose, and each new deployment surface, a fresh base image or a different Linux distribution, is another place it has to be reconciled by hand.
It is worth being precise about the shape of the problem, because rendering untrusted HTML into a PDF is a category-wide attack surface rather than a single-tool defect. Feed almost any HTML-to-PDF renderer a reference to an internal address or a local file and the question is what comes back embedded in the output. The wkhtmltopdf binary is the renderer most exposed to it right now, because it is the one that stopped getting patched and cannot receive a fix. Whatever a team lands on next, the same question about untrusted input has to be asked of it.
Where IronPDF Fits
The migration target that removes the frozen-engine problem is a renderer that still ships. Here is the same task, rendering HTML to a PDF, on a Chromium engine instead.
using IronPdf;
// render an HTML string through the bundled Chromium engine
var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice #1042</h1><p>Total due: $250.00</p>");
// write the finished PDF to disk
pdf.SaveAs("invoice.pdf");
That writes invoice.pdf to disk through the same Chromium engine that ships in Chrome, and the engine is patched on Chromium's release cadence instead of sitting at 2012-era WebKit. IronPDF ships that engine inside a single IronPdf package that handles its own native binaries per platform, and it targets .NET 10 down through .NET Framework 4.6.2, so moving onto it rarely means touching the target framework first.
The choice comes down to who patches the engine, and the difference reads clearly side by side.
| Concern |
wkhtmltopdf and DinkToPdf
|
IronPDF |
|---|---|---|
| Rendering engine | Qt WebKit frozen since 2012, last release 0.12.6 in June 2020 |
Chromium through ChromePdfRenderer, IronPdf 2026.7.2 shipped June 2026 |
| Maintenance status | Repository archived January 2023, GitHub organization archived July 2024, no patches | Actively released on one line, 2026.7.2 shipped June 2026 |
| Untrusted HTML |
CVE-2020-21365 and CVE-2022-35583 open with no fix coming |
Chromium sandbox patched on Chromium's cadence, one IronPdf package on 2026.7.2
|
There is an honest counterweight worth stating. When budget is the hard constraint and commercial support is not required, the maintainer's own suggestions, WeasyPrint for static documents and Puppeteer where JavaScript matters, are worth evaluating before landing on any paid renderer. The decision that needs making is not open-source versus paid. It is a frozen, unpatched engine versus one that still receives security fixes, and there is more than one supported way off the first.
What the Migration Actually Costs
The reason this decision gets deferred is that nothing is on fire today yet, and a working PDF path is easy to leave alone. The cost of leaving it alone stays invisible until an auditor flags the CVEs, or a customer sends HTML the frozen engine mishandles, or the one person who understood the DinkToPdf setup moves on and takes the tribal knowledge with them. Priced over a few years, an unmaintained renderer is technical debt that accrues quietly and then comes due all at once, usually on someone else's schedule.
The migration itself is bounded work rather than a rewrite. Both tools take an HTML string and hand back a PDF, so the surface that changes is the call site, not the document templates, which is where most of the real effort in any PDF pipeline lives. The templates carry over, the rendering call swaps, and the engine underneath moves from frozen to maintained. That is a small, testable change with a clear before and after, which is exactly the kind of migration worth doing while it is a planned line item rather than after an incident makes it urgent.
Wrapping Up
The short version for a review meeting looks like this.
- wkhtmltopdf is archived, with its last release
0.12.6in June 2020 and its GitHub organization archived in July 2024. - Two wkhtmltopdf-specific CVEs stay open with no patch coming,
CVE-2020-21365andCVE-2022-35583. - DinkToPdf wraps the same binary, so it inherits the same engine and the same CVEs.
- Rendering untrusted HTML is a category-wide attack surface, and an unpatched engine is the worst place to meet it.
- Moving to a Chromium renderer like IronPDF puts the render on a codebase that still ships patches, and open-source alternatives fit where budget is the constraint.
So what is keeping wkhtmltopdf or DinkToPdf in your stack right now, the migration effort, the license cost of a supported renderer, or the fact that nothing has visibly broken yet? That last one is the hardest to argue with a manager, and we are genuinely curious which of the three carries the most weight for your team.
If you want to map the API before committing to anything, the migration guide covers the move from wkhtmltopdf and DinkToPdf, and the status page and both advisories above are public if you would rather verify the risk for yourself first. Has an archived renderer with open CVEs already come up in one of your reviews, and did it change the plan or get waved through? Tell us how that went in the comments.
wkhtmltopdf, DinkToPdf, WeasyPrint, and Puppeteer are the property of their respective owners, and we have no affiliation with any of them. The dates and CVE details above are drawn from the projects' own archives and the GitHub Advisory Database, and if one has moved since, correct us in the responses.
Top comments (0)