CVE-2025-68616

What it actually does

This is a server-side request forgery protection bypass in WeasyPrint before version 68.0. WeasyPrint applications commonly fetch remote resources referenced by HTML or CSS while rendering PDFs, such as images, stylesheets, fonts, and imported CSS. Even when an application implements a custom url_fetcher to block access to internal addresses, WeasyPrint's default_url_fetcher can rely on urllib behavior that automatically follows HTTP redirects. If the original attacker-controlled URL passes validation but redirects to a blocked destination, such as localhost, private RFC1918 addresses, link-local cloud metadata endpoints, or internal service names, the redirected destination may be fetched without being re-checked against the application's SSRF policy. The primary impact is unauthorized read access to internal HTTP-accessible resources from the perspective of the server performing PDF generation.

Why it matters to the business

Systems that render attacker-controlled or user-supplied HTML/CSS into PDFs using affected WeasyPrint versions may unintentionally expose internal services or cloud instance metadata. In cloud environments, successful exploitation may disclose temporary credentials, instance identity data, service tokens, or internal application data, which can lead to broader account or infrastructure compromise. The CVSS score is high at 7.5 due to confidentiality impact, but current exploitation maturity is listed as none, EPSS is low at 0.00501, and the issue is not currently in the CISA KEV catalog, so remediation should be prioritized based on whether PDF generation accepts untrusted input and whether servers have access to sensitive internal networks or metadata services.

How an attack unfolds

An attacker identifies an application feature that converts HTML, templates, rich text, uploaded documents, or user-controlled content into PDF using WeasyPrint. The attacker supplies HTML or CSS containing a resource reference, such as an image, stylesheet, font, or @import URL, that points to an attacker-controlled web server. The application's custom url_fetcher checks the initial URL and allows it because it appears to be external and permitted. When WeasyPrint retrieves that URL, the attacker-controlled server responds with an HTTP redirect to an otherwise blocked internal destination, such as a localhost service, private IP address, Kubernetes or container service endpoint, or cloud metadata endpoint. Because urllib follows the redirect automatically without re-applying the developer's destination validation, the PDF renderer may fetch the internal resource. The attacker then attempts to infer or recover the response through rendered PDF output, conversion errors, embedded resource behavior, timing differences, or application logs, depending on how the application handles fetched content and errors.

How to fix it

Upgrade WeasyPrint to version 68.0 or later. For source-based deployments of kozea/weasyprint, ensure the fix is present at or after commit e9352befffdb1754462b160c38a7e8903a4e28d7. If immediate upgrade is not possible, disable or tightly restrict remote resource fetching during PDF generation; ensure custom url_fetcher logic validates every final URL after redirects, not only the initial URL; disable automatic redirects where feasible; enforce scheme allowlists such as https only; block loopback, link-local, private, multicast, and reserved address ranges; block cloud metadata hostnames and IPs; resolve and validate hostnames before connection and after redirects; and apply network-level egress controls so PDF rendering workers cannot reach metadata services or internal administrative endpoints. In cloud environments, require hardened metadata protections such as IMDSv2 where applicable and avoid attaching overly broad credentials to PDF rendering workloads.

How to confirm the fix worked

Confirm that installed WeasyPrint packages report version 68.0 or later, or that source builds include commit e9352befffdb1754462b160c38a7e8903a4e28d7 or a later equivalent patch. Review dependency manifests, lockfiles, container images, and deployed runtime environments because vulnerable WeasyPrint may be bundled indirectly. Perform a controlled validation test in a non-production environment by rendering HTML that references an allowed external test URL which returns a redirect to a benign internal test endpoint; the request should be blocked, logged, or fail safely, and no request should reach the internal target. Repeat the test for loopback, private IP, link-local metadata-style addresses, IPv6 loopback/link-local, and DNS names that resolve to restricted ranges. Verify that outbound network policy prevents PDF rendering processes from connecting to internal-only services and metadata endpoints regardless of application-layer behavior.

Typical attack path

1. Find an application workflow that accepts user-controlled HTML, CSS, rich text, URLs, or uploaded content and renders it to PDF with WeasyPrint.
2. Embed an external resource reference in the content, such as an img, link rel=stylesheet, @import, @font-face, or similar fetchable URL.
3. Host the referenced URL on attacker-controlled infrastructure and return an HTTP 30x redirect.
4. Set the redirect Location header to an internal or sensitive destination, such as localhost, a private network address, or a cloud metadata endpoint.
5. Allow WeasyPrint's underlying fetch logic to follow the redirect from the initially approved URL to the sensitive destination.
6. Recover sensitive data through the generated PDF, visible rendering artifacts, error messages, timing behavior, or downstream logs if the fetched content is reflected or processed.

How to detect it

Look for evidence that servers performing PDF generation made outbound HTTP requests to unexpected internal or metadata destinations after fetching attacker-controlled external URLs. Useful log sources include application PDF-rendering logs, reverse proxy logs, outbound web proxy logs, DNS resolver logs, firewall or VPC flow logs, EDR network telemetry, container runtime network telemetry, and web server logs for endpoints that accept HTML/CSS or trigger PDF creation. Focus on HTTP 30x redirect chains where the first request is to an external domain and the follow-up request is to localhost, private address space, link-local metadata services, or internal hostnames. Review generated PDFs and conversion error logs for leaked metadata, IAM/security credential JSON, instance identity documents, internal admin pages, service banners, or unexpected embedded text from internal resources. Investigate bursts of failed or unusual PDF render attempts containing HTML tags or CSS directives that cause network fetches, including img, link rel=stylesheet, @import, @font-face, SVG references, and url() CSS functions. If metadata endpoints may have been reached, review cloud audit logs for subsequent suspicious use of temporary credentials associated with the PDF rendering workload.

• 169.254.169.254
• http://169.254.169.254
• http://169.254.169.254/latest/meta-data/
• http://169.254.169.254/latest/meta-data/iam/security-credentials/
• http://169.254.169.254/metadata/instance
• metadata.google.internal
• http://metadata.google.internal
• 100.100.100.200
• http://100.100.100.200
• fd00:ec2::254
• localhost
• http://localhost
• 127.0.0.1
• http://127.0.0.1
• ::1
• http://[::1]
• Location: http://169.254.169.254
• Location: http://localhost
• Location: http://127.0.0.1
• Location: http://[::1]
• Location: http://10.
• Location: http://172.16.
• Location: http://172.17.
• Location: http://172.18.
• Location: http://172.19.
• Location: http://172.20.
• Location: http://172.21.
• Location: http://172.22.
• Location: http://172.23.
• Location: http://172.24.
• Location: http://172.25.
• Location: http://172.26.
• Location: http://172.27.
• Location: http://172.28.
• Location: http://172.29.
• Location: http://172.30.
• Location: http://172.31.
• Location: http://192.168.
• @import url(
• <img src="http
• <link rel="stylesheet" href="http
• @font-face
• url(http

What your security team should do

• Inventory applications, services, workers, and container images that use WeasyPrint for PDF generation, especially where HTML or CSS content can be influenced by external users.
• Upgrade affected deployments to WeasyPrint 68.0 or later, or a source revision containing commit e9352befffdb1754462b160c38a7e8903a4e28d7.
• Prioritize internet-facing or multi-tenant PDF generation workflows and any workload running with cloud credentials or access to sensitive internal networks.
• Add egress filtering for PDF rendering workloads to block loopback, private, link-local, reserved, and metadata service destinations by default.
• Review custom url_fetcher implementations to ensure validation occurs after each redirect and after DNS resolution, not only on the originally supplied URL.
• Search historical logs for redirect chains from external domains to internal addresses, metadata endpoints, or localhost during PDF generation activity.
• Rotate exposed cloud or service credentials if logs, generated PDFs, or forensic evidence suggest metadata or secret-bearing endpoints were accessed.
• Add regression tests that attempt redirect-based SSRF during PDF rendering so future library or code changes do not reintroduce the issue.