CVE-2026-102354 in BentoPDF
Summary
by MITRE • 10/14/2026
BentoPDF is a privacy-focused PDF toolkit that runs in the browser. In versions through 2.8.6, cloudflare/cors-proxy-worker.js performs a DNS-over-HTTPS safety check in hostnameResolvesToPrivate(), as used by isValidCertificateUrl() and isValidTsaUrl(), separately from the outbound fetch(targetUrl, ...). In deployments where PROXY_SECRET validation is not enabled, a direct client that controls authoritative DNS can forge the Origin header, supply a certificate, OCSP, CRL, or TSA URL that passes the proxy's accepted path checks, return a public address during validation, and return a private or link-local address during the later fetch. The endpoint can return allowed response bodies to the attacker, but exploitation requires precise timing, redirects and IP-literal obfuscation are blocked, and network reachability limits the target. This vulnerability is fixed in 2.8.7.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in BentoPDF versions through 2.8.6 stems from a race condition inherent in how the application validates URLs for external resources such as certificates, OCSP responders, CRL distribution points, and Time Stamping Authority endpoints. The core issue lies in the separation of DNS resolution safety checks and actual network requests within the cloudflare/cors-proxy-worker.js module. Specifically, the function hostnameResolvesToPrivate() is invoked to verify that a target URL does not resolve to a private or link-local IP address before allowing the proxy to fetch it. This check serves as a critical defense against Server-Side Request Forgery attacks targeting internal network services. However, this validation occurs independently from the subsequent outbound fetch operation performed by the isValidCertificateUrl and isValidTsaUrl functions. In environments where PROXY_SECRET validation is not enabled, an attacker who controls authoritative DNS records can exploit this temporal gap to perform a DNS rebinding attack. By manipulating DNS responses over time, the attacker can cause the initial safety check to return a public IP address while causing the actual fetch request to resolve to a private or link-local internal IP address.
This architectural flaw allows for potential unauthorized access to internal network resources that are typically inaccessible from the internet. The attacker crafts requests where the Origin header is forged and DNS records are dynamically updated between the validation phase and the execution phase of the proxy request. Although the vulnerability requires precise timing due to the nature of DNS caching and propagation delays, it remains a significant risk in misconfigured deployments. The impact includes the potential exposure of internal services such as administrative interfaces, database ports, or other sensitive endpoints that rely on network-level isolation for security. While the implementation blocks IP-literal obfuscation and redirects, which mitigates some common bypass techniques, the reliance on separate DNS resolution steps creates a window of opportunity for sophisticated attackers capable of controlling authoritative name servers.
From a classification perspective, this vulnerability aligns with CWE-367, Time-of-check to time-of-use (TOCTOU), as the security check performed during validation is not atomic with respect to the subsequent resource access operation. It also relates to CWE-918, Server-Side Request Forgery (SSRF) Flaws, specifically regarding the failure to enforce consistent network destination policies across multiple stages of request processing. In terms of MITRE ATT&CK tactics, this technique falls under Taint Analysis and Validation Failure within the Initial Access or Discovery phases, where an attacker leverages flawed input validation logic to pivot into internal networks. The specific mechanism resembles DNS Rebinding attacks often categorized under reconnaissance techniques that bypass perimeter defenses by exploiting trust in initial network state verification.
Mitigation strategies must address both immediate configuration issues and long-term architectural improvements. Administrators should ensure that PROXY_SECRET validation is enabled for all deployments of BentoPDF, as this adds a layer of authentication that prevents unauthorized clients from forging Origin headers or initiating proxy requests without proper credentials. For existing installations where secret-based protection cannot be immediately implemented, network-level controls such as firewall rules restricting outbound traffic to known public IP ranges can provide compensating controls. Furthermore, the application logic should be updated to perform DNS resolution and validation atomically within a single request context, ensuring that the IP address resolved at the time of fetching matches the one validated during the safety check. Updating to version 2.8.7 or later resolves this issue by correcting the race condition in the proxy worker implementation.