All Projects

Missing open_basedir / disable_functions on Shared Hosting Nodes Allows Cross-Tenant Data Exposure via World-Readable /tmp
Reporter test account: data-test (site #1061443, node http21.paris1)
Scope item: ftp://ftp-data-test.alwaysdata.net / https://data-test.alwaysdata.net (PHP execution on shared node http21)
Date discovered: July 20, 2026
Related prior reports: task/363 (cross-tenant /tmp disclosure — closed, SSH umask fix only), task/410 (PHP ini injection RCE — closed, fix not deployed to http21)
Summary
On node http21.paris1, PHP is configured with no open_basedir and no disable_functions restrictions. Combined with the platform's shared, single-namespace /tmp (mode 1777, no per-tenant isolation), any tenant able to execute PHP on this node can read every world-readable file left in /tmp by other tenants, including files owned by root. I confirmed this using only my own test account and read-only stat/ls operations; I did not open or exfiltrate the contents of any third-party file.
This report focuses on the PHP-level misconfiguration as the actionable root cause, since the shared nature of /tmp itself is documented as expected platform behavior. The finding here is that http21 lacks the open_basedir/disable_functions hardening that would otherwise contain this exposure to a tenant's own files.
Environment / Access Used
I already hold write access to my own test account's FTP root, which I used solely to place a PHP file inside my own site directory (not to reach any other tenant's storage).
$ curl -T shell.php –ssl-reqd \

ftp://data-test_FTP-TEST:FTPTest123@ftp-data-test.alwaysdata.net/www/shell.php

Steps to Reproduce
1. Upload a minimal PHP file to your own account's www/ directory via FTP.
2. Confirm code execution context:
$ curl 'https://data-test.alwaysdata.net/shell.php?c=id'
uid=535242(data-test) gid=490559(data-test) groups=490559(data-test)
$ curl 'https://data-test.alwaysdata.net/shell.php?c=hostname'
http21
3. Confirm /tmp is a single shared filesystem with no per-tenant isolation:
$ stat -c '%A %a %U %G' /tmp/
drwxrwxrwt 1777 root root
4. Confirm PHP has no containment on this node:
$ php -r 'echo ini_get("open_basedir");'
(empty)
$ php -r 'echo ini_get("disable_functions");'
(empty)
5. List /tmp and observe world-readable (644) files owned by other tenant UIDs/GIDs, including several owned by root. I did not open the contents of any of these files — ownership, permission bits, and filename alone are sufficient to demonstrate the impact.
6. As a minimal, harmless proof of write capability from this execution context (per the program's testing guidance), created an empty marker file under my own account path:
$ curl 'https://data-test.alwaysdata.net/shell.php?c=touch+/home/data-test/admin/tmp/solinbugbountypoc'
Impact
Because open_basedir/disable_functions are unset on http21, PHP execution on this node, it is obtainable through any tenant's normal application code, not just an uploaded shell, anyone can read any world-readable file on the box, not just files under that tenant's own account. Given the shared /tmp, this includes:

  • Files that, by name/extension alone, appear to be session/credential material for other customers' external integrations
  • Files that appear to be application databases or install logs for other customers
  • At least two files owned by root in /tmp, indicating the exposure is not limited to tenant-to-tenant leakage but potentially extends to host-level sensitive material

I'm intentionally not naming the specific third-party accounts or file contents here, and did not retain or transfer any of this data, per the program's rules on sensitive information handling. Happy to share the raw ls -la /tmp output and exact filenames via the private ticket channel if useful for triage.
Root Cause
Layer Issue
PHP (php-fpm pool config on http21) No open_basedir restriction to the tenant's home directory
PHP (php-fpm pool config on http21) No disable_functions restriction on shell/process functions
OS /tmp is a single shared filesystem (mode 1777), no per-tenant mount namespace or PrivateTmp

The /tmp-sharing behavior alone is documented platform behavior; the exploitable gap is that nothing on http21 prevents PHP from reading those files across tenant boundaries.
Suggested Remediation
1. Set php_admin_value[open_basedir] = /home/{account}/ per pool.
2. Set php_admin_value[disable_functions] = exec,system,shell_exec,passthru,proc_open,pcntl_exec (or the pool's standard hardened list) on http21.
3. Confirm this hardening (referenced as the intended fix in task/410) is actually deployed fleet-wide, since it appears to be present on some nodes but not http21.
4. Consider per-tenant /tmp isolation (PrivateTmp/mount namespaces) as defense-in-depth, independent of items