Security vulnerabilities

I discovered a path traversal vulnerability in the Working Directory field of the alwaysdata Service command feature.

The Service feature allows users to specify a Working Directory from which their configured command is executed. However, the Working Directory is not properly restricted to the user's authorized directory.

By using ../ path traversal sequences, an authenticated user can escape the intended Working Directory boundary and point the service to another directory.

The service then executes commands from the resulting directory. Using the standard Linux ls command, the service logs disclose the names of files and directories contained within the target directory.

Additionally, when a non-existent directory is specified, the service returns an error indicating that the directory does not exist. This provides a directory-existence oracle, allowing an attacker to determine whether specific directories exist.

The user account used for the proof of concept was:

mexmos

This account belongs to me and is not associated with another alwaysdata customer. All testing was performed using my own account and controlled test data.

1. Log in to an alwaysdata account.
2. Go to Services and click Add service.
3. In the Command field, enter:

ls

4. In the Working Directory field, enter:

../mexmos/www

5. Submit the service configuration.
6. Go back to Services and open the newly created service.
7. Open the service Logs.
8. The output of the ls command is displayed in the logs, revealing the names of files and directories inside the specified www directory.

STDOUT: index.html

Additional files and directories present in the directory are also returned.

The issue also allows determining whether a specific directory exists.

../mexmos/www/existing-directory

The service successfully starts and ls returns its contents.

../mexmos/www/non-existent-directory

The service returns an error indicating that the directory does not exist.

This creates an existence oracle that allows an attacker to distinguish between existing and non-existing directories.

Therefore, the vulnerability provides:

Path Traversal → Directory Existence Disclosure → Directory/File Name Enumeration

An authenticated alwaysdata user who has access to the Service command feature can bypass the intended Working Directory restriction and enumerate filesystem entries outside their intended directory.

The attacker can:

* Determine whether specific directories exist.
* Enumerate directory contents using ls.
* Obtain filenames and directory names.
* Map the structure of accessible directories under the target www directory.

In a shared-hosting environment, this can disclose the filesystem structure of other hosted directories.

For example, the www directory of a hosted website may contain filenames revealing:

* Application structure
* Backup files
* Configuration-related filenames
* Internal directories
* Application resources

The vulnerability therefore results in unauthorized directory and file-name enumeration across the intended Working Directory boundary.

The proof of concept is limited to filename/directory-name enumeration. I did not access or extract file contents from other customers.

The Working Directory should be restricted to the directories authorized for the service.

Traversal sequences such as ../ should not allow the resulting canonical path to escape the authorized directory.

For example, if a service is restricted to:

/home/mexmos/

a Working Directory containing:

../other-user/www

should not be accepted.

The application should:

* Canonicalize/resolve the supplied Working Directory.
* Resolve all .. components before authorization.
* Verify that the resulting canonical path is within the directory authorized for the service.
* Reject the request if the canonical path escapes the authorized directory.

The security check should be performed against the resolved path rather than the raw user-supplied string.

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)

Additional impact:

Directory Enumeration / File and Directory Name Disclosure

I recommend evaluating this as a Medium-severity access-control/path-traversal issue, depending on the intended filesystem isolation boundary of the Service feature.

The demonstrated impact is directory existence disclosure and filename/directory enumeration.

This report does not claim arbitrary file-content disclosure, arbitrary file modification, or root privileges.

Testing was performed using my own account, mexmos, and controlled test data.

The mexmos account belongs to me and is not associated with another alwaysdata customer.

No sensitive customer file contents were accessed, retained, or exfiltrated.