CVE-2024-54141 is a high-severity (CVSS 8.6) CWE-209 vulnerability in thorsten/phpmyfaq. A fix is available for thorsten/phpmyfaq — see the affected versions and patch details below.
phpMyFAQ Generates an Error Message Containing Sensitive Information if database server is not available
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-54141.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
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
Exposure of database (ie postgreSQL) server's credential when connection to DB fails.
Details
Exposed database credentials upon misconfig/DoS @ permalink: https://github.com/thorsten/phpMyFAQ/blob/main/phpmyfaq/src/phpMyFAQ/Setup/Installer.php#L694
PoC
When postgreSQL server is unreachable, an error would be thrown exposing the credentials of the database. For instance, when "http://<phpmyfaq-instance>:8080/setup/index.php" is hit when the database instance/server is down, then credentials are exposed, for instance:
( ! ) Warning: pg_connect(): Unable to connect to PostgreSQL server: connection to server at "127.0.0.1", port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78
Call Stack
# Time Memory Function Location
1 0.0404 453880 {main}( ) .../index.php:0
2 1.1341 610016 phpMyFAQ\Setup\Installer->startInstall( $setup = ??? ) .../index.php:471
3 1.2113 611544 phpMyFAQ\Database\Pgsql->connect( $host = '127.0.0.1', $user = 'cvecve', $password = '<redacted>', $database = 'cvecve', $port = 5432 ) .../Installer.php:694
4 1.2113 611864 pg_connect( $connection_string = 'host=127.0.0.1 port=5432 dbname=cvecve user=cvecve password=<redacted>' ) .../Pgsql.php:78
( ! ) Fatal error: Uncaught TypeError: Cannot assign false to property phpMyFAQ\Database\Pgsql::$conn of type ?PgSql\Connection in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78
( ! ) TypeError: Cannot assign false to property phpMyFAQ\Database\Pgsql::$conn of type ?PgSql\Connection in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78
Call Stack
# Time Memory Function Location
1 0.0404 453880 {main}( ) .../index.php:0
2 1.1341 610016 phpMyFAQ\Setup\Installer->startInstall( $setup = ??? ) .../index.php:471
3 1.2113 611544 phpMyFAQ\Database\Pgsql->connect( $host = '127.0.0.1', $user = 'cvecve', $password = '<redacted>', $database = 'cvecve', $port = 5432 ) .../Installer.php:694
A way to force this would be to perform a denial of service on the database instance/server. When the db connection is refused, the credentials would show. The remote attacker can then use that to gain full control on the database.
Impact
This vulnerability exposes the credentials of the database and grants a remote attacker full control over the database.
First notified Snyk on 16 Jan 2024.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | thorsten/phpmyfaq | all versions | 4.0.0composer require thorsten/phpmyfaq:^4.0.0 |
Affected Products
phpmyfaqphpmyfaqDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update thorsten/phpmyfaq to 4.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-54141 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is CVE-2024-54141 in your dependencies?
Find it across Packagist, including transitive dependencies.