|
Task Description
[Severity: High] WebDAV share-root containment bypass on webdav-*.alwaysdata.net
Full technical write-up with exact request paths and outputs is attached as
"01-webdav-cross-tenant.md" (the literal encoded-traversal strings trip the WAF
if pasted inline, hence the attachment).
SUMMARY
The per-account WebDAV service at webdav-<account>.alwaysdata.net runs WsgiDAV
4.3.3 (shown in its own error pages). That version is affected by CVE-2026-48099
("encoded dot segments can escape WsgiDAV filesystem share roots", fixed in
WsgiDAV 4.3.4). FilesystemProvider._loc_to_file_path() confines a request to the
account home with a string-prefix check (file_path.startswith(root_path)) instead
of a real path-boundary check, so a request path that resolves OUTSIDE the share
root is accepted as long as the resulting absolute path still starts with the
root path string.
WHAT I CONFIRMED (see attachment for the exact transcript)
Home dirs are /home/<account_name>. From my own account whose root is
/home/mehdik5100a:
- a request going one level up (to /home) is correctly rejected with
500 "Security exception: tried to access file outside root: /home";
- a request resolving to a sibling that merely shares the root string prefix,
e.g. /home/mehdik5100aZZZ, is NOT rejected: it returns 404 (target absent),
proving "/home/mehdik5100aZZZ".startswith("/home/mehdik5100a") passed the
containment check.
Reproduced identically on a second, independent backend server (account root
/home/mehdik5100). Version banner: WsgiDAV/4.3.3 behind gunicorn.
IMPACT
Because account names are chosen freely at signup, an attacker who registers a
free account whose name is a string-prefix of a target account, and who lands on
the same physical server as that target, can read / write / delete the target's
files over WebDAV (GET/PUT/DELETE outside root are confirmed in the CVE's own
proof). This is a cross-tenant break on the shared hosting platform, reachable
from a free account. CVSS 3.1 8.7 High (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H).
ETHICS / SCOPE
I demonstrated only the containment bypass (the 404-vs-500 oracle) on my own
three test accounts (mehdi2008kerimov+alwaysdata{1,2,3}@gmail.com). I did NOT
read, write, or delete any other customer's data, and did not create the volume
of accounts that forcing co-location would require.
REMEDIATION
Upgrade WsgiDAV to >= 4.3.5 (4.3.4 fixes CVE-2026-48099). Additionally confine
each WebDAV worker to its account at the OS level (per-account chroot / mount
namespace / bind mount of only /home/<account>) so a library path bug cannot
cross tenants. Consider hiding the WsgiDAV version and Python exception text.
- Mehdi Kerimov
|
