CVE-2026-97883 is a high severity (CVSS 7.3) SQL injection in the CloudClassroom-PHP-Project, in updatequery.php through the gid parameter. The project uses rolling releases, so the record gives no fixed version, and the vendor did not respond. Treat any deployment as exposed until you change or remove the code.
What's affected
The record covers mathurvishal CloudClassroom-PHP-Project up to commit 5dadec098bfbbf3300d60c3494db3fb95b66e7be. The affected file is updatequery.php and the manipulated argument is gid. The project delivers continuously with rolling releases, so the record says no version details exist for either affected or updated releases.
The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, a score of 7.3. The record says the attack can start remotely, the exploit has been disclosed publicly and may be used, and the vendor was contacted early but never responded. KEV is false.
We could not read the public write-up linked in the record, because the address returned a not found error when we tried, so we cannot add detail beyond the record. If you want details, check the references in the NVD entry directly.
How to check if you're exposed
Work out whether you run this project at all. It is a small open source PHP application, often used for coursework or demos, so check any server where someone may have deployed it. Look for a directory containing updatequery.php.
If you deployed it from the GitHub repository, compare your commit with 5dadec098bfbbf3300d60c3494db3fb95b66e7be using git log in the install directory. Because there is no versioned fix, any commit up to that point is in scope, and the record does not identify a later safe commit.
Also check the web server logs for requests to updatequery.php with unusual gid values. Abnormal parameter content or database errors in the logs are signs that someone has been testing the page.
What to do now
- Take any internet facing copy offline, or put it behind authentication or a VPN, until the code is fixed.
- Back up the database, then rotate any passwords and API credentials stored in or used by the application.
- In your own copy of updatequery.php, change the database call to a prepared statement with bound parameters and validate that gid is an integer.
- Review the other PHP files for the same pattern of building queries from request parameters.
- Decide whether this project should be running in production at all. If it is a demo, retire it.
Why it matters
The weakness types are CWE-74, CWE-89. SQL injection occurs when a request value is placed directly into a database query, so the database cannot tell data from instructions. The standard fix has been the same for many years: parameterised queries plus input validation. It is not complicated, but unmaintained projects often never get it.
Rolling release projects with an unresponsive maintainer are a difficult case for dependency tracking. There is no version number to compare, and no one to ask. Your best defence is knowing where such code runs and limiting what the database account behind it can do.
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan. It covers packages and libraries your projects pull in, so it will not see a standalone application or a kernel, but it is a quick way to find out which third party components you are carrying at all. Reachability analysis then helps you separate vulnerable code that your application actually calls from code that only sits in a dependency tree.
Quick check
Which versions are affected?
The record gives no versions. It says rolling releases are used, so affected means everything up to commit 5dadec098bfbbf3300d60c3494db3fb95b66e7be, and no fixed commit is named.
Can I fix it myself?
Yes, in your own copy. Use a prepared statement and validate the parameter type. Test it carefully and keep the change documented, since upstream may never ship a patch.
Sources
Gold entry for CVE-2026-97883 Public advisory, listed in the record, returned not found when we tried to read it VulDB entry
Last reviewed: 18 October 2026.
