CVE-2025-8986 is a high severity (CVSS 7.3) SQL injection in SourceCodester COVID 19 Testing Management System 1.0. The record says manipulating the serachdata parameter of /search-report-result.php leads to SQL injection, and the attack can be launched remotely. The record names no fixed version, so treat the application as unpatched and reduce its exposure.
Nothing exotic is going on here. The application takes a request value and uses it inside a query, and the query was not written to treat that value strictly as data. The weakness classes are CWE-74 and CWE-89.
What's affected
SourceCodester COVID 19 Testing Management System 1.0, according to the record. The affected component is /search-report-result.php, and the parameter named is serachdata. The record lists no other versions and no fixed version.
The record scores this 7.3 (HIGH) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. In plain terms: reachable over the network, low attack complexity, no privileges, no user interaction, and low impact on confidentiality, low on integrity and low on availability. The vector says no account is needed. Anyone who can reach the page can try it.
The record links a public report (https://github.com/zhuyi-hz/cve/issues/5). On 18 October 2026 I could confirm the issue page exists and that its title matches the product and file in the record, but its body would not load for me, so the details here come from the NVD style record and not from that write-up.
The record does not say whether other versions share the flaw. If you run a different release of the same application, check the file named above instead of assuming it is clean.
One data quality note. The description names SourceCodester as the vendor, while the product field in the record carries an unyasoft covid19_testing_management_system entry. Scanners that match on the product field may label this differently from the description, so match on the file path and version instead.
How to check if you're exposed
There is no package manager entry to query for an application like this, so start with an inventory. Find out whether a copy is deployed anywhere you run web servers, including test and staging hosts that were never retired.
find /var/www -type f -name 'search-report-result.php' 2>/dev/null
If that finds the file, open it and look at how serachdata is used. A query built by joining strings with request values is the pattern the record describes. Your web server logs can show whether the page is being probed:
grep -F "search-report-result.php" /var/log/apache2/access.log | grep -Ei "%27|%22|union|sleep"
Odd quote characters and SQL keywords in requests to that page deserve a closer look. Absence of hits proves little, since logs rotate and attackers can encode input in other ways. You can also run the free in-browser dependency scan at gold.safeguard.sh/scan on any project that has a manifest, and use the Gold directory to see how other advisories for the same product read.
What to do now
- Decide whether the application needs to be reachable from the internet at all. If not, block public access today.
- If it must stay up, put it behind authentication, a VPN or an IP allowlist, and add a web application firewall rule in front of search-report-result.php as a stopgap.
- Replace string built queries that use serachdata with prepared statements, and review the other queries in the same code.
- Give the application's database user the minimum rights it needs. It should not own the schema or read tables it never uses.
- Check the vendor site and the linked report for a fixed release before you rely on any patch claim. I could not confirm one.
- Watch the logs for the page named above for a few weeks after you change anything.
The shape of the fix is the same in every language. In PHP with PDO it looks like this, where the query text and the value travel separately:
$stmt = $pdo->prepare('SELECT * FROM items WHERE id = ?');
$stmt->execute([$id]);
$row = $stmt->fetch();
The placeholder is filled by the database driver, so the value is never parsed as SQL. Apply that to every query that touches request data, not only the one named in the CVE.
Why it matters
The record classes the issue as CWE-74 and CWE-89: injection into a downstream component, specifically SQL. A successful attack can read or change what the database holds, within the limits of the database account the application uses. The low confidentiality, low integrity and low availability ratings in the vector reflect that.
Because the flaw lives in the application's own code and not in a shared library, a dependency upgrade will not fix it. Someone has to change the queries.
The KEV flag in the record is false, so this is not on CISA's Known Exploited Vulnerabilities list. Public proof of concept details do exist according to the record, and that is the practical risk here.
Related CVEs in the same product
This product has several sibling CVEs published in the same few days. Each is a separate entry point in one codebase, and together they suggest the query handling problem is not confined to one file:
- CVE-2025-8953: employeeid in /check_availability.php
- CVE-2025-8985: mobilenumber in /profile.php
- CVE-2025-8987: remark in /test-details.php
- CVE-2025-8988: fromdate in /bwdates-report-result.php
- CVE-2025-8989: mobilenumber in /edit-phlebotomist.php
The record lists a different file and parameter for each, so fixing one file does not close the others.
Quick check
Is this being exploited in the wild?
Not on the evidence I have. The record's KEV flag is false, and I found no advisory saying it is exploited in the wild. The record does say the exploit has been disclosed to the public, which is a reason to move quickly. Public details lower the effort for anyone who wants to try, but they are not proof that anyone has.
What should I do first if the vendor has not shipped a fix?
Take the application off the open internet or put it behind a login, VPN or IP allowlist, then change the queries that use serachdata to prepared statements. Also give the database account only the rights the application needs, so a successful injection reaches less.
Sources
- Gold entry for CVE-2025-8986
- Public report linked from the record
- CWE entries used for the weakness classes
- NVD style record for CVE-2025-8986, published 2025-08-14, CVSS 7.3 (HIGH)
Last reviewed: 18 October 2026.
