CVE-2024-6440 is a medium severity (CVSS 6.3) SQL injection in SourceCodester Home Owners Collection Management System 1.0. The id argument of the delete category action reaches the database unsafely. No fixed version is listed, so the answer is to parameterize the query or retire the app.
What's affected
The record lists Home Owners Collection Management System 1.0. The vulnerable code is in /classes/Master.php, called with f=delete_category, and the argument at fault is id. The record rates the attack as remotely launchable.
It is the second CVE published the same day for this project. The first, CVE-2024-6439, is an upload problem in the same application. Anyone who finds one should assume the codebase has more.
The weakness is CWE-89, improper neutralization of special elements in an SQL command. The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. VulDB tracks it as VDB-270168. The record says a public exploit exists and the KEV flag is false.
I could not load the cited GitHub write-up or the VulDB page during review, so there is no vendor advisory or patch note to cite.
How to check if you're exposed
- Confirm whether the application is deployed and find the file:
grep -rn "delete_category" /var/www --include=*.php
- Read the code that handles the
idvalue. If it is joined into an SQL string, it is exposed. If it goes through a prepared statement, it is not. - Check web logs for requests to
Master.php?f=delete_categoryand look for unusually long or oddidvalues. - Check whether the admin area is open to the internet.
What to do now
- Take the app offline if it is a demo or a test install.
- Otherwise, restrict the whole admin path to a VPN or an address allow list.
- Change the query to use prepared statements with bound parameters. In PHP with mysqli, that means
prepare,bind_paramandexecute. - Treat the id as an integer and reject anything else before it reaches the database.
- Give the database account only the permissions the app needs, so an injection cannot drop tables or read other schemas.
- Back up the database before making changes, and review it for unexpected rows or accounts.
Why it matters
A delete action looks harmless because it takes only a number. That is the trap: any value the browser sends is user input, whether or not a form field is visible.
SQL injection has been well understood for decades and the fix is cheap, which is why scanners and code review still flag it first. A static check would catch this pattern in the source; a reachability analysis would tell you whether the route is exposed at all.
Quick check
Does the attacker need an account?
The vector lists low privileges required, so a logged in user is assumed. If registration or the admin panel is open, that bar may be very low.
What is the real fix?
Use prepared statements with bound parameters for every query that takes user input, then retest. Escaping alone is a weaker option.
Sources
- NVD record for CVE-2024-6440
- VulDB entry 270168 and the public write-up cited by the record (neither was retrievable when this post was prepared)
Last reviewed: 19 October 2026.
