CVE-2024-1831 is a high severity (CVSS 7.3) SQL injection flaw in Complete File Management System version 1.0 from SourceCodester. It affects the user login. The record names no fixed version, so check the project page, patch the code yourself, or retire the application.
What's affected
Complete File Management System version 1.0, from SourceCodester. The record lists version 1.0 only, and does not name any newer or patched release.
The description places the flaw in users/index.php, part of the login form, where the username argument leads to SQL injection. A write-up linked from the record is titled as a login bypass via SQL injection. The weakness is CWE-89, SQL injection. The description says the attack can be launched remotely and that the exploit has been disclosed publicly and may be used.
Severity conflict. The description text, which follows the VulDB style, calls this issue critical. NVD's own CVSS 3.1 score is 7.3, which is High, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. Both ratings are published. The vector in the record needs no privileges, so no account is required.
How to check if you're exposed
These are small PHP applications with no package manager entry, so the check is about your own deployment. Find the install and confirm the product and version:
find / -type f -name "index.php" 2>/dev/null
grep -rn "mysqli_query\|mysql_query" /var/www/html | head -50
The second command lists places where queries are run directly. Look at each one that uses a request value such as a POST or GET field. A query assembled by joining strings with request data is the weakness class this CVE describes.
Check your web server access logs for repeated requests to index.php from addresses you do not recognise, and for login attempts that succeed with odd looking input. That tells you whether anyone has already probed the endpoint.
What to do now
- Decide whether you actually run this application. If it is a demo, a learning project or an unused install, take it offline and delete it.
- Check the record references and the project page for a fixed release. None is named in the record, so assume there is no patch.
- If you must keep it, change the vulnerable query to use prepared statements with bound parameters, and validate input on the server.
- Put the application behind authentication or a VPN, and do not expose it directly to the internet.
- Run it with a database account that has only the rights it needs, and rotate any credentials stored in its tables.
Why it matters
SQL injection is one of the oldest and best understood web flaws. The fix is also well understood: use prepared statements with bound parameters, so the database never confuses a value with part of the query. When code builds the query by joining strings, a crafted value can change what the query does.
A login form that is injectable can let an attacker sign in without a valid password, or read the user table, which often holds credentials. A file management system holds uploaded documents, so access to its accounts means access to the files. Public exploit write-ups make small applications like this easy targets, because attackers scan for known file names.
The record's Known Exploited Vulnerabilities flag is false, and I found no source saying this CVE is exploited in the wild. The description does say the exploit has been disclosed publicly.
Quick check
Which login page is affected?
The user login at users/index.php. The admin login is CVE-2024-1832.
Is this a login bypass?
A linked write-up is titled that way. The description itself says the username argument leads to SQL injection.
Sources
- NVD record for CVE-2024-1831
- VulDB entry 254622 (listed in the record, not retrievable when reviewed)
- Write-up listed in the record (not retrievable when reviewed)
Last reviewed: 19 October 2026.
