CVE-2025-1580 is a medium severity SQL injection flaw in PHPGurukul Nipah Virus Testing Management System 1.0. Input handled by the searchdata parameter in /search-report-result.php reaches a database query without safe handling, and the attack runs over the network. NVD scores it 6.3. The record names no patch, so treat the app as unfixed and remove it from public reach.
What's affected
The record lists Nipah Virus Testing Management System 1.0 from PHPGurukul as affected. Scope is one script: /search-report-result.php, through the searchdata argument. No fixed version is named in the record, and none of the references we could read announces a vendor patch. If this is a downloaded source code project, each deployment is a standalone copy that nobody updates for you. The record adds that the initial researcher advisory mentions contradicting parameter names, so do not assume the one named in the record is the only input at risk.
How to check if you're exposed
Start by finding out whether you run this code at all. Search the web roots on your servers for the file name, then look at how the script builds its query.
find /var/www /srv /opt -type f -name "search-report-result.php" 2>/dev/null
grep -n "searchdata" $(find /var/www -type f -path "*/search-report-result.php" 2>/dev/null)
If the query is assembled by joining strings with request values, the script is in the affected class. Then check your access logs for requests to /search-report-result.php so you know how often it is reached and from where.
grep "/search-report-result.php" /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null | tail -n 50
The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) shows the attack needs a low privilege account and no user interaction. A public exploit is reported in the record, so any internet facing copy deserves quick attention.
What to do now
- Find every copy of Nipah Virus Testing Management System in your estate, including test and demo servers that were never meant to stay online.
- Take internet facing copies offline or restrict them to a VPN or an IP allow list until the code is fixed.
- Rewrite the query in
/search-report-result.phpto use prepared statements with bound parameters, and validate input types at the edge. - Give the application's database account only the permissions it needs, with no file or administrative rights.
- Review database contents and logs for unexpected reads or changes, and rotate any credentials stored in the affected database.
- Watch the vendor site and the CVE entry for a patch, and plan to replace the app if none arrives.
Why it matters
The weakness is CWE-89, SQL injection, filed under the broader class CWE-74, injection. The application takes a value from the request and places it inside a SQL statement as text. The database cannot tell where the developer's query ends and the visitor's input begins, so input can change what the query does.
Here the exposed data is likely patient and test report records. The CVSS impact is low across confidentiality, integrity and availability, which is why the score sits at 6.3, but a database often holds more than the one page suggests. The record also says the exploit is public, which shortens the time between a scan and a problem. This is not on the CISA KEV list.
Going further
Compensating controls matter more than usual here because a vendor fix may never ship. Put the app behind authentication at the web server, limit it to known networks and turn on query logging so an unusual request stands out. None of this fixes the flaw, but it narrows who can reach it.
If the app holds anything personal, such as patient and test report records, involve whoever owns privacy for the system. Decide whether a review of past access is needed, and record what you found either way.
A short example shows the shape of the repair. The safe form sends the statement and the value to the database separately, so the value can never become part of the statement.
$stmt = $pdo->prepare('SELECT * FROM items WHERE name = :name');
$stmt->execute([':name' => $value]);
$rows = $stmt->fetchAll();
Apply the same change to every script that touches the database, not only the one in the CVE. Code written in one style tends to repeat the same pattern in many files, and researchers who find one SQL injection in a small app often find more. Treat this CVE as a prompt to read the whole codebase.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a patched version of Nipah Virus Testing Management System?
The record does not name one. Check the vendor site and the CVE entry before relying on any release, and fix the query yourself if you must keep running the app.
What is the durable fix for this class of bug?
Use parameterized queries everywhere and keep user input out of query text. A web application firewall rule can reduce noise, but it does not repair the code.
Sources
Last reviewed: 19 October 2026.
