CVE-2025-4073 is a high SQL injection flaw in PHPGurukul Student Record System, with a CVSS score of 7.3. The record names no fixed version, so check with the maintainer. Treat any instance reachable from untrusted networks as exposed until you have confirmed the fix, and review your logs for unexpected requests.
What's affected
- Product: PHPGurukul Student Record System 3.20, a PHP app for keeping student records.
- Fixed version: The record names no fixed version.
- Severity: High, CVSS 7.3 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L).
- Weakness: CWE-74 and CWE-89.
- Published: 2025-04-29.
The record points at /change-password.php, where the manipulation of the currentpassword argument leads to SQL injection. It says the attack can be started remotely and that the exploit has been disclosed to the public.
The record is a VulDB entry scored 7.3, a High rating. Its weakness types are CWE-74 (injection in general) and CWE-89 (SQL injection in particular).
How to check if you're exposed
This is source code you host yourself, so you can search for the file and parameter named in the record:
grep -rn '\$_GET\|\$_POST\|\$_REQUEST' --include=*.php . | grep -i 'query'
The command lists lines where request input and a database query appear together. Read each hit and look for values placed straight into the SQL text. It is a starting point for review, not proof of safety.
You can also run your dependency manifests and container images through the free in-browser scan to see which known CVEs affect the packages you ship. It will not find a flaw inside a vendor appliance or an unmanaged install, so keep an inventory of those too.
What to do now
- Identify every copy of PHPGurukul Student Record System you run, including test and forgotten ones.
- Look for a newer release from PHPGurukul. If none exists, patch the query yourself or take the application off the public internet.
- Until that is done, remove public access where you can. Put the application behind a VPN, a network allow list or a web application firewall rule, and watch the access and database logs for unusual requests to the endpoint named above.
- If you can edit the code, change the vulnerable query or check to a safe form and review nearby files for the same pattern.
- Record the outcome, including the date, the version you ended on and who confirmed it, so a later audit has something to read.
- Add the product to your continuous monitoring so a future CVE against it reaches you without a manual search.
Why it matters
SQL injection happens when an application builds a database query by gluing user input into the query text. The database cannot tell where the developer's command ends and the visitor's data begins, so a crafted value can change what the query does. The class is catalogued as CWE-74 (injection) and CWE-89 (SQL injection).
The usual fix is a parameterized query, where the SQL text and the values travel separately. Input validation helps as a second layer, but it is not a substitute. Because this flaw needs no login and no click from a victim, anything that can reach the page over the network is in range.
The record's KEV flag is false, so CISA does not list it as known to be exploited, and nothing in the sources here says it is being exploited in the wild.
Quick check
What does the score of 7.3 mean for PHPGurukul Student Record System?
The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L reads as network reachable, low complexity, no privileges and no user interaction. The impact ratings are confidentiality low, integrity low, availability low. Use it to rank the work, then confirm exposure for your own deployment.
Is escaping the parameter enough to fix this?
Escaping is fragile and easy to get wrong in one place out of many. Parameterized queries are the reliable fix because the value is never treated as SQL. If you maintain the code, change the query itself rather than patching the symptom.
Sources
Last reviewed: 18 October 2026.
