CVE-2025-4766: High SQL Injection in PHPGurukul Zoo Profile Page

CVE-2025-4766 is a high severity SQL injection flaw (CVSS 7.3) in PHPGurukul Zoo Management System 2.1. The contactnumber input handled by /admin/profile.php reaches a database query unsafely, and the record says it can be reached remotely. No fixed version is confirmed in the record, so check the vendor and cut exposure now.

What's affected

The record names PHPGurukul Zoo Management System 2.1. The weak spot is the file /admin/profile.php and its contactnumber argument. The record also states that an exploit has been disclosed to the public. It does not say the flaw is exploited in the wild, and the CISA Known Exploited Vulnerabilities list does not include it.

The path sits under an admin folder, which suggests a login screen in front of it, but the CVSS vector in the record lists no privileges required. Do not assume the login protects you until you have tested it on your own copy.

I could not confirm a fixed version or a vendor patch. The vendor site is listed as a reference in the record, so check it and any release notes before you decide the product is safe to keep running.

How to check if you're exposed

Start by finding out whether you run this product at all. Look on your web servers for the file named in the record:

find /var/www -name "profile.php" 2>/dev/null

If the path matches /admin/profile.php, you have the affected code. Check the version in the application footer, the readme or the admin page, and compare it with 2.1.

Next, read the file and see how the contactnumber value is used. If it is concatenated into a query string, the page is in the same state the record describes. If it already uses prepared statements, your copy may differ from the one that was reported.

Your web server logs can also help. Search for requests to /admin/profile.php and look for unusual values in the contactnumber field, long strings, or bursts of requests from one address. That will not prove safety, but it shows whether someone has been probing.

What to do now

1. List every place this application runs, including test and demo copies. Small PHP projects often end up forgotten on shared hosting.
2. Check the vendor site and release notes for a patched build. If none is confirmed, treat the product as unpatched.
3. Take the app off the public internet if you can, or restrict it by IP address or VPN until it is fixed.
4. If you must keep it online, change the query behind /admin/profile.php to a parameterized statement, or put a web application firewall rule in front of the contactnumber field as a stopgap.
5. Make sure the database account used by the app has only the permissions it needs, and that it cannot read other databases.
6. Back up the database and review it for unexpected rows or new accounts.
7. Plan a replacement if the vendor does not ship a fix.

If you want a quick look at what your own projects pull in, the free in-browser dependency scan at https://gold.safeguard.sh/scan needs no setup. The Gold directory lets you look up other CVEs by id.

Why it matters

The record tags this as CWE-89 and CWE-74. Both describe the same mistake: untrusted input is used to build a command for another system, here a database. Parameterized queries and strict input validation are the standard defenses, and a database account with only the rights the app needs limits the damage if something slips through.

Small PHP applications like this are often deployed exactly as shipped, so a flaw in the code is a flaw in every copy. One reported injection point is a reason to review the rest of the app, not just the field named in CVE-2025-4766. Even a medium or high score here can matter, because a database often holds personal data and login hashes.

Quick check

Sources

• Gold page for CVE-2025-4766
• github.com (listed in the CVE record)
• phpgurukul.com (listed in the CVE record)
• vuldb.com (listed in the CVE record)
• vuldb.com (listed in the CVE record)

Last reviewed: 18 October 2026.