- Status Closed
-
Assigned To
cbay - Private
Opened by NOoobsec - 26.09.2026
Last edited by cbay - 26.09.2026
FS#507 - Server-Side Request Forgery (SSRF) via `reverse_proxy` Site Type
Severity: High
CVSS 3.1: 7.5
Affected Component: `reverse_proxy` site type (`url` / “URL distante”)
## Summary
The `reverse_proxy` site type allows the configured `url` to be fetched server-side without restricting access to private, loopback, or link-local addresses.
I confirmed that the server can make external requests and access `127.0.0.1`. I did not enumerate internal services in accordance with the program rules.
## Steps to Reproduce
1. Set the site type to `reverse_proxy` and configure:
{"type":"reverse_proxy","url":"http://example.com/"}
The site returns the content from Example Domain, confirming server-side fetching.
2. Change the URL to:
{"url":"http://127.0.0.1/"}
The response changes to:
404 Site not found Request ID: ... Server: Apache
This confirms that the request reached the platform's loopback interface.
3. I also tested:
{"url":"http://169.254.169.254/latest/meta-data/"}
which returned `503`. No cloud metadata was obtained.
## Impact
An attacker can control a server-side request destination and reach the platform's loopback interface.
This creates an SSRF primitive that could potentially be used to access internal services or other restricted resources, depending on the services reachable from the server. Internal service enumeration was not performed.
## Recommendation
* Block private, loopback, and link-local IP ranges.
* Validate the resolved IP address, not only the supplied hostname.
* Protect against DNS rebinding.
* Apply outbound/egress network filtering for server-side requests.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Addendum — additional context (observation via own SSH account, not SSRF-tested)
While reviewing my own hosting account's environment over SSH (the ssh-[account] in-scope host, using my own credentials), I observed that the server's loopback interface (127.0.0.1) exposes a number of internal services, including listeners on ports 8080, 8007, 8100, 8083, 53 (dnsdist), and several others, and that the host sits on an internal subnet (185.31.40.0/22, resolver domain paris1.alwaysdata.com).
This is provided only as supporting context for the SSRF finding: it indicates that the reverse-proxy SSRF's reach to 127.0.0.1 points at a live internal control plane rather than a dead end.
Per the program's SSRF rule ("do not go playing around on any internal networks"), I have not enumerated these services or attempted to reach them through the SSRF. Determining what those internal services expose — and whether any is reachable via the SSRF — is left to your investigation, as the policy directs.