CVE-2026-48051

Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client. This issue has been patched in version 26.5.0.

Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client. This issue has been patched in version 26.5.0.

Summary

Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client.

Details

The vulnerable call

The webhook HTTP client in packages/webhooks/src/webhooks.services.ts (lines 16–19) calls ofetch.raw() without specifying a redirect option:

const response = await ofetch.raw<unknown>(url, {
  ...options,
  ignoreResponseError: true,
  // no `redirect` option — defaults to 'follow' per Fetch API spec
});

ofetch is a thin wrapper around the WHATWG Fetch API. The Fetch specification defines three redirect modes — follow, error, and manual — and sets follow as the default. In follow mode, the HTTP implementation resolves the redirect chain internally and returns only the final response; application code receives the terminal response with no indication that any redirects occurred. ofetch 1.4.1 does not set a redirect option in its internal fetch() call, so the default applies. The ignoreResponseError: true option only suppresses exceptions on non-2xx responses; it has no effect on redirect handling.

How the bypass works

The SSRF protection runs at two points: registration time (checkWebhookUrlIsSsrfSafe, webhooks.usecases.ts:34) and delivery time (filterOutSsrfUnsafeWebhooks, webhooks.usecases.ts:124). Both checks work the same way:

// apps/papra-server/src/modules/shared/ssrf/ssrf.services.ts, lines 20-27
const hostname = getUrlHostname(url);
return isHostnameSsrfSafe({ hostname, allowedHostnames, dnsLookup, logger });
// Resolves hostname → checks all resulting IPs against the blocklist
// Blocklist covers: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
//                   169.254.0.0/16, ::1, and other reserved ranges

Both checks operate on url — the registered webhook URL, a public hostname that resolves to a public IP and passes the blocklist. Neither check has any visibility into where the HTTP client will end up after following a redirect. The Location header in a 3xx response is never extracted, never DNS-resolved, and never compared against the blocklist. By the time the redirect target is known to the Fetch implementation, the request has already been made.

The developer cannot observe this gap. The Fetch API gives no opportunity to inspect the redirect target before following it.

Evidence

Attacker's redirect server receives the POST and returns 302:

[2026-05-08T15:55:38.388647] POST /redirect
  User-Agent: papra-webhook-client    ← set only in webhooks.services.ts:47
  X-Forwarded-For: <REDACTED>
"POST /redirect HTTP/1.1" 302 -

Papra's inbound request log immediately after — this is the server logging a request arriving at itself:

{"message":"Request completed","timestampMs":1778255738420,
 "data":{"status":200,"method":"GET","path":"/api/health",
         "userAgent":"papra-webhook-client"}}   ← outbound UA on an inbound request

papra-webhook-client is set exclusively by the outbound webhook delivery code (webhooks.services.ts:47). Its presence on an inbound log entry is only possible if Papra's own HTTP client followed the 302 and made a request to the loopback. The delivery record confirms the internal endpoint responded HTTP 200:

{"message":"Webhook triggered","timestampMs":1778255738422,
…

Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client. This issue has been patched in version 26.5.0.

Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client. This issue has been patched in version 26.5.0.

Summary

Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client.

Details

The vulnerable call

The webhook HTTP client in packages/webhooks/src/webhooks.services.ts (lines 16–19) calls ofetch.raw() without specifying a redirect option:

const response = await ofetch.raw<unknown>(url, {
  ...options,
  ignoreResponseError: true,
  // no `redirect` option — defaults to 'follow' per Fetch API spec
});

ofetch is a thin wrapper around the WHATWG Fetch API. The Fetch specification defines three redirect modes — follow, error, and manual — and sets follow as the default. In follow mode, the HTTP implementation resolves the redirect chain internally and returns only the final response; application code receives the terminal response with no indication that any redirects occurred. ofetch 1.4.1 does not set a redirect option in its internal fetch() call, so the default applies. The ignoreResponseError: true option only suppresses exceptions on non-2xx responses; it has no effect on redirect handling.

How the bypass works

The SSRF protection runs at two points: registration time (checkWebhookUrlIsSsrfSafe, webhooks.usecases.ts:34) and delivery time (filterOutSsrfUnsafeWebhooks, webhooks.usecases.ts:124). Both checks work the same way:

// apps/papra-server/src/modules/shared/ssrf/ssrf.services.ts, lines 20-27
const hostname = getUrlHostname(url);
return isHostnameSsrfSafe({ hostname, allowedHostnames, dnsLookup, logger });
// Resolves hostname → checks all resulting IPs against the blocklist
// Blocklist covers: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
//                   169.254.0.0/16, ::1, and other reserved ranges

Both checks operate on url — the registered webhook URL, a public hostname that resolves to a public IP and passes the blocklist. Neither check has any visibility into where the HTTP client will end up after following a redirect. The Location header in a 3xx response is never extracted, never DNS-resolved, and never compared against the blocklist. By the time the redirect target is known to the Fetch implementation, the request has already been made.

The developer cannot observe this gap. The Fetch API gives no opportunity to inspect the redirect target before following it.

Evidence

Attacker's redirect server receives the POST and returns 302:

[2026-05-08T15:55:38.388647] POST /redirect
  User-Agent: papra-webhook-client    ← set only in webhooks.services.ts:47
  X-Forwarded-For: <REDACTED>
"POST /redirect HTTP/1.1" 302 -

Papra's inbound request log immediately after — this is the server logging a request arriving at itself:

{"message":"Request completed","timestampMs":1778255738420,
 "data":{"status":200,"method":"GET","path":"/api/health",
         "userAgent":"papra-webhook-client"}}   ← outbound UA on an inbound request

papra-webhook-client is set exclusively by the outbound webhook delivery code (webhooks.services.ts:47). Its presence on an inbound log entry is only possible if Papra's own HTTP client followed the 302 and made a request to the loopback. The delivery record confirms the internal endpoint responded HTTP 200:

{"message":"Webhook triggered","timestampMs":1778255738422,
…