CVE-2025-11660 is a high severity unrestricted file upload flaw (CVSS 7.3) in the ProjectsAndPrograms School Management System. The File argument of /assets/uploadSllyabus.php is not checked, so a remote user can upload files the app should refuse. The product has no versions, so check the project.
What's affected
The record lists the ProjectsAndPrograms School Management System, in every build up to commit 6b6fae5426044f89c08d0dd101c7fa71f9042a59. The affected file is /assets/uploadSllyabus.php and the argument is File. The record classifies it under CWE-284 (Improper Access Control) and CWE-434 (Unrestricted Upload of File with Dangerous Type). The file name suggests it uploads a syllabus, but the record does not describe the feature, so read the code to see what it does with the uploaded file.
This product does not use versioning. The record says it follows a rolling release model, so there is no version number to compare. You need to know which commit you deployed.
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. The attack runs over the network, needs low complexity, and needs no account or user interaction. The record adds that the exploit has been published and may be used. Several sibling CVEs from the same disclosure cover other upload handlers in the same project, so fixing one file is not enough.
How to check if you're exposed
Because there is no version number, check the commit and the code. If you deployed from a git clone, run:
git log -1 --format=%H
git merge-base --is-ancestor 6b6fae5426044f89c08d0dd101c7fa71f9042a59 HEAD && echo "at or after the listed commit"
The record says builds up to that commit are affected, and it names no fixed commit, so a build after it is not proof of a fix. Read the code in the file named above and see whether it checks the file type, the extension, and the destination folder. Then look at the upload folder itself for files that should not be there, such as script files in a folder meant for documents.
Check web server logs for POST requests to the affected file from unknown addresses.
What to do now
-
Take the application off the public internet, or require a VPN, until the upload code is fixed.
-
Configure the web server so that the upload folder serves files as static content only and never executes scripts there.
-
Add server side checks to every upload handler. Allow a short list of extensions, verify the content type by inspection, rename files on save, and store them outside the web root where you can.
-
Require a signed in user for every handler that accepts a file.
-
Review the upload folder, remove anything unexpected, and treat any script file found there as a sign of compromise.
-
Check the project page for a newer commit that addresses these CVEs, and re-test after you pull it.
Why it matters
Unrestricted upload, tracked as CWE-284 (Improper Access Control) and CWE-434 (Unrestricted Upload of File with Dangerous Type), lets a user place a file of the attacker's choosing on the server. The record pairs it with an access control weakness. If the server will run an uploaded script, the upload becomes a way to run code, which is why the handler and the folder settings must both be fixed.
The pattern repeats across five files in this project. That points to a shared design gap, with each handler written without a common upload check, not to one slip. Fixing it once in a shared helper and calling that helper everywhere is the sturdy answer.
The record does not mark the CVE as exploited in the CISA Known Exploited Vulnerabilities catalog, but it does say the exploit is public.
To see whether a vulnerable package is hiding in your own projects, run the free in-browser dependency scan at gold.safeguard.sh/scan. The Gold directory lists the same advisories alongside affected versions, and reachability analysis helps you rank which findings are actually called by your code.
Quick check
Why does this product have no fixed version?
It uses rolling releases without version numbers. The record lists builds up to a commit, so the only reliable check is the commit you deployed and the code in the file.
Are the five upload CVEs the same bug?
They share a class and a project but each names a different file. Fix each handler, or better, a shared helper that all of them call.
Sources
Last reviewed: 19 October 2026.
