All Projects

On alwaysdata's shared hosting infrastructure every customer account on a given physical host shares a single, non-polyinstantiated `/tmp` directory (mode `drwxrwxrwt` / `1777`), while the platform default umask is `022` — so any file a customer writes into `/tmp` is created world-readable (`644`).

Account isolation on these hosts is enforced only by cgroups + per-account Unix UIDs, and SSH is explicitly not chrooted (per alwaysdata's own documentation). As a result, any customer — on any plan, including the free plan — can read any other customer's world-readable files in `/tmp` on the same physical host. This is a cross-tenant confidentiality boundary violation: it lets a low-privileged tenant passively harvest other tenants' source code, configuration, and temporary artifacts.

The condition is confirmed on both the SSH tier (`ssh1`) and the web-application tier (`http21`), indicating it is fleet-wide. (Note: PHP `session.save_path` is per-account, so live sessions are not exposed — which bounds this at High rather than Critical.)

Exposed Endpoints / Affected Components

Steps to Reproduce

Requires two accounts you control (`A` and `B`, different customers) that land on the same physical host. In this report `A` = `steve-william` (uid 530469), `B` = `test-domain` (uid 530478), both on `ssh1`.

1. Create two free alwaysdata accounts with different emails; enable SSH on each (Remote access → SSH).
2. SSH into account A: `ssh A@ssh-A.alwaysdata.net`.
3. As A, write a file into the shared `/tmp` (created world-readable due to default umask 022):

 `echo "SECRET_OF_A" > /tmp/canary_A.txt`

4. In a second terminal, SSH into account B (a *different* customer): `ssh B@ssh-B.alwaysdata.net`.
5. As B, confirm you are a different UID on the same host: `id; hostname`.
6. As B, read account A's file: `cat /tmp/canary_A.txt` → A's content is returned. 7. Enumerate the real cross-tenant exposure (metadata only): `find /tmp -maxdepth 1 -type f ! -user "$(id -un)" -readable`.

Observed live: as account B, 65 files across 12 other live customer accounts were readable, including source archives (`*.tgz`), a config script (`inject_config.py`), an Omeka DB env file (`omeka_db_env_*`), financial PDFs, and cryptocurrency wallet backups. (No third-party file *content* was read — only names/owners/permissions were enumerated, per program rules.)

Proof of Concept (PoC)

Bash PoC Script, Python PoC Script, and other attachments are attached.

- Cross-tenant confidentiality breach affecting all customers sharing the same physical host.
- On the affected host (`ssh1`), approximately 882 customer home directories are co-located, allowing tenants to access world-readable temporary files belonging to other customers.
- Sensitive information that may be exposed includes source code, configuration files, temporary application data, and other confidential files.
- If a world-readable `.env` or configuration file contains database credentials, an attacker could use those credentials to access the victim's remotely reachable database (e.g., `mysql-<account>.alwaysdata.net:3306` or `postgresql-<account>.alwaysdata.net:5432`).
- This could lead to unauthorized access to another customer's database and the data stored within it.
- No other customers' files, credentials, or databases were accessed during testing. The impact assessment is based solely on the demonstrated file exposure and the resulting attack path.

- Polyinstantiate `/tmp` (and `/var/tmp`) per account — e.g. `pam_namespace` with per-account instances, or a per-account-namespace private `tmpfs` — so each tenant sees an isolated `/tmp`.
- And/or set the platform default umask to `077`.
- Optionally enable `fs.protected_regular=2` and per-account `/tmp` reaping.