Security vulnerabilities

  • Status Closed
  • Assigned To
    cbay
  • Private
Attached to Project: Security vulnerabilities
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.

Closed by  cbay
26.09.2026 15:36
Reason for closing:  Duplicate
Additional comments about closing:  

https://security.alwaysda ta.com/task/470

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing