CVE-2026-16770

This CVE exposes a trust boundary failure in PDF::WebKit that transcends the specific vulnerability: the module lets HTML documents configure their own rendering options through meta tags, which is architecturally equivalent to letting user input rewrite your validated command-line arguments after you've checked them. The attack works because the module processes meta tags from untrusted documents and passes them as arguments to wkhtmltopdf, enabling options like --enable-local-file-access for path traversal or --cookie-jar for credential exfiltration. The compounding failure is the optional dependency model. When XML::LibXML isn't installed—a recommended but not required dependency—the security scan that would catch malicious meta tags is silently disabled. The module continues processing documents without any warning to the operator that their security controls are offline. This is the critical failure: a security dependency that doesn't hard-fail when absent creates silent insecurity worse than loud failure. The argument-list implementation provides no meaningful protection. While it prevents classic shell injection (no string interpolation into a command string), argument injection into wkhtmltopdf still exposes a real attack surface—options like --enable-local-file-access and --cookie-jar are documented features, not obscure flags. The mitigation that looks like a security measure actually obscures the residual vulnerability. To determine if you're affected: first, check whether your deployment has XML::LibXML installed—if it doesn't, you're running the vulnerable code path without protection. Second, audit whether PDF::WebKit processes untrusted HTML (documents from external users, uploaded content, or scraped pages). If it processes only internal, trusted documents, the practical risk differs. Third, examine your wkhtmltopdf invocation for whether untrusted input could reach the meta tag parsing path. The deeper remediation is architectural: treat document-to-renderer as an untrusted data flow permanently. Remove or disable meta tag processing unless you can implement a strict allow list of safe options—and make the absence of that allow list loud, not silent. The pattern recurs across ecosystems (dompdf, WeasyPrint, Prawn) precisely because the industry never codified the principle that HTML-to-PDF converters must treat source documents as untrusted input, not configuration sources.

Reviewed through automated stages and approved by a human before publication.