CVE-2024-5134 is a medium severity (CVSS 6.3) SQL injection in SourceCodester Electricity Consumption Monitoring Tool. The bill input handled by /endpoint/delete-bill.php reaches a database query unsafely. The record names no fixed version, so remove the application from exposure or patch the query yourself.
What's affected
The record lists SourceCodester Electricity Consumption Monitoring Tool (version 1.0) and says the flaw is in /endpoint/delete-bill.php, through the bill argument. The endpoint deletes a bill, so the injection sits inside a write statement. A flawed DELETE query matters more than a flawed SELECT, because the wrong condition can remove many rows.
The record gives no fixed version and no vendor patch, and the public write up was posted by an independent researcher. The identifier VDB-265210 is VulDB's tracking number. Sources of this kind describe projects distributed as learning or demo code, so a patch from the author may never arrive.
How to check if you're exposed
First find out whether you run this software at all. Search your web roots and repositories:
find /var/www -name 'delete-bill.php' 2>/dev/null
grep -rn "bill" /var/www --include=*.php | head
If the file is present, open it and look for the parameter being placed straight into a query string. Review web server logs for requests to this path that carry quote characters or SQL keywords in the parameter. A web application scan of a staging copy can confirm the behavior without touching production.
What to do now
- Remove public access to the /endpoint/ folder.
- Bind the bill value in the DELETE query and cast it to an integer.
- Keep regular backups so deleted billing data can be restored.
- Give the database user only the rights the tool requires.
- Log all delete operations with a user and time.
- Consider replacing the tool if it is business critical.
Why it matters
SQL injection (CWE-89) happens when user input is concatenated into a query string, so the database cannot tell data from instructions. The result depends on database privileges and on what the query does: reading rows the page never meant to show, changing them, or in some setups reaching further. Destructive statements that accept request values deserve the strictest handling. A single unquoted value in a DELETE clause can change its scope from one row to the whole table.
The published description says the exploit has been disclosed to the public and may be used, so assume that anyone who looks can find the technique. The record does not set the KEV flag, so there is no CISA report of active exploitation in it.
Quick check
Why does the DELETE statement raise the stakes?
A condition changed by an attacker can widen the delete to many rows.
What protects me from data loss?
Tested backups, plus fixing the query.
Sources
Last reviewed: 19 October 2026.
