CVE-2025-5979: High SQL Injection in School Fees Payment System

CVE-2025-5979 is a high severity (CVSS 7.3) SQL injection in code-projects School Fees Payment System 1.0. The ID argument of /branch.php is affected. The record lists no fixed version, so restrict access to the application or retire it. The sections below cover who is affected, how to check, and what to do now.

What's affected

code-projects School Fees Payment System version 1.0 is named in the record. The record does not list a fixed version, and I could not find a vendor patch or release note to point to. Treat every installation of this application as affected until the project says otherwise.

The affected file is /branch.php and the affected argument is ID. This is a separate flaw from CVE-2025-5977, which is in a different file of the same product.

How to check if you're exposed

Check whether the application is installed anywhere you run or host it. These small PHP projects are often downloaded as source and deployed by hand, so they may not appear in any package manager.

grep -ril "school fees" /var/www 2>/dev/null | head

Then review your web server access logs for requests to the affected path, /branch.php, from addresses you do not recognise. The record states that the exploit has been disclosed to the public, so assume the path is known to scanners.

What to do now

1. Decide whether you need this application at all. It is a sample style project, and the simplest fix for an unmaintained app is to retire it.
2. If it must stay, remove it from the public internet. Put it behind a VPN, an allow list or at minimum HTTP authentication at the web server.
3. Check the vendor site and the linked issue for a patched release, and apply it if one exists. Do not assume one does.
4. Fix the code path yourself if you maintain a fork, following the defence described below.
5. Review logs and the database for activity you cannot explain, and rotate any credentials stored by the application.

Why it matters

The record maps this to CWE-89 (SQL injection) and CWE-74 (injection). An identifier passed in the ID argument ends up inside a database query. Numeric identifiers are a classic case: casting to an integer or binding the value as a parameter closes the hole.

Two separate SQL injection CVEs in one small application is a pattern worth noting. It suggests the whole code base builds queries the same way, so fixing one file would not make the application safe. The record says exploit details are public. It is not on the CISA KEV list.

SQL injection happens when input reaches a database query as part of its structure instead of as plain data. The reliable defence is the same everywhere: parameterised queries or prepared statements, and no string building for anything a user can influence. Input validation helps, but it is a second line, not the first.

If you find injectable code in your own applications, treat the fix as two jobs. Change the query so the value is bound as a parameter, and check the database account the application uses. An account that can only read the tables it needs turns a bad bug into a smaller one.

Safeguard can help you find this one in your own software. The free in-browser dependency scan at gold.safeguard.sh/scan reads your manifest or lockfile and shows which known vulnerabilities your declared dependencies carry, including transitive ones. Reachability analysis then helps you separate the places where your code actually calls the affected component from the places where it only sits in the tree, which makes it easier to decide what to patch first.

Quick check

Sources

• NVD record data for CVE-2025-5979
• Public issue report
• VulDB entry

Last reviewed: 18 October 2026.