Skip to main content
VulnerabilityPublished

CVE-2026-48051: papra · Server-Side Request Forgery (SSRF)

Affects papraSource CVE Database V5

0

Not known to be exploited · CVSS 3.5 Low : upgrade to 26.5.0 when convenient.

Data as of 27 Oct 2026, 05:11 UTC

CVSS 3.1 base score
3.5Low
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 16% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 26.5.0
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade papra to 26.5.0.

Affected software

ProductAffectedFixed in
papra-hqpapraAffected
  • <26.5.0
Fixed in
  • 26.5.0

AI-suggested

This vulnerability is patched in papra version 26.5.0. Users should upgrade to version 26.5.0 or later to remediate the SSRF protection bypass. No other mitigation is indicated by the vendor advisory. Patch status is confirmed by the vendor stating the fix is included in version 26.5.0.

Description

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.

References

Community reviews

Loading reviews…