Apryse SDK in 2026: HTML2PDF Is a Separate Module

Apryse is the name PDFTron rebranded to on 8 February 2023, four years after PDFTron itself acquired the underlying SDK's original vendor. They sell one of the widest-format document toolkits available for .NET, more than 30 file types out of a single native C++ core, exposed through nine language bindings. What they do not sell as part of that base toolkit is HTML-to-PDF conversion. It ships as its own module, downloaded separately, inside a product built around a native binary and a licensing model that assumes a procurement process rather than a five-minute evaluation.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Apryse's separate HTML2PDF module and its two disclosed CVEs cost a team, and where IronPDF renders the same page from one package.

This is the highest-stakes comparison in the series, because Apryse has real, disclosed CVEs, and two land on the exact module covered here, the HTML2PDF component that renders HTML to PDF in C#.

What does Apryse SDK get right?

Once the HTML2PDF module is in place, converting a page looks like this.

// Requires the Apryse Server SDK and the separately downloaded HTML2PDF module
using pdftron;
using pdftron.PDF;

PDFNet.Initialize(licenseKey);
HTML2PDF.SetModulePath(@"C:\Apryse\Lib");
if (!HTML2PDF.IsModuleAvailable())
{
    throw new InvalidOperationException("HTML2PDF module not found at the configured path.");
}

using var doc = new PDFDoc();
var converter = new HTML2PDF();
converter.InsertFromURL("https://example.com/invoice");
converter.Convert(doc);
doc.Save(@"C:\Output\invoice.pdf", SDFDoc.SaveOptions.e_linearized);

The PDFTron name never really left the shipping product, even after the rebrand, and it is right there in the code. The NuGet package is still PDFTron.NET.x64, the native binary is still PDFNetC.dll, and initialization still runs through pdftron.PDFNet.Initialize. That native core buys real breadth, with over 30 file types including CAD formats and full Office documents, nine language bindings sharing one C++ engine, and Office-to-PDF conversion that runs without Microsoft Office installed and without data leaving the local network, which a cloud-routed conversion service cannot match. Apryse also ships a client-side WebViewer that renders documents in the browser at zero server compute cost, which IronPDF does not do, since it renders server-side by design.

How do Apryse SDK and IronPDF compare?

Capability	Apryse SDK	IronPDF
HTML-to-PDF	Separate HTML2PDF module, downloaded and configured	Included in IronPdf, no separate module
Rendering engine	Bundled Chromium, inside the HTML2PDF module	Bundled Chromium, ChromePdfRenderer
Format conversion range	30+ file types including CAD and Office	PDF from HTML, images, and existing PDFs
Client-side rendering	Yes, via WebViewer	Not offered, server-side by design
Language bindings from one core	9	.NET-focused
Own-code CVEs affecting HTML rendering	Two current, see below	None found
Trial	40 active days, then the library throws	30-day free trial
Published pricing	Entry package from $1,500, rest quote-only	Published tiers by deployment

Where does the HTML2PDF module add friction?

• HTML-to-PDF is a module you download and wire up yourself: the HTML2PDF module ships as its own archive, expanded into the SDK directory and located through HTML2PDF.SetModulePath(), with an IsModuleAvailable() check required before use. It is one of twelve optional modules Apryse offers, and while only OCR by IRIS is documented as separately licensed among them, HTML2PDF still is not part of a base SDK install.
• The trial and licensing model assume an enterprise buyer: the trial runs 40 active days of real use, not 40 calendar days, and needs registry write access, a documented friction point on IIS. License keys are platform-locked, and running on a platform the key was not issued for silently drops the application into demo mode instead of failing with a clear error. The only price published anywhere on Apryse's site is an entry package from $1,500, and every other tier is quote-only, with no published ceiling to budget against.
• Linux deployment of HTML2PDF has no fixed, documented dependency list: Apryse's own guidance for missing shared libraries, including Chromium runtime dependencies like libnss3 and fontconfig, is to run ldd against the module and resolve whatever comes back, because the documentation says outright that the missing-dependency list varies by distribution instead of publishing one canonical set.

None of that touches the format breadth or the WebViewer, both real and unaffected by the three points above. What they describe is the friction of adopting HTML-to-PDF inside a toolkit not built around it as a first-class feature, namely a separate module, an enterprise-shaped trial, and a Linux dependency list you have to discover rather than look up.

What does the CVE record actually say?

Unlike most libraries in this series, Apryse has real, disclosed CVEs in its own code, and two land directly on the HTML2PDF module this article covers. CVE-2025-56590 is a 9.8 critical OS command injection (CWE-78) in HTML2PDF's InsertFromURL() function. NVD's own description states it could allow an attacker to execute arbitrary operating system commands on the local server, scoped through version 11.10 of the module. The root cause sits in Apryse's own argument handling, unsanitized input reaching a system call, not the bundled Chromium engine that does the actual rendering. CVE-2025-56589 is a 7.5 high local file inclusion and server-side request forgery (CWE-918) in the same module's InsertFromHtmlString() function.

For both, NVD lists no fixed version, and no vendor advisory was published. NVD's CPE data for CVE-2025-56590 lists specific point releases rather than one clean version range, so the safest citation is the description's own stated ceiling, through 11.10, rather than a boundary NVD itself does not draw cleanly.

Older issues have been resolved. CVE-2021-40160 and CVE-2021-40161 (both 7.8, memory corruption via crafted files, fixed in 9.0.7), CVE-2022-27527 (7.8, fixed in 9.0.7), CVE-2022-27871 (7.8, fixed in 9.1.17), and CVE-2022-24960 (7.8, use-after-free, fixed in 9.2.1) are five flaws resolved across roughly two years, several major versions behind the current release.

A few misattribution traps read as more damning than they are. A dependency scan of the NuGet PDFTron.NET.x64 package reporting dozens of vulnerabilities is counting bundled third-party native libraries such as zlib, libexpat, and libjpeg-turbo, not flaws in Apryse's own code. Three CVEs filed under M-Files Hubshare (CVE-2022-39016, CVE-2022-39018, CVE-2022-39019) name PDFTron in their text but are M-Files integration flaws, fixed in Hubshare's own releases. CVE-2024-4327 and CVE-2024-57240 are cross-site-scripting issues in WebViewer specifically, a separate client-side product from the Server SDK. And iText's CVE-2023-6298 is explicitly disputed by the vendor and should not be cited as a confirmed flaw. iText's CVEs generally, including CVE-2021-43113, belong to iText, a product Apryse now owns but does not share code with the Server SDK.

One checkable fact for anyone auditing this dependency is that there are zero NuGet and zero npm advisories against any Apryse or PDFTron package, so a routine dotnet list package --vulnerable scan will not surface either HTML2PDF CVE. Both only turn up in a direct NVD or GitHub Advisory Database search.

That is a different vulnerability class than what is covered above. Command injection and SSRF are about untrusted input going into the renderer, not what happens once a PDF already exists. If untrusted PDFs coming into your own system are also part of your threat model, IronPDF's guide to sanitizing untrusted PDF content is a reasonable companion read.

Where does IronPDF fit?

The same HTML-to-PDF job, with the rendering engine included instead of configured as a separate module.

// Install-Package IronPdf
using IronPdf;

var renderer = new ChromePdfRenderer();
PdfDocument pdf = renderer.RenderUrlAsPdf("https://example.com/invoice");
pdf.SaveAs("invoice.pdf");

There is no module to download, locate on the file system, or check for availability before calling. That call is available the moment the IronPDF package installs, and the renderer's full option set is documented in IronPDF's API reference. None of that is a reason to write off Apryse SDK outright. A project that needs the 30-plus format range, the WebViewer, or nine-language-binding portability from one native core gets capability IronPDF does not offer. Where the calculus shifts is a project whose actual need is specifically HTML-to-PDF, because a toolkit that treats that feature as a separately configured module, with two disclosed CVEs neither carrying a published fix as we write this, is worth pricing against one where the same rendering path is the product's whole reason for existing.

So which one fits your project?

Apryse SDK earns its reputation as a serious, broad document toolkit. HTML-to-PDF specifically is where the friction concentrates, in a separately configured module, an enterprise-shaped trial and licensing model, an undocumented Linux dependency list, and two disclosed CVEs in that module that carry no published fixed version as we write this. For a project centered on document conversion breadth, that is a manageable tradeoff. For a project centered specifically on rendering HTML to PDF, it is worth pricing against a library built around that job from day one.

Have you deployed the HTML2PDF module on Linux yourself? Did the dependency list match what you expected going in, or did you end up running an ldd pass to sort it out? Drop a comment either way, we are curious how common that friction actually is.

Apryse and PDFTron are trademarks of their owner, and this piece is not affiliated with the company. The CVE details, module behavior, and pricing above are drawn from Apryse's own documentation, NVD, and the GitHub Advisory Database as they stood at the time of writing. If a detail has changed since, correct us in the comments.