Security vulnerabilities

Description

A cross-user file access vulnerability was identified in the shared hosting environment. The authenticated user remberme is able to read files owned by other users, such as:

/tmp/dashboard.env.local.bak

The file is owned by another account:

Owner: davidgoncalves
Group: davidgoncalves
Permissions: 664

The permission mode 664 grants read access to users outside the file owner/group through the other::r– permission.

Using the remberme account, I successfully verified that the file is readable, demonstrating a violation of expected cross-user filesystem isolation.

CVSS → CVSS v3.1: 7.0 (High)

The severity may increase if the affected files contain credentials, API keys, private source code, customer information, or other sensitive data.

Steps to Reproduce

1- Log in to the hosting environment using a normal account, e.g.: remberme@ssh1

2- Identify a file belonging to another user: stat -c 'owner=%U group=%G mode=%a file=%n' /tmp/dashboard.env.local.bak

3- The file reports:

owner=davidgoncalves
group=davidgoncalves
mode=664

4- Check the ACL: getfacl -p /tmp/dashboard.env.local.bak

5- The output confirms:

user::rw-
group::rw-
other::r--

6- While authenticated as remberme, verify read access: test -r /tmp/dashboard.env.local.bak && echo "READABLE" || echo "NOT_READABLE"

7- The result is: READABLE

8- A non-destructive read test was performed:

head -c 1 /tmp/dashboard.env.local.bak >/dev/null 2>&1 \
&& echo "CROSS-USER READ CONFIRMED" \
|| echo "READ FAILED"

9- Result: CROSS-USER READ CONFIRMED
No modification, deletion, or execution of the other user's file was performed.

Actual Behaviour

A normal authenticated user is able to obtain read access to a file owned by another user/account. This demonstrates insufficient filesystem isolation between users in the shared hosting environment.

Expected Behaviour

Files belonging to another customer/user should not be readable by an unrelated authenticated account unless explicitly shared. The platform should enforce strict per-user filesystem isolation and ensure that customer-owned files are inaccessible to other customers.

Impact An attacker with a valid low-privileged hosting account could potentially enumerate and read files belonging to other users when those files are created with overly permissive permissions.

Depending on the affected files, this could expose:

1- Application source code
2- Configuration files
3- Database credentials
4- API keys/tokens
5- Environment variables
6- Internal application data
7- Customer-specific information
8- Backup files

The demonstrated .env.local.bak filename is particularly concerning because environment/backup files commonly contain application configuration and secrets.

Business Impact

This issue breaks the fundamental tenant isolation expected from a multi-user hosting platform.

Successful exploitation could allow one customer to access another customer's confidential application data or credentials, potentially resulting in:

1- Customer data exposure
2- Credential/API-key compromise
3- Unauthorized access to external services
4- Loss of customer trust
5- Privacy and compliance concerns
6- Increased impact from chained attacks

The business impact depends on the sensitivity of the files exposed through the insecure permissions.

Conclusion

The testing demonstrates that the remberme account can read a file owned by the unrelated davidgoncalves account due to permissive filesystem permissions.

The issue is therefore reproducible and not merely theoretical. I recommend enforcing strict per-user filesystem isolation and preventing files created by one customer from being readable by other customers by default.

Thanks