CVE-2025-4266: High SQL Injection in PHPGurukul Notice Board System

CVE-2025-4266 is a high severity (CVSS 7.3) SQL injection in PHPGurukul Notice Board System 1.0. The fromdate and tomdate inputs of /bwdates-reports-details.php?vid=2 reaches a database query without safe handling, so a remote request can change what the query does. No fixed version is confirmed in the record, so patch the code and restrict access.

What's affected

PHPGurukul Notice Board System, version 1.0, per the record. The vulnerable code is in /bwdates-reports-details.php?vid=2, and the record names fromdate and tomdate as not handled safely. The product is a notice board with a date range report page.

The record lists no fixed version. The vendor or project site is linked from the CVE, but the record includes no patch notes or advisory. Check the vendor site directly before assuming a fix exists. Treat every copy of this version as vulnerable until you have confirmed otherwise.

The weakness is tagged CWE-89 (SQL injection) and CWE-74, the broader class of injection into a downstream component. The CVSS 3.1 vector in the record is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. In plain terms, it is reachable over the network, needs no special complexity, and the scoring assumes no privileges and no user interaction. Even if the path sits under an admin folder, do not assume the page is protected unless you have tested that on your own deployment.

Note that the record names two parameters, the start and end dates of a report. Date fields are easy to forget because they look harmless, but anything a user can send must be treated as untrusted. The NVD product entry lists the vendor as anujk305, while the description names PHPGurukul.

How to check if you're exposed

First find out whether you run this product at all. Look for the application folder on your web servers and check the version noted in the readme, the footer or the project files.

find /var/www -type f -name "bwdates-reports-details.php" 2>/dev/null

Then look at how the code builds its query. Search the file for the input name and read what happens to the value.

grep -n -E "fromdate" /var/www/path/to/app/bwdates-reports-details.php

If the value is concatenated straight into a SQL string, the code has this weakness. In web server logs, look for requests to bwdates-reports-details.php with unusually long values or SQL keywords in the query string. Absence of such entries is not proof of safety, since POST bodies are often not logged.

You can also run the free in-browser dependency scan at gold.safeguard.sh/scan on your project manifests. It covers third party libraries, so it will not find a flaw in application code like this one. For that you need code review or a code scanner.

What to do now

1. Find every copy of PHPGurukul Notice Board System 1.0 in your environment, including test and demo servers that people forget about.
2. If the application is not needed, take it offline. Sample and teaching applications are often left running long after the project ends.
3. If it must stay up, limit who can reach it. Put it behind a VPN or an IP allowlist, and add authentication at the web server for the admin paths.
4. Change the vulnerable code to use prepared statements with bound parameters. Do the same for every other query that takes user input.
5. Run the application's database account with the least privilege it needs, with no rights over other databases and no file or administration rights.
6. Review logs for odd requests to bwdates-reports-details.php. If you see signs of abuse, rotate stored credentials and treat the data as exposed.
7. Check the vendor site for a patched release and record the result against this CVE.

A safe version of a lookup in PHP looks like this:

$stmt = $pdo->prepare('SELECT * FROM items WHERE name = :name');
$stmt->execute([':name' => $value]);
$rows = $stmt->fetchAll();

Why it matters

This is a classic injection flaw. Input that should only ever be a value ends up shaping the query itself. Depending on database rights, the outcome can range from reading records to changing or deleting them, which is why even a score in the high 7s deserves quick attention.

The record says the exploit has been disclosed to the public and may be used. That raises the odds that automated scanners include this path. The record does not flag the CVE as listed in CISA's Known Exploited Vulnerabilities catalog (KEV), and that does not prove it has not been used. The CNA calls the issue critical in its text, while the CVSS 3.1 base score of 7.3 puts it in the High band, so plan remediation accordingly.

Quick check

Sources

• Gold entry for CVE-2025-4266
• Gold entry for CWE-89
• VulDB entry, listed in the CVE record
• Public issue report, listed in the CVE record

The vendor and reference pages above are linked from the CVE record. Some of them block automated access, so I could not read their full text. Verify fixed versions on the vendor site.

Last reviewed: 18 October 2026.