Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by zlynv - 25.09.2026
Last edited by cbay - 25.09.2026

Summary field: API accepts unvalidated WebDAV/FTP user path ("../") - file access root escapes the account directory (cross-customer read/write risk)

—

Details field:

Affected endpoint (in scope) https://api.alwaysdata.com/v1/webdav/ and https://api.alwaysdata.com/v1/ftp/ (create operation, path field), and the resulting WebDAV service on https://webdav-[account].alwaysdata.net/

Summary

The API create operation on the webdav and ftp resources accepts an arbitrary path value without validation. Creating a user with "path":"../" is accepted (201 Created) and stored verbatim. The WebDAV service then resolves that user's root above the account directory (to /home), so the "user" can read and write paths outside their own account - in the worst case, every other customer's files under /home.

This directly breaks the documented guarantee of the field (from /v1/webdav/doc/):

\"Chemin relatif a la racine de votre compte. Les repertoires parents du repertoire racine ne seront ni accessibles ni visibles.\" (\"Path relative to your account root. Parent directories of the root directory will neither be accessible nor visible.\").

Steps to reproduce

1. Create a test account with a WebDAV user restricted to www/ (control).

2. Create a second WebDAV user with a traversal path:

POST https://api.alwaysdata.com/v1/webdav/
Authorization: Basic <token-id>:
Content-Type: application/json

{"name":"<account>_prov","password":"<any>","path":"../"}

→ 201 Created. GET confirms stored value:

"path": "../"

(no validation error).
Identical POST to

/v1/ftp/

also returns 201 with

"path": "../"

.

3. Authenticate to the WebDAV service as that user and prove the root escaped the account.
(Only URLs inside my own account namespace were requested - see rules note below.)

GET /docs/                    -> 200   (account directory is INSIDE this user's root)
GET /docs/www/index.html      -> 200   (own file, reachable only if root = /home)

Control - existing user with path "www/":
GET /docs/                    -> 404
GET /docs/www/index.html      -> 404   (properly jailed)

The control returning 404 while the "../" user returns 200 for the same URLs proves the root is physically different: it resolved to /home (the parent of /home/<account>/), not to /home/<account>/.

4. Cleanup (immediately after verification):

DELETE /v1/webdav/<id>/  -> 204
DELETE /v1/ftp/<id>/     -> 204
GET /v1/webdav/, /v1/ftp/ -> only original users remain

Impact

Any customer - or an attacker who registers an account - can create a WebDAV (or FTP) user whose root is /home, i.e. full read/write across tenant boundaries on the file-sharing layer. Unlike the encoded-traversal issue in my earlier WebDAV task (which broke the jail of a correctly configured user at request time), this one lets the attacker configure an escaped root directly through the API, with no special encoding and no pre-existing restricted user.

Worst case per your methodology: cross-customer file read and write via WebDAV (PUT/DELETE were exercised only inside my own account while proving the write path of the related issue), plus disclosure of anything stored under /home.

Suggested classification: High (customer data), potentially Critical under worst-case analysis - your call.

I did not request any other account's paths (program rules). All probes were limited to /docs/… URLs inside my own test account, which is sufficient to prove the root elevation.

Root cause

The path field of the webdav and ftp resources is not validated on create (and presumably update): no rejection of "..", no canonicalization check that the resolved root stays within the account directory before the value is handed to the file-sharing services.

Relation to my previous reports

- WebDAV ..%2f jail bypass (earlier task): request-time encoding bypass of a correctly configured user. Different layer, different fix.
- Site path "../" (earlier task): same missing-validation pattern on the site resource affecting Apache DocumentRoot. This report covers the webdav and ftp resources affecting the file-sharing services. If you prefer to handle these as one fix family, feel free to merge.

Account used for testing

- Same test customer account as my previous tasks (details available on request).
- Both test users deleted (204) and listings verified back to original state; no lingering credentials.
- No foreign customer data was accessed at any point.