Root Cause Analysis

Document360

Server-Side Request Forgery (SSRF) in the Knowledge Base attachment download endpoint

11th June 2026

Problem

An unauthenticated Server-Side Request Forgery (SSRF) vulnerability was identified on the Knowledge Base attachment-download endpoint (GET /api/document/download-file?url=), reported and validated.

This endpoint supports a legitimate feature: when a reader clicks a file attachment in a Knowledge Base article, the server fetches the file and streams it back to the browser so that it downloads cleanly rather than opening in the browser. The endpoint accepted a "url" parameter and fetched it without validating where the request was being sent. As a result, a caller could supply an arbitrary URL - including internal or private network addresses and cause the server to make outbound requests to those destinations on their behalf.

Impact

No sensitive or customer data was disclosed by this vulnerability. While SSRF is classified as critical because of its potential, the actual exposure in this case was limited and contained:

The report demonstrated that the server could be induced to issue outbound requests to internal network addresses and to return responses from publicly facing components.
The cryptographic material observed (OIDC / JWKS) is public by design — these are public verification keys and discovery metadata that any client is intended to read. They contain no secrets and cannot be used to forge tokens or impersonate users. Signing keys are managed per environment, and private keys were never exposed.
Protected backend services were not accessed. For the secrets vault and storage components, the report confirmed only that the network endpoints were reachable (via response timing) — not that any data was retrieved. These services require authenticated access, which the vulnerability could not provide. No keys, secrets, files, or stored data were extracted.
No customer or tenant data was accessible through this endpoint at any point.

In summary, the issue allowed unauthorized outbound requests from our infrastructure, but the information actually observable was limited to non-sensitive, public-by-design material and confirmation of network reachability. There was no compromise of confidential data.

Cause

The download-proxy endpoint was introduced to force browser downloads of file attachments. Its implementation fetched the caller-supplied URL directly and did not apply input validation or destination restrictions on that URL. Specifically, it lacked:

a restriction limiting fetches to Document360's own trusted content domains;
blocking of internal/private, loopback, link-local, and cloud-metadata network ranges;
protocol and port restrictions; and
protection against redirect- and DNS-based bypass techniques.

Root cause classification: Code defect — an outbound “fetch-on-behalf-of-the-user” capability was implemented without a destination allow-list.

Resolution

The endpoint has been comprehensively hardened with a deny-by-default, allow-list model, applied consistently across every layer that serves this functionality:

Strict first-party allow-list — the server now fetches only Document360's own trusted content/CDN domains; any other destination is rejected. External links a user pastes into an article now open directly in the browser instead of being fetched by our servers.
Internal-network protection — requests to private, loopback, link-local, shared (CGNAT), and cloud-metadata IP ranges are blocked (IPv4 and IPv6), even when a hostname resolves to such an address.
Protocol and port restrictions — only standard web protocols (HTTP/HTTPS) on standard ports are permitted; URLs containing embedded credentials are rejected.
Bypass protection — redirects are re-validated against the allow-list, and the destination address is re-checked at connection time, defeating DNS-rebinding and redirect-based evasion.
Safe response handling — fetched content is always returned as an opaque download with hardening headers, so the endpoint cannot be misused to serve active content.
Resource limits — request timeouts and a maximum response size were added.

The fix was developed with automated tests, validated end-to-end (all malicious request patterns are now rejected while legitimate attachment downloads continue to work), peer-reviewed, and released in patch version 12.5.1.2.2.

Preventive Action