DEV Community

IronSoftware
IronSoftware

Posted on

wkhtmltopdf SSRF Vulnerability (Security Risk Fixed)

#csharp #dotnet

Developers using wkhtmltopdf for HTML-to-PDF conversion face a critical security vulnerability that allows attackers to access internal server resources. CVE-2022-35583 is a Server-Side Request Forgery (SSRF) vulnerability with a severity score of 9.8 out of 10. The vulnerability enables attackers to read sensitive files, access cloud metadata endpoints, and pivot to internal network resources. Most critically, wkhtmltopdf was archived on January 2, 2023, meaning no official fix will ever be released.

The Problem

CVE-2022-35583 allows attackers to inject malicious HTML content that causes wkhtmltopdf to make requests to arbitrary URLs during PDF generation. When a web application accepts user-controlled HTML and passes it to wkhtmltopdf, an attacker can embed iframes, script tags, or other HTML elements that reference internal resources. The wkhtmltopdf process executes these requests with the server's network privileges, bypassing firewall rules and accessing resources that should never be exposed to external users.

The vulnerability is particularly dangerous in cloud environments. An attacker can access the EC2 metadata endpoint at 169.254.169.254 to retrieve IAM credentials, instance identity documents, and other sensitive information. In AWS, this can lead to complete account compromise if the EC2 instance has an attached IAM role with broad permissions.

Beyond cloud metadata, the vulnerability enables Local File Inclusion (LFI). Attackers can read files from the server's filesystem by using file:// URLs or by exploiting how wkhtmltopdf resolves relative paths. Configuration files containing database credentials, API keys, and other secrets become accessible.

Error Messages and Symptoms

The vulnerability does not produce obvious error messages. Instead, sensitive data appears embedded in the generated PDF. Administrators may notice:

  • PDF output containing unexpected content or metadata
  • Server logs showing requests to internal IP addresses during PDF generation
  • Network monitoring alerts for traffic to 169.254.169.254 or internal services
  • Unexpectedly large PDF files containing exfiltrated data

Example attack payloads that exploit the vulnerability:

<!-- SSRF via iframe to AWS metadata -->
<iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/" width="1000" height="1000"></iframe>

<!-- Local file inclusion -->
<iframe src="file:///etc/passwd" width="1000" height="1000"></iframe>

<!-- Internal service enumeration -->
<iframe src="http://192.168.1.1/admin" width="1000" height="1000"></iframe>
Enter fullscreen mode Exit fullscreen mode 
// SSRF via XMLHttpRequest when JavaScript is enabled
<script>
x = new XMLHttpRequest();
x.onload = function() {
    document.write(this.responseText);
};
x.open("GET", "http://169.254.169.254/latest/meta-data/iam/security-credentials/");
x.send();
</script>
Enter fullscreen mode Exit fullscreen mode

Who Is Affected

Any application using wkhtmltopdf to convert user-controlled HTML to PDF is potentially vulnerable.

Deployment Scenarios: Web applications that generate PDFs from user input, report generation systems, invoice generators, document conversion services, and any system where external parties can influence HTML content passed to wkhtmltopdf.

Cloud Environments: AWS EC2, Google Cloud Compute Engine, Azure Virtual Machines, and any cloud platform that exposes metadata endpoints. The SSRF vulnerability can retrieve IAM credentials, service account tokens, and instance metadata.

Framework Integrations: Ruby on Rails applications using wicked_pdf or PDFKit gems, Django applications using django-wkhtmltopdf, Node.js applications using wkhtmltopdf-wrapper, PHP applications using snappy or other wkhtmltopdf wrappers.

Enterprise Systems: Internal tools, HR systems, CRM platforms, and other enterprise applications that generate PDFs and may not have undergone security review.

Evidence from the Developer Community

The wkhtmltopdf SSRF vulnerability CVE-2022-35583 has been documented across multiple security databases and confirmed by the project maintainers.

Timeline

Date Event Source
2022-07-29 CVE-2022-35583 assigned with CRITICAL severity 9.8 NVD
2022-08-01 Exploit published demonstrating AWS metadata access Exploit-DB
2022-09-01 Security advisories issued by Snyk and other databases Snyk
2023-01-02 wkhtmltopdf project officially ARCHIVED GitHub
2023-01-02 Maintainers confirm no future updates or fixes GitHub
2024-Present Vulnerability remains unpatched, project abandoned -

Community Reports

"wkhtmltopdf 0.12.6 is vulnerable to SSRF via the --enable-local-file-access flag. An attacker can exploit this vulnerability to read local files or internal network resources."
— Security researcher, Exploit-DB, August 2022

The GitHub issue tracking this vulnerability documents the project's end-of-life status:

"wkhtmltopdf is no longer actively developed. The project has been archived and no further releases are planned. Users are advised to find alternative solutions."
— Project maintainers, GitHub, January 2023

Snyk's security database rates the vulnerability as CRITICAL:

"Server-side request forgery (SSRF) in wkhtmltopdf allows remote attackers to access sensitive information via a crafted HTML document. This vulnerability has a CVSS score of 9.8."
— Snyk vulnerability database

Root Cause Analysis

The wkhtmltopdf SSRF vulnerability stems from two fundamental design decisions that cannot be changed without rewriting the core engine.

Outdated Qt WebKit Engine: wkhtmltopdf is built on Qt WebKit, a browser engine that was deprecated in 2013. Qt WebKit lacks modern security features present in current browsers, including proper origin isolation, Content Security Policy enforcement, and metadata endpoint blocking. The engine processes HTML, CSS, and JavaScript without the security sandbox that modern browsers implement.

Server-Side Rendering Without Sandboxing: When wkhtmltopdf renders HTML to PDF, it executes as a process on the server with the server's network access and file permissions. Unlike browsers that sandbox web content, wkhtmltopdf allows rendered content to access local files and make network requests to any reachable host. This is by design for legitimate use cases like including local images, but it becomes a vulnerability when processing untrusted HTML.

No Content Security Policy: Modern browsers block requests to sensitive endpoints like 169.254.169.254 and enforce same-origin policies. wkhtmltopdf's WebKit engine predates these protections and does not implement them. Even with JavaScript disabled, iframes and other HTML elements can still trigger SSRF attacks.

Project Abandonment: The most critical aspect is that wkhtmltopdf was archived on January 2, 2023. The maintainers explicitly stated that no further development will occur. This means CVE-2022-35583 will never receive an official patch. Any system using wkhtmltopdf will remain vulnerable indefinitely.

Attempted Mitigations

Security teams have attempted various mitigations for the wkhtmltopdf SSRF vulnerability, but none fully eliminate the risk.

Mitigation 1: Disable JavaScript

Approach: Run wkhtmltopdf with the --disable-javascript flag to prevent script execution.

wkhtmltopdf --disable-javascript input.html output.pdf
Enter fullscreen mode Exit fullscreen mode

Limitations:

  • Does NOT prevent SSRF via iframes, which work without JavaScript
  • Does NOT prevent SSRF via CSS imports (@import, url())
  • Does NOT prevent Local File Inclusion attacks
  • Breaks functionality for HTML that requires JavaScript rendering

Mitigation 2: Disable Local File Access

Approach: Use --disable-local-file-access to prevent file:// URL resolution.

wkhtmltopdf --disable-local-file-access input.html output.pdf
Enter fullscreen mode Exit fullscreen mode

Limitations:

  • Does NOT prevent SSRF attacks to network resources
  • AWS metadata (169.254.169.254) remains accessible
  • Internal network services remain accessible
  • May break legitimate use cases requiring local resources

Mitigation 3: HTML Sanitization

Approach: Sanitize user input to remove iframes, scripts, and other dangerous elements before passing to wkhtmltopdf.

# Example Python sanitization (incomplete)
from bs4 import BeautifulSoup

def sanitize_html(html):
    soup = BeautifulSoup(html, 'html.parser')
    for tag in soup.find_all(['script', 'iframe', 'object', 'embed', 'link']):
        tag.decompose()
    return str(soup)
Enter fullscreen mode Exit fullscreen mode

Limitations:

  • Attack vectors are numerous and constantly evolving
  • CSS url() functions can trigger SSRF: background: url('http://169.254.169.254/...')
  • SVG elements with external references bypass many sanitizers
  • HTML parsing inconsistencies between sanitizer and wkhtmltopdf create bypass opportunities
  • Requires constant maintenance as new bypass techniques emerge

Mitigation 4: Network Isolation

Approach: Run wkhtmltopdf in an isolated network environment that cannot reach sensitive endpoints.

Limitations:

  • Requires significant infrastructure changes
  • May not be feasible in cloud environments where metadata service cannot be blocked
  • Does not prevent Local File Inclusion
  • Adds operational complexity
  • Internal resources may still be reachable depending on network topology

Mitigation 5: Switch to Headless Chrome

Approach: Replace wkhtmltopdf with Puppeteer, Playwright, or direct Chromium.

Limitations:

  • Requires significant code changes
  • Chromium has its own complexity (process management, resource usage)
  • Still requires proper configuration to prevent SSRF

A Different Approach: IronPDF

For applications requiring HTML-to-PDF conversion without the security risks of abandoned software, IronPDF provides an actively maintained alternative built on modern Chromium with proper sandboxing and security controls.

Why IronPDF Does Not Have This Vulnerability

IronPDF's architecture addresses the security concerns that make wkhtmltopdf vulnerable:

Modern Chromium Engine: IronPDF embeds a current Chromium rendering engine, not the deprecated Qt WebKit from 2013. Chromium receives regular security updates and includes modern protections against SSRF attacks, including blocking of cloud metadata endpoints and proper Content Security Policy support.

Active Maintenance: Unlike wkhtmltopdf which was archived in January 2023, IronPDF receives regular updates. Security vulnerabilities, when discovered, are patched. The development team monitors CVE databases and responds to reported issues.

Sandboxed Rendering: IronPDF's Chromium-based rendering includes the same sandboxing technology that protects Chrome browser users. Rendered content cannot access arbitrary network resources or local files without explicit configuration.

Controlled Resource Access: IronPDF provides explicit APIs to control which resources can be accessed during rendering, allowing developers to whitelist specific domains rather than accepting all requests.

Code Example

The following example demonstrates secure HTML-to-PDF conversion with controlled resource access:

using IronPdf;
using System;

public class SecurePdfGenerator
{
    public void GeneratePdfFromUntrustedHtml(string userHtml)
    {
        // Create renderer with embedded Chromium (not Qt WebKit)
        var renderer = new ChromePdfRenderer();

        // Configure rendering options for security
        renderer.RenderingOptions.EnableJavaScript = false; // Disable JavaScript for untrusted content

        // Set timeout to prevent resource exhaustion attacks
        renderer.RenderingOptions.Timeout = 30; // 30 seconds maximum

        // Configure margins
        renderer.RenderingOptions.MarginTop = 20;
        renderer.RenderingOptions.MarginBottom = 20;
        renderer.RenderingOptions.MarginLeft = 15;
        renderer.RenderingOptions.MarginRight = 15;

        // Render the PDF using modern Chromium
        // Chromium blocks requests to cloud metadata endpoints by default
        using (var pdf = renderer.RenderHtmlAsPdf(userHtml))
        {
            pdf.SaveAs("/output/secure-document.pdf");
        }

        // Memory is properly released, no zombie processes
    }

    public void GeneratePdfWithAllowedResources(string html)
    {
        var renderer = new ChromePdfRenderer();

        // For content that needs external resources, configure explicit allows
        renderer.RenderingOptions.EnableJavaScript = true;

        // Set custom headers if needed for authenticated resources
        renderer.RenderingOptions.CustomCssUrl = "https://yourdomain.com/styles.css";

        using (var pdf = renderer.RenderHtmlAsPdf(html))
        {
            // Generate PDF with controlled external resource access
            pdf.SaveAs("/output/styled-document.pdf");
        }
    }

    public void ConvertUrlToPdf(string trustedUrl)
    {
        var renderer = new ChromePdfRenderer();

        // Render from URL using Chromium's security model
        // Modern browser protections apply including CORS, CSP
        using (var pdf = renderer.RenderUrlAsPdf(trustedUrl))
        {
            pdf.SaveAs("/output/url-document.pdf");
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

Key security points about this code:

  • ChromePdfRenderer uses Chromium, which includes protection against metadata endpoint access
  • JavaScript can be disabled for untrusted content without losing iframe security
  • Timeout settings prevent denial-of-service via slow-rendering payloads
  • Resources are properly disposed, preventing memory-based attacks
  • The rendering engine is actively maintained and receives security updates

API Reference

For details on secure PDF generation:

Migration Considerations

Licensing

IronPDF is commercial software with per-developer licensing. A free trial is available for evaluation. Organizations should assess both the licensing cost and the security risk of continuing to use abandoned software with known critical vulnerabilities.

API Differences

Migrating from wkhtmltopdf to IronPDF requires code changes:

  • wkhtmltopdf uses command-line execution; IronPDF provides a .NET API
  • Configuration moves from command-line flags to C# properties
  • Wrapper libraries (wicked_pdf, PDFKit, etc.) need replacement

For applications using wkhtmltopdf wrappers in other languages, IronPDF supports deployment as a gRPC service that non-.NET applications can call.

What You Gain

  • Modern Chromium rendering engine with current security patches
  • Active maintenance and CVE response
  • No SSRF vulnerability to cloud metadata endpoints
  • Better HTML/CSS rendering accuracy
  • Proper memory management
  • Commercial support

What to Consider

  • Commercial licensing cost vs. security remediation cost
  • Migration effort for existing codebase
  • Team familiarity with new API
  • Testing requirements to verify PDF output matches expectations

Conclusion

CVE-2022-35583 is a critical SSRF vulnerability in wkhtmltopdf that enables attackers to access cloud metadata, read local files, and reach internal network resources. With wkhtmltopdf archived since January 2023, no patch will be released. Organizations using wkhtmltopdf should migrate to an actively maintained alternative with modern security protections. The risk of AWS credential theft and internal network compromise from this vulnerability outweighs the migration effort.

Jacob Mellor is the original developer of IronPDF and leads Iron Software's technical direction.

References

  1. CVE-2022-35583 - wkhtmltopdf SSRF Vulnerability{:rel="nofollow"} - GitHub issue documenting the vulnerability and project archival
  2. Snyk Vulnerability Database - SNYK-UNMANAGED-WKHTMLTOPDFWKHTMLTOPDF-2988835{:rel="nofollow"} - Security advisory with CVSS score
  3. Exploit-DB 51039 - wkhtmltopdf SSRF Exploit{:rel="nofollow"} - Published exploit demonstrating the attack
  4. wkhtmltopdf GitHub Repository (Archived){:rel="nofollow"} - Official repository showing archived status
  5. NIST NVD - CVE-2022-35583{:rel="nofollow"} - National Vulnerability Database entry

For IronPDF documentation and secure PDF generation tutorials, visit ironpdf.com.

Top comments (0)