A freely available hacking technique can give a complete stranger on the internet full access to the database powering a school's entire digital operation — grades, student addresses, staff records, and all.
Who Is At Risk — and How Bad Could This Get?
The vulnerability sits inside ProjectsAndPrograms School Management System, a web-based platform used by schools to manage everything from student enrollment and bus routing to staff payroll. It is deployed across educational institutions internationally, with the affected build confirmed up to commit 6b6fae5426044f89c08d0dd101c7fa71f9042a59. Because the product operates on a rolling release model — meaning there are no numbered version tags, just a continuous stream of updates — administrators have no simple version number to check. If your school is running this software and hasn't pulled a recent update from the repository, you are likely exposed.
The real-world stakes here go beyond IT inconvenience. Schools store some of the most sensitive personal data imaginable: children's names and home addresses, parental contact information, health and dietary needs, disciplinary records, and financial data tied to fee payments. A successful attack could result in that information being silently copied, sold, or held for ransom — and because many schools lack dedicated security staff, a breach might not be detected for weeks or months.
What the Attacker Actually Does — In Plain English
Imagine a school's website has a page that tracks where each bus is located. To load the right bus's information, the page reads a value from the web address — something like buslocation.php?bus_id=12 — and uses it to ask the school's database a question: "Give me the details for bus number 12." That's normal, expected behavior. The problem is that the software takes whatever value arrives in that web address and passes it directly to the database without checking whether it's actually a legitimate bus number.
An attacker doesn't need to be a student, staff member, or anyone with a login. They just need a browser. By crafting a malicious web address and sending it to the school's server, they can append extra database commands after the bus number. Instead of just fetching bus details, the database now executes the attacker's instructions — instructions that could read out every student record, dump administrator passwords, or in some configurations, write files to the server itself. The attack is entirely remote, requires no special tools beyond a web browser or a free command-line utility, and leaves little obvious trace.
What makes this especially dangerous is the last piece of that puzzle: the exploit is already public. This isn't a theoretical research finding sitting in a lab. The method for pulling this off has been published and is available for anyone to find. That means the window between "discovered" and "actively abused" is measured in days, not months.
The Technical Anchor: Classic GET-Parameter SQL Injection, CVSS 7.3
For security researchers and professionals: this is a GET-parameter SQL injection vulnerability in the bus_id argument handled by buslocation.php. The flaw is unauthenticated and remotely exploitable, classified under CVE-2026-6595 with a CVSS score of 7.3 (HIGH). The attack vector is network-based, requires no privileges and no user interaction, and the confidentiality and integrity impact are both rated as HIGH. The vulnerability class — unsanitized user-supplied input concatenated into a raw SQL query — represents one of the oldest and most well-documented categories in web application security, yet continues to appear in production codebases with alarming regularity.
How Was This Found — and Has Anyone Been Hit Yet?
The vulnerability was responsibly disclosed to the vendor ahead of publication, following standard coordinated disclosure practice. As of the time of writing, no confirmed active exploitation has been reported — but given that a working exploit is publicly available, security teams should treat this as an active threat rather than a future concern. There are no known confirmed victim organizations or attributable threat campaigns tied to this CVE at this time.
The rolling-release nature of the software complicates the response. Because there is no "patch version 6.1" to point to, the vendor's fix — if applied — would simply appear as a newer commit in the project repository. That puts the burden squarely on administrators to pull updates and verify the fix is actually present.
What Schools Should Do Right Now
Three concrete steps, in order of urgency:
-
Update immediately from the official repository. Pull the latest commit from the ProjectsAndPrograms School Management System repository right now. Confirm that your deployment is running a commit newer than
6b6fae5426044f89c08d0dd101c7fa71f9042a59. If you cannot confirm this, treat your installation as compromised until verified otherwise. -
Restrict public access to sensitive PHP pages. If
buslocation.php— and other data-serving scripts — do not need to be accessible without a login, enforce authentication at the application or web-server level immediately. Use your web server's configuration (Apache.htaccessrules or nginxlocationblocks) to block unauthenticated access to these endpoints as an emergency measure while you prepare a full update. -
Review your database access logs for anomalies. Look for unusual query patterns, especially requests to
buslocation.phpcontaining characters like single quotes ('), double dashes (--), or SQL keywords such asUNION,SELECT, orDROPin thebus_idparameter. Many web application firewalls (WAFs) — including free options like ModSecurity with the OWASP Core Rule Set — can be deployed in front of your application to block these patterns while a proper fix is applied.
CVE: CVE-2026-6595 | CVSS: 7.3 HIGH | Category: SQL Injection | Exploitation: No confirmed active exploitation; public exploit available | Affected Component: buslocation.php — HTTP GET Parameter bus_id