CVE-2025-3045 is a medium severity (CVSS 6.3) SQL injection in the oretnom23 SourceCodester Apartment Visitor Management System 1.0. The ID argument in /remove-apartment.php is not handled safely. I could not confirm a fixed version, so mitigate and check for updates.
What's affected
The record lists the oretnom23 (SourceCodester) Apartment Visitor Management System 1.0 as affected. The file is /remove-apartment.php and the argument is ID.
No fixed version is named in the record. The references are a VulDB entry and a researcher's write up on GitHub, and neither is a vendor advisory. Treat the application as unpatched.
The record says the exploit was disclosed publicly and the attack can be launched remotely. It does not say the flaw is exploited in the wild, and it is not in the CISA KEV catalog.
How to check if you're exposed
This is a PHP application that you install and host yourself.
- Confirm whether it is deployed and whether it is version 1.0.
- Look in web logs for requests to /remove-apartment.php with unusual values in the ID parameter, such as quotes or SQL keywords.
- Check database logs for errors and for rows that were removed unexpectedly.
If the application records visitor names and contact details, consider that data exposed if you see signs of probing.
What to do now
- Find every deployment and take public facing ones offline unless they are needed.
- Change the code to use parameterized queries for the ID parameter, or add strict integer validation, if you maintain your own copy.
- Require login for the page and restrict it to trusted networks.
- Give the database account the fewest permissions it needs, so that a successful injection reaches less.
- Back up the database and test that you can restore it.
Why it matters
The record maps the flaw to CWE-89 (SQL Injection) and CWE-74 (Injection). The ID value is placed into a database query without being kept apart from the query text, so crafted input can change what the query does. The affected page removes an apartment, so a successful attack could also change or delete records.
Identifier parameters are usually numbers, and the simplest fix is to treat them as numbers. Converting the value to an integer, or binding it as a parameter, ends this class of problem for this page.
Small sample applications often lack any patch process. If you run one with real visitor data, you own the code, so review it for the same pattern in other pages.
Quick check
How can I fix this in my own copy?
Use parameterized queries or bind the ID as an integer. Then review other pages for the same pattern.
Is the vendor shipping a fix?
I could not confirm one. Check the project's own page.
Sources
Last reviewed: 19 October 2026.
