BentoPDF vulnerabilities

In BentoPDF through 2.8.6, cloudflare/cors-proxy-worker.js performs a DNS-over-HTTPS safety check in hostnameResolvesToPrivate() separately from the outbound fetch. In deployments without PROXY_SECRET validation, an attacker controlling authoritative DNS can forge the Origin header and supply a certificate, OCSP, CRL, or TSA URL that passes path checks, returning a public address during validation and a private one during the later fetch.

BentoPDF in 2.8.6 and earlier has a vulnerability in the certificate and timestamp CORS proxy in cloudflare/cors-proxy-worker.js that uses isPrivateOrReservedHost() to validate a supplied hostname separately from the DNS resolution used by fetch(targetUrl), allowing an attacker-controlled hostname to resolve to an internal or reserved destination after validation. A certificate-like path can satisfy ALLOWED_PATH_PATTERNS, and direct clients can forge the Origin header. Deployments without PROXY_SECRET skip the optional signature check.

BentoPDF is a client-side PDF toolkit that is self hostable. In 2.8.6 and earlier, deserializeWorkflow() accepts the Timestamp node's tsaUrl control from imported JSON without schema or destination validation. When a user imports the crafted workflow and runs it against a PDF, timestampPdf() sends an RFC 3161 TimeStampReq containing the PDF's SHA-256 MessageImprint to the attacker-selected endpoint. The default self-hosted configuration does not set VITE_CORS_PROXY_URL, so the request bypasses the proxy's ALLOWED_TSA_HOSTS checks and is sent directly. The disclosed digest can confirm that a document matches a known file and can correlate the same document across users without revealing its contents. This vulnerability is fixed in 2.8.7.

In BentoPDF, prior to version 2.8.3, a cross-site scripting (XSS) vulnerability was identified. An attacker could execute arbitrary JavaScript under certain circumstances in the Markdown to PDF Tool.