CVE-2025-7757 is a high severity (CVSS 7.3) SQL injection in PHPGurukul Land Record System 1.0. The editid parameter in /edit-property.php reaches a database query without safe handling, and the CVSS vector lists network access with no login or user interaction. The record names no fixed version, so rewrite the query or take the app offline.
The description says the exploit has been disclosed to the public and may be used. The record does not flag this CVE as exploited in the wild, and it is not marked as a CISA Known Exploited Vulnerability. Public details still make it easy for others to try, so do not wait on that distinction.
What's affected
The record lists PHPGurukul Land Record System 1.0. The weakness is in /edit-property.php, through the editid parameter. An edit identifier on a property edit page decides which record the query touches, and an update query that is built unsafely can change data, not only read it. A land record application normally keeps property and owner records in one database.
I could not confirm a fixed version. The record lists none, and the vendor page is a general site, not a security advisory. Land Record System appears to be distributed as a free downloadable sample project, so a patched release may never ship. Treat any copy you run as unpatched until you have changed the code yourself.
Severity needs a note. The description calls the issue critical, which is the wording VulDB uses when it files these reports. The score in the record is CVSS 7.3, which is High, with a vector of network access, low complexity, no privileges, no user interaction and low impact on each of confidentiality, integrity and availability. This post uses the score. The public write-up linked from the record returned a not found page when I tried it, so this post rests on the record itself and not on the original report. Nothing here goes beyond what the record states.
How to check if you're exposed
First find out whether you run this application at all. Search web roots and repositories for the file name and for the product name:
find / -name "edit-property.php" -path "*php*" 2>/dev/null
grep -rIl "Land Record System" /var/www 2>/dev/null
If the file exists, open it and look at how the editid value reaches the database. A query assembled by joining strings is the problem. A prepared statement with bound parameters is not:
grep -n "mysqli_query\|mysql_query\|->query(" edit-property.php
Then look at your web server access log for requests to the file. Unusual quote characters, SQL keywords or very long values in the parameter deserve a closer look:
grep "edit-property.php" /var/log/apache2/access.log | grep -i "%27\|union\|sleep(" | head
A clean log does not prove safety, because logging may be off or rotated. A hit means you should treat the database as possibly read or changed.
Safeguard's free in-browser dependency scan covers third party packages. It will not flag this issue, which sits in the application's own query code, so use code review or a SAST tool for that part.
What to do now
- Decide whether the application needs to run. If it is a demo, a training copy or an unused install, remove it.
- If it must stay up, take it off the public internet or limit it by IP address or VPN until the code is fixed.
- Replace string built queries in /edit-property.php and in every other file that talks to the database with prepared statements. In PHP with mysqli the pattern looks like this:
$stmt = $conn->prepare("SELECT * FROM some_table WHERE some_column = ?");
$stmt->bind_param("s", $value);
$stmt->execute();
- Give the database account the application uses only the rights it needs. It should not own the schema or reach other databases.
- Review access logs and recent database changes for signs of misuse. If you find any, rotate the database password and any application credentials.
- A web application firewall rule can reduce noise while you fix the code. It is a stopgap, not a fix.
Why it matters
CWE-89 is SQL injection, and CWE-74 is the wider class of injection, where input changes the meaning of a command that another component interprets. Here the cause is plain: the editid value is placed into a SQL statement without being kept separate from the command. The database cannot tell data from instructions, so crafted input can change what the query does.
The damage depends on the query and the database account. It can range from leaking records to changing or deleting them. In small PHP projects, one account often has wide rights, which raises the stakes. The fix is not a longer blocklist. It is keeping data out of the command text, which prepared statements do by design.
Quick check
Is there a patched version of Land Record System?
The record lists none, and I found no vendor advisory. Check the vendor site, and if nothing is published, fix the query code yourself or retire the application.
Does a web application firewall solve this?
It can block some obvious attempts, but it does not remove the flaw. The query is still built unsafely. Use prepared statements and treat the firewall as extra cover.
Sources
Last reviewed: 18 October 2026.
