https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 02:00:45 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-48051 <p>Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra&#39;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.</p> <p>Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra&#39;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.</p> https://db.gcve.eu/vuln/fkie_cve-2026-48051 https://db.gcve.eu/vuln/ghsa-5g86-85rp-f9hx <p><strong>Affected:</strong> npm: @papra/webhooks</p> <p>### Summary</p> <p>Papra&#39;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.</p> <p>### Details</p> <p>**The vulnerable call**</p> <p>The webhook HTTP client in `packages/webhooks/src/webhooks.services.ts` (lines 16–19) calls `ofetch.raw()` without specifying a `redirect` option:</p> <p>```typescript const response = await ofetch.raw&lt;unknown&gt;(url, { ...options, ignoreResponseError: true, // no `redirect` option — defaults to &#39;follow&#39; per Fetch API spec }); ```</p> <p>`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…</p> <p><strong>Affected:</strong> npm: @papra/webhooks</p> <p>### Summary</p> <p>Papra&#39;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.</p> <p>### Details</p> <p>**The vulnerable call**</p> <p>The webhook HTTP client in `packages/webhooks/src/webhooks.services.ts` (lines 16–19) calls `ofetch.raw()` without specifying a `redirect` option:</p> <p>```typescript const response = await ofetch.raw&lt;unknown&gt;(url, { ...options, ignoreResponseError: true, // no `redirect` option — defaults to &#39;follow&#39; per Fetch API spec }); ```</p> <p>`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…</p> https://db.gcve.eu/vuln/ghsa-5g86-85rp-f9hx