CVE-2025-11105 is a high severity (7.3) SQL injection flaw in code-projects Simple Scheduling System 1.0. The subcode parameter handled by /schedulingsystem/addsubject.php reaches a database query unsafely. The record lists no fixed version, so restrict access, replace the code or the product, and check your logs.
What's affected
The record lists code-projects Simple Scheduling System version 1.0. The weak spot is the file /schedulingsystem/addsubject.php, where the subcode argument is used in a database query without safe handling. CVSS 7.3 (high severity), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. That vector reads as network reachable, low complexity, no privileges and no user interaction required, with limited impact on confidentiality, integrity and availability.
Fixed versions: none are named in the CVE record, and the sources below do not name one. Check the vendor site or project page for a newer release before you rely on this.
How to check if you're exposed
First find out whether you run it at all. Search your asset list, container images and web roots for code-projects Simple Scheduling System. On a Linux host you can look for the vulnerable file name directly.
find / -name "addsubject.php" -not -path "/proc/*" 2>/dev/null
Then read the code behind it. If the subcode value is joined into a query string rather than bound as a parameter, the flaw is present in your copy. Next, look in web server logs for unusual requests to that path.
grep "addsubject.php" /var/log/nginx/access.log | grep -iE "%27|union|select|sleep"
Adjust the log path for your server. Hits are not proof of abuse, but they tell you where to look in the database logs.
A dependency scan helps with the inventory part. The free in-browser scan at gold.safeguard.sh/scan lists the libraries in a manifest you paste in. It will not find a hobby PHP application that was never packaged, so keep a plain list of what you host too.
What to do now
- Take code-projects Simple Scheduling System off the public internet if you can. Put it behind a VPN or an IP allow list while you work.
- Check the vendor or project site for a newer release than 1.0. The record does not name one.
- If you own the code, bind the subcode value as a query parameter instead of joining it into SQL text. If the value picks a column or sort order, accept only a fixed list of names.
- Run the database account for this app with the fewest rights it needs. It should not own the schema or read unrelated tables.
- Review web and database logs for the affected path, and rotate any credentials stored in that database if you see signs of abuse.
- If the product is a demo or tutorial project, replace it with a maintained alternative before it holds real data.
Why it matters
The record classes this as CWE-74 (injection), CWE-89 (SQL injection). In plain terms, text from a request is treated as part of a database command. The database cannot tell the difference between what the developer wrote and what the visitor supplied, so the visitor can change what the query does.
Small PHP and Java apps from tutorial sites and niche vendors repeat this mistake because queries are written by hand with string joining. The record says the exploit has been disclosed publicly. It is not on the CISA Known Exploited Vulnerabilities list as of the record, and nothing here says it is being used in attacks. Public details still shorten the time between disclosure and scanning.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a patched version of code-projects Simple Scheduling System?
The CVE record names none. Check the vendor or project page, and limit exposure until you have written confirmation.
Does a web application firewall solve this?
It can block common patterns as a stopgap, but the fix is to bind parameters in the code. Treat a firewall as time bought, not a repair.
Sources
Last reviewed: 19 October 2026.
