CVE-2026-35461: Papra SSRF Vulnerability

CVE-2026-35461 Overview

CVE-2026-35461 is a Server-Side Request Forgery (SSRF) vulnerability affecting Papra, a minimalistic document management and archiving platform. Prior to version 26.4.0, the Papra webhook system allows authenticated users to register arbitrary URLs as webhook endpoints without any validation of the destination address. The server makes outbound HTTP POST requests to registered URLs—including localhost, internal network ranges, and cloud provider metadata endpoints—on every document event.

Critical Impact

Authenticated attackers can leverage this SSRF vulnerability to probe internal network infrastructure, access cloud provider metadata services (such as AWS IMDSv1), and potentially exfiltrate sensitive configuration data or credentials from the internal environment.

Affected Products

• Papra versions prior to 26.4.0
• Self-hosted Papra deployments with webhook functionality enabled
• Cloud-hosted Papra instances with access to internal networks or metadata services

Discovery Timeline

• April 7, 2026 - CVE-2026-35461 published to NVD
• April 9, 2026 - Last updated in NVD database

Technical Details for CVE-2026-35461

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The SSRF occurs because the webhook registration endpoint fails to implement proper URL validation or allowlisting. When a user creates or triggers a webhook, the Papra server initiates an outbound HTTP POST request to the user-specified URL without verifying whether the destination is a safe, external address.

The attack requires authentication, limiting the attack surface to users with valid credentials. However, once authenticated, the attacker gains the ability to make the server perform requests on their behalf to arbitrary destinations. This is particularly dangerous in cloud environments where metadata services (such as http://169.254.169.254/) can be queried to retrieve instance credentials, API keys, and sensitive configuration data.

Root Cause

The root cause of CVE-2026-35461 lies in the absence of URL validation logic within the webhook registration and execution workflow. The application accepts any user-supplied URL and makes HTTP requests to it without:

1. Validating the URL scheme (allowing non-HTTP protocols in some cases)
2. Checking whether the destination IP address falls within private or reserved ranges (e.g., 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
3. Blocking access to cloud metadata endpoints (e.g., 169.254.169.254)
4. Implementing a URL allowlist or denylist mechanism

Attack Vector

The attack is network-based and requires low-privilege authenticated access. An attacker can exploit this vulnerability by:

1. Authenticating to the Papra application with valid credentials
2. Registering a malicious webhook URL pointing to an internal resource (e.g., http://127.0.0.1:8080/admin or http://169.254.169.254/latest/meta-data/)
3. Triggering a document event that causes the webhook to fire
4. Receiving the HTTP response data or observing side effects from the internal request

The vulnerability allows the attacker to bypass network segmentation and firewalls, as requests originate from the trusted Papra server rather than an external source.

Detection Methods for CVE-2026-35461

Indicators of Compromise

• Webhook registrations containing URLs pointing to internal IP ranges (127.0.0.1, 10.x.x.x, 172.16-31.x.x, 192.168.x.x)
• Webhook URLs targeting cloud metadata endpoints (e.g., 169.254.169.254, metadata.google.internal)
• Unusual outbound HTTP traffic from the Papra server to internal services
• Repeated webhook registration attempts with incrementing port numbers (port scanning behavior)

Detection Strategies

• Monitor webhook registration events and alert on URLs containing private IP address ranges or metadata service hostnames
• Implement network-level monitoring for outbound connections from the Papra application server to internal networks
• Review application logs for webhook execution failures or unexpected response codes from internal services
• Deploy web application firewalls (WAF) with SSRF detection rules to inspect outbound request destinations

Monitoring Recommendations

• Enable verbose logging for all webhook registration and execution events in Papra
• Configure network intrusion detection systems (IDS) to alert on traffic patterns consistent with SSRF exploitation
• Establish baseline outbound connection patterns for the Papra server and alert on deviations
• Monitor cloud provider audit logs for unexpected metadata service access attempts originating from application instances

How to Mitigate CVE-2026-35461

Immediate Actions Required

• Upgrade Papra to version 26.4.0 or later immediately
• Audit existing webhook configurations and remove any entries pointing to internal or suspicious addresses
• Implement network-level controls to restrict outbound connections from the Papra server to approved external destinations only
• Review application logs for evidence of prior exploitation attempts

Patch Information

The vulnerability is fixed in Papra version 26.4.0. The patch implements proper URL validation to prevent webhook registration with internal network addresses, localhost, and cloud metadata endpoints. For detailed patch information, see the GitHub Security Advisory.

Workarounds

• If immediate upgrade is not possible, disable the webhook functionality entirely until the patch can be applied
• Implement network egress filtering at the firewall level to block outbound connections to private IP ranges and metadata endpoints from the Papra server
• Deploy a reverse proxy in front of the Papra application that inspects and blocks outbound SSRF attempts
• Restrict webhook registration capabilities to trusted administrator accounts only through access control modifications

# Example iptables rules to block SSRF to internal networks (apply on Papra server)
# Block localhost
iptables -A OUTPUT -d 127.0.0.0/8 -m owner --uid-owner papra -j DROP
# Block private networks
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner papra -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner papra -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner papra -j DROP
# Block cloud metadata endpoint
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner papra -j DROP