SSRF bypass in Papra webhook delivery (Pre-Auth) with POC and patch

Vulnerability Overview Vulnerability Name: SSRF via HTTP redirect bypass in webhook delivery Vulnerability Description: The Papra webhook delivery system contains an SSRF protection bypass vulnerability that allows any authenticated organization member to cause the server to send HTTP requests to internal addresses (such as loopback, link-local, and RFC 1918 ranges) while ignoring the target address. SSRF protection validates registered webhook URLs but does not check redirect targets. The HTTP client ( ) automatically follows 3xx responses, and redirect targets are not checked against the blacklist. An attacker can register a webhook pointing to a server under their control, which redirects to any internal address. This vulnerability was confirmed using the official Docker image. The fix requires adding one line of code to the webhook HTTP client. Impact Scope Affected Versions: <= 26.4.0 Fixed Versions: 26.5.0 Severity: Low (3.5 / 10) CVSS v3 Base Metrics: - Attack Vector: Network - Attack Complexity: High - Privileges Required: Low - User Interaction: None - Scope: Changed - Confidentiality: Low - Integrity: None - Availability: None Remediation In at line 16, set the option in the call to to prevent automatic redirection. The specific code is as follows: If redirection is needed in the future, the header should be verified using the existing check before re-issuing the request. POC Code Exploitation Steps 1. Start on a publicly accessible server (e.g., an Nginx server). The following example uses Papra's own health endpoint as the redirect target to demonstrate the bypass—in a cloud environment, replace with or any other internal address. 2. Register a webhook pointing to the redirect server. 3. Upload any document to trigger the event. 4. Confirm in the Papra server logs that received a GET request with . Impact Any authenticated organization member (administrator privileges are not required) can trigger this vulnerability. Papra servers send HTTP requests to internal addresses that are blocked by their own SSRF blacklist (127.0.0.0/8, 169.254.0.0/16, RFC 1918 ranges). This is a blind SSRF—the internal response body is written to , but there are no API routes that expose delivery records. The response content cannot be accessed via the Papra API. Internal network topology can be partially inferred based on whether requests succeed or fail (closed ports generate network errors; open ports return HTTP responses). HTTP 307 redirects preserve the POST method and body, allowing state change requests to internal services that accept unauthenticated POSTs. In cloud deployments (AWS, GCP, Azure), the instance metadata address 169.254.169.254 can be accessed using the same technique. Cloud metadata was not tested in the POC (in the local Docker environment, no metadata service exists). Response exfiltration via the Papra API remains unavailable.

Goal Reached Thanks to every supporter — we hit 100%!

SSRF bypass in Papra webhook delivery (Pre-Auth) with POC and patch

More from this source