Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by ihor-herasymovych - 13.10.2026
Last edited by cbay - 13.10.2026

Asset: ssh-[account].alwaysdata.net shared web servers (e.g. ssh2) — host network namespace / loopback Severity: high — CVSS 6.2 (v4.0) CVSS vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Description

All customer accounts on a shared alwaysdata web server run in the host's single, shared network namespace (readlink /proc/self/ns/net ⇒ net:[4026531833], the init ns, identical for every account on the server). Consequently 'localhost' / 127.0.0.1 is NOT private per account: any service a customer binds to loopback is reachable by every other customer that holds a shell on the same physical server, and an unprivileged co-tenant can see the whole host's sockets (ss shows hundreds of host-wide connections and other tenants' unix-socket paths).

This has now been demonstrated end-to-end – READ and WRITE – between two accounts we own, co-located on the same server (ssh2), to avoid touching any third party:
Attacker = account A (uid 554081), running no service of its own.
Victim = account B (uid 553290), a different customer/uid, running a small HTTP service bound to 127.0.0.1:<port> with a startup-generated secret (stored in a 0600 file under its 1770 home, so unreadable on the filesystem by A) and a state file.

From account A, reaching only the shared loopback:
GET http://127.0.0.1:<port>/canary returned the victim's private secret verbatim (confidentiality: A obtained a value that existed only inside B's process and an owner-only file it cannot read on disk).
POST http://127.0.0.1:<port>/set changed the victim's server-side state; the change persisted to B's own state file on disk (independently verified from B's shell), not merely echoed (integrity: A mutated another tenant's application state).

The platform's own loopback services are correctly auth-gated (monit :2812, PowerDNS API :8083, almonitor metrics :8593, :7102 all return 401), which confirms the exposure is specifically other customers' services. A customer binding a service to 127.0.0.1 has a reasonable, universal expectation that it is private to their account; the shared network namespace breaks that expectation, so this is a platform isolation gap acting in conjunction with customer applications.

Observed at scale on real tenants (read-only, one identifying page title each; the apps were NOT driven and no data was pulled or written): curl http://127.0.0.1:8530/ ⇒ HTTP 200, a co-tenant's private trading-bot control panel 'Flash Sniper' (Werkzeug/Python, loopback-only bind, NO authentication); curl http://127.0.0.1:5000/ ⇒ HTTP 200, a different co-tenant's app 'OmniRoute' (NO authentication). Because those real services answer unauthenticated exactly like the owned victim in the PoC, the same read-AND-write exposure applies to them and to every similarly configured tenant on each shared server (~2000 accounts per server). alwaysdata can confirm the scale internally without any further third-party interaction.

Prerequisites
One ordinary hosting account with SSH on the same physical server as the victim (co-location). Accounts are packed ~2000 per shared server, so any shell co-locates with many victims. No special role, no privilege escalation, and no filesystem access to the victim is needed – only the shared loopback.
Impact

Full cross-tenant compromise of any customer service that binds to localhost/127.0.0.1 (or any port) without its own authentication. An attacker needing only an ordinary co-located shell can READ the service's private data and secrets and WRITE/control its server-side state. Demonstrated end-to-end on our own two accounts: A read a secret that lived only inside B's process and an owner-only file, and A persisted an arbitrary change to B's application state (verified on B's disk). Two real co-tenant apps already observed answering unauthenticated on loopback (a trading-bot control panel and an AI validator) exhibit the same pattern, so for affected tenants the real-world impact is unauthorized read AND modification of customer data/services at scale.