GHSA-q4rm-m6xh-5pv7 Froxlor customer can create MySQL databases on disallowed servers via Mysqls.add API
SummaryThe `Mysqls.add` API command (`lib/Froxlor/Api/Commands/Mysqls.php`) accepts a customer-controlled `mysql_server` parameter and only validates that the value is numeric and that the server index exists in `userdata.inc.php`. It never checks the value against the calling customer's `allowed_mysqlserver` allowlist. A customer can therefore create a database, plus a MySQL user with a password they choose, on any MySQL server the operator has configured — including servers that were explicitly excluded from that customer (e.g. a separate cluster, premium-tier host, or another tenant pool). The same `allowed_mysqlserver` check is correctly enforced in `MysqlServer::get()` / `MysqlServer::listing()` and in the customer-facing UI (`customer_mysql.php`), confirming the omission is a bug, not by-design.Details**Vulnerable code path** — `lib/Froxlor/Api/Commands/Mysqls.php:69-99` (`add()`):The `$customer['allowed_mysqlserver']` field IS read on line 80 but is only consumed by `getDefaultMySqlServer()` (lines 566-573) to compute a default when the request omits `mysql_server`. As soon as the client supplies the parameter, the default path is skipped and no further authorization gate runs.**Cross-file evidence the check is intended elsewhere:**`lib/Froxlor/Api/Commands/MysqlServer.php:319-323` — `get()` rejects with HTTP 405 when `$dbserver` is not in `allowed_mysqlserver`:`lib/Froxlor/Api/Commands/MysqlServer.php:252-257` — same allowlist filter on `listing()`.`customer_mysql.php:222` — UI rejects with `Response::dynamicError('No permission')` when `empty($allowed_mysqlservers)`.**Chain of execution (attacker → impact):**Customer authenticates to `api.php` with apikey/secret. The only API gate is `cust_api_allowed`; `allowed_mysqlserver` is not consulted at auth time.Customer sends JSON `{"command":"Mysqls.add","params":{"mysql_password":"<valid>","mysql_server":<disallowed_idx>}}`.`Mysqls.php:71` quota check passes (`mysqls_used < mysqls`).`Mysqls.php:80` `getCustomerData('mysqls')` returns the caller's own row.`Mysqls.php:81` `$dbserver` is set from the request (default-fallback path skipped).`Mysqls.php:92` numeric regex passes.`Mysqls.php:93-99` `Database::needRoot(true, $dbserver, false)` switches to the root context of the attacker-chosen server; existence check passes.`Mysqls.php:116/118` `DbManager::createDatabase(...)` runs against the disallowed server using stored root credentials, creating the DB and granting the supplied password to `<loginname>_<sqlN>` (DbManager.php:177-218).`Mysqls.php:127-141` inserts a row into `TABLE_PANEL_DATABASES` with the attacker's `customerid` and the disallowed `dbserver`, allowing later management via `Mysqls.get/update/delete` (which only filter by `customerid` for non-admins, e.g. `Mysqls.php:282`).PoCPreconditions on the target instance:≥2 MySQL servers configured in `lib/userdata.inc.php` (e.g. index 0 default, index 1 internal/premium).Customer X with `allowed_mysqlserver=[0]`, `cust_api_allowed=1`, `mysqls > 0`, and an issued API key (`apikey:secret`).Request — customer creates a database on server `1`, which is *not* in their allowlist:Expected (mirroring `MysqlServer.get()` behaviour): `HTTP 405 — "You cannot access this resource"`.
Actual: `HTTP 200` with the full database record, e.g.:Verify the credentials work on the forbidden server:The customer can subsequently manage the DB via `Mysqls.get`, `Mysqls.update`, and `Mysqls.delete` — those non-admin code paths filter only by `customerid` (`Mysqls.php:282-289`, `Mysqls.php:380-391`), which matches.ImpactBypass of the per-customer MySQL-server allowlist (`allowed_mysqlserver`) enforced by the admin/reseller. The authorization model is fully defeated for the `add` operation.The customer obtains valid MySQL credentials on a server the operator explicitly excluded for them — possibly an internal/separate cluster, billing tier, premium-only host, or a server provisioned for a different tenant pool.The customer can persist a DB on the forbidden server (resource and policy bypass), then read/write data there, and continue to manage it through `Mysqls.update` / `Mysqls.delete`.Impact is bounded: privileges granted by `DbManager::grantPrivilegesTo` apply only to the new `<loginname>_sqlN` database, so no cross-tenant data exposure on the forbidden server. The damage is policy bypass, resource consumption on the forbidden server, and credential persistence there.Recommended FixMirror the allowlist check already present in `MysqlServer::get()`. After the numeric validation on `Mysqls.php:92`, before `Database::needRoot(...)`, add for non-admin callers:Audit `Mysqls::update()`, `Mysqls::delete()`, and `Mysqls::get()` for the same gap: those endpoints accept `mysql_server` and ultimately call `Database::needRoot(true, $result['dbserver'], false)` on the row's stored value. Once the row exists with a forbidden `dbserver`, those paths execute against the forbidden server unchallenged. Consider rejecting any non-admin operation whose target row's `dbserver` is outside `allowed_mysqlserver`, even if the row already exists, to defend in depth.
CVSS v3.1 score: 4.3