Security vulnerabilities

Reporter: Li Xian (otterlysecure)
Date: 22 Sep 2025 (UTC+8)
Asset: Hosting control panel → virtual host configuration for any domain

Summary

The hosting control panel accepts unvalidated paths for a site’s Root directory and writes them directly into the Apache vhost DocumentRoot. By setting DocumentRoot to /, an attacker can publish arbitrary world-readable files from the server filesystem to the internet (e.g., /etc/passwd, /etc/hosts) under the attacker’s domain. This is a tenant isolation bypass and information disclosure vulnerability.

Severity Rating: High

CVSS v3.1 (proposed): 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Impact

Unauthenticated internet users can read any world-readable file on the server via the affected domain, exposing system configuration, service versions, and other sensitive information that materially aids further attacks.

Violates tenant isolation in principle: if any tenant or system component stores world-readable artifacts (logs, backups, static assets), these can be served publicly by another tenant’s vhost.

Expands attack surface for privilege escalation and targeted exploitation.

Affected Functionality

Hosting control panel “Root directory” setting for websites (Apache vhost generation).

Apache evaluates the resulting DocumentRoot without confinement to the account home.

Technical Details / Root Cause

User-supplied paths are written verbatim into Apache config. Example (observed vhost):

<VirtualHost *>

ServerName otterlysecure.alwaysdata.net
DocumentRoot "/home/otterlysecure/../../../../../../"
<Location />
  AddHandler fcgid-script .php
  FcgidWrapper "/usr/bin/env /usr/bin/php-cgi" .php
</Location>

</VirtualHost>

Because ../../.. is not canonicalized or constrained, the vhost can be pointed to any filesystem path (including /).

Proof of Concept (PoC)

In the control panel, set Root directory to:

../../../../..// (via path traversal)

Request world-readable system files via my domain:
curl -i https://otterlysecure.alwaysdata.net/etc/hosts curl -i https://otterlysecure.alwaysdata.net/etc/passwd

Observed results:

HTTP/200 with contents of /etc/hosts and /etc/passwd.

Reset Root directory back to a safe path under my home after testing.

Notes on scope/ethics

I accessed only system files (/etc/hosts, /etc/passwd) sufficient to demonstrate impact.

I did not attempt to access other tenants’ data or private directories.

Why this matters even if some paths 403

Reading /etc/* proves arbitrary file read of world-readable files over the public web. Current 403s on some directories (e.g., /home) are incidental to Unix permissions/overrides and do not mitigate the core design flaw (unconfined DocumentRoot).

Timeline

2025-09-22: Discovered and verified impact (read /etc/hosts, /etc/passwd over HTTPS via my domain).

2025-09-22: Report submitted.

Please see attachments.

Credits / Contact

Reporter: Li Xian

Preferred contact: lixianchai-ywh-fd1a7856643e0e35@yeswehack.ninja