Summary
BentoPDF's certificate and timestamp CORS proxy can validate a hostname before DNS resolution, allowing that hostname to later resolve to an internal or reserved destination. An attacker who can directly invoke the proxy may use it to relay response bodies from reachable services, particularly when deployment protections such as a proxy secret are absent.
Affected context
The issue affects the certificate and timestamp CORS proxy used by BentoPDF deployments where:
- The proxy validates a supplied hostname separately from the DNS lookup performed by the outbound request
- The execution environment can reach internal, private, or reserved destinations
- Requests can be sent directly to the Worker endpoint
- Optional request-signing controls are not configured or are treated as the primary security boundary
Both official Worker deployments and self-hosted instances may be exposed when these conditions apply.
Exploit preconditions
- Attack surface: The certificate and timestamp CORS proxy Worker endpoint
- Required access: Ability to submit requests to the proxy; authentication may not be required when no proxy secret is configured
- Trigger point: Proxy processing of a certificate-like path followed by an outbound fetch
- Why exploitation is possible: Hostname validation is performed independently of the DNS resolution used for the request, allowing a validated hostname to resolve to an internal or reserved destination
Why this happens
The vulnerability is caused by a server-side request forgery design flaw in which destination validation and destination resolution are separate operations. A hostname may pass an allowlist or private-address check, then resolve to a different address when the outbound fetch occurs. This maps to CWE-918: Server-Side Request Forgery, where attacker-influenced request destinations allow a server-side component to access resources that should not be externally reachable.
Potential impact
- Internal services may be queried from the Worker environment
- Response bodies from reachable destinations may be relayed to an attacker
- Cloud or platform metadata endpoints could potentially be exposed
- Network segmentation and access-control assumptions may be weakened
- Internal service information could support further compromise
General mitigation guidance
Mitigation generally focuses on making destination authorization authoritative at request time rather than trusting a separately validated hostname.
Common defensive patterns include:
- Resolve and validate the final destination address before making the request
- Re-check redirect targets and prevent transitions to private, loopback, link-local, or reserved ranges
- Prefer explicit destination allowlists over broad hostname pattern matching
- Bind outbound requests to controlled egress paths or network policies
- Treat browser-oriented headers such as
Originas untrusted input - Use request signatures as an abuse-control layer, not as a substitute for destination validation
- Apply least-privilege network permissions to the Worker execution environment
- Enforce response-size, timeout, and content-type limits
How teams detect issues like this
Detection can include:
- Static analysis and code review for hostname validation performed separately from DNS resolution or outbound fetching
- Searches for proxy handlers that construct request URLs from user-controlled paths, hosts, or query parameters
- Tests covering DNS rebinding, redirects, alternate address representations, and private or reserved ranges
- Monitoring for proxy requests targeting unusual hostnames, repeated resolution changes, or internal address space
- Policy enforcement requiring centralized outbound-request validation and explicit egress controls
Automated security review tools can help identify SSRF-prone URL construction and incomplete network destination checks.
