CVE-2026-48051 Overview
CVE-2026-48051 is a Server-Side Request Forgery (SSRF) [CWE-918] vulnerability in Papra, a minimalistic document management and archiving platform. Versions prior to 26.5.0 contain a webhook delivery flaw that allows any authenticated organisation member to force the server into making HTTP requests to internal network addresses. The SSRF protection validates the initially registered webhook URL but fails to re-check redirect destinations. The underlying HTTP client, ofetch, automatically follows 3xx responses, permitting requests to loopback, link-local, and RFC-1918 ranges. The maintainers patched the issue in version 26.5.0.
Critical Impact
Authenticated attackers can bypass SSRF controls to probe internal infrastructure through the Papra server, though impact is limited to information exposure via outbound HTTP requests.
Affected Products
- Papra document management platform (versions prior to 26.5.0)
- Official Papra Docker image (confirmed exploitable via live test)
- Self-hosted Papra deployments running affected releases
Discovery Timeline
- 2026-07-27 - CVE-2026-48051 published to NVD
- 2026-07-30 - Last updated in NVD database
Technical Details for CVE-2026-48051
Vulnerability Analysis
The vulnerability resides in Papra's webhook delivery system. When an organisation member registers a webhook, the application checks the supplied URL against a blocklist covering loopback, link-local, and RFC-1918 address ranges. This validation occurs only once, before the request is dispatched. The HTTP client used for delivery, ofetch, transparently follows HTTP redirects (3xx responses) without applying the same address filtering to the redirect target. An authenticated attacker registers a webhook pointing at an attacker-controlled external server. When Papra delivers a webhook event, the malicious server responds with a redirect to an internal address such as http://127.0.0.1, http://169.254.169.254, or an RFC-1918 host. The Papra server follows the redirect and issues an HTTP POST to the internal target. Exploitation was confirmed against the official Docker image.
Root Cause
The root cause is incomplete SSRF validation coverage. The blocklist enforcement runs against the user-supplied webhook URL but does not intercept the destinations produced by automatic redirect following inside ofetch. The redirect target is never re-validated against the same blocklist. The upstream fix is described by the maintainers as a single-line change to the webhook HTTP client.
Attack Vector
Exploitation requires an authenticated account with permission to register webhooks in an organisation. The attacker registers a webhook pointing to a host they control. When Papra emits a webhook event, the attacker's server returns an HTTP 3xx response with a Location header referencing an internal address. Papra's HTTP client follows the redirect and issues the POST to the internal endpoint. See the GitHub Security Advisory for full technical details.
Detection Methods for CVE-2026-48051
Indicators of Compromise
- Webhook registrations pointing to unfamiliar external hosts that immediately return 3xx responses during delivery.
- Outbound Papra server connections followed by inbound connections to internal-only services such as metadata endpoints or RFC-1918 hosts.
- Application logs showing webhook delivery attempts whose final resolved URL differs from the registered URL.
Detection Strategies
- Audit the Papra webhook registration table for URLs owned by non-corporate domains or recently added by low-privileged organisation members.
- Instrument egress traffic from the Papra host and alert on HTTP 3xx responses that redirect to private address ranges.
- Correlate webhook delivery timestamps with unexpected requests to internal services or cloud metadata endpoints (169.254.169.254).
Monitoring Recommendations
- Log the full redirect chain for every webhook delivery, including the final resolved host and IP.
- Alert on any Papra outbound request whose resolved destination falls inside loopback, link-local, or RFC-1918 space.
- Track anomalous rates of webhook registration or modification per organisation member.
How to Mitigate CVE-2026-48051
Immediate Actions Required
- Upgrade Papra to version 26.5.0 or later, which contains the fix to the webhook HTTP client.
- Review existing webhook configurations and remove any that point to unknown or untrusted external hosts.
- Restrict webhook registration permissions to trusted organisation members where feasible.
Patch Information
The issue is fixed in Papra 26.5.0. The maintainers describe the remediation as a single-line change to the webhook HTTP client that disables or validates redirect following. Refer to the GitHub Security Advisory GHSA-5g86-85rp-f9hx for release details.
Workarounds
- Deploy Papra behind an egress proxy that blocks outbound HTTP requests to loopback, link-local, and RFC-1918 destinations.
- Run Papra on a network segment that has no route to internal management interfaces or cloud metadata services.
- Temporarily disable the webhook feature for organisations that do not require it until the upgrade is applied.
# Example egress restriction using iptables to block SSRF targets from the Papra container
iptables -A OUTPUT -m owner --uid-owner papra -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner papra -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner papra -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner papra -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner papra -d 192.168.0.0/16 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
