PHPGurukul Tourism Management System 1.0 has a high severity SQL injection, CVE-2025-13247 (CVSS 7.3), in /admin/user-bookings.php. The CVE record names no fixed release, so the safe moves are to limit who can reach the app and to rewrite the vulnerable query with bound parameters.
What's affected
PHPGurukul Tourism Management System 1.0 is the affected product. The record, published on 2025-11-16, says the flaw sits in /admin/user-bookings.php and that changing the uid parameter alters the SQL the application builds. No login is needed to reach it.
The record maps the flaw to CWE-89 (SQL injection) and its parent class CWE-74 (injection). The CVSS vector is 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 user interaction, and limited impact on confidentiality, integrity and availability.
The record does not list a fixed version. It also states that a public write up exists for this issue, which lowers the bar for anyone who wants to test it against a live site. The record's kev flag is false, so CISA has not listed it as exploited in the wild. Public details still mean you should assume scanning is possible.
How to check if you're exposed
Start by finding out whether you run this software at all. Small PHP apps like this one often live on a forgotten virtual host, so check web roots and not just your asset list.
# find the vulnerable file in your web roots
find /var/www -name "user-bookings.php" 2>/dev/null
# see how the parameter is used in the source
grep -rn "uid" --include=*.php /var/www 2>/dev/null | head -50
If the file exists and the code builds SQL by joining that value into a query string, you are exposed. Check the web server access log for requests to that path that carry odd quote characters or SQL keywords in the value.
grep "/admin/user-bookings.php" /var/log/nginx/access.log | tail -100
For a wider view across your own code and dependencies, the free in-browser dependency scan is a quick place to start, and the Gold directory lists the CVE and its weakness classes in one place.
What to do now
- Find every copy of Tourism Management System you run, including test and staging hosts.
- Take it off the public internet. Put it behind a VPN or an IP allow list until it is fixed.
- Check the vendor or project page for a newer release. The record names none, so confirm against the advisory before you trust any version number you are told.
- Rewrite the vulnerable query to use bound parameters. The shape of the fix is the same in any language:
$stmt = $pdo->prepare("SELECT * FROM items WHERE id = :id");
$stmt->execute([':id' => $id]);
$row = $stmt->fetch();
- Give the application database account only the rights it needs, so a bad query cannot read or change unrelated tables.
- Review database and web logs since 2025-11-16 for unusual requests to
/admin/user-bookings.php, and rotate any credentials stored in that database if you see signs of probing. - Add a rule to your pull request checks that fails on string built SQL, so the pattern does not come back.
Why it matters
SQL injection happens when user input is placed inside a query as code instead of being passed as data. The database cannot tell the two apart, so the attacker's text can change what the query does. Depending on the app, that can mean reading records the page was never meant to show, changing stored data, or bypassing a login check. The vector shows no privileges required (pr:n), so an anonymous visitor can reach the flaw.
This family of bugs is old and well understood, which is the frustrating part. The fix is not exotic. Prepared statements, input validation as a second layer, and a least privilege database account stop the class. Apps that skip them tend to repeat the mistake in many files, so fixing one parameter and moving on is rarely enough. Search for every place the app builds a query from request data.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2025-13247 exploited in the wild?
The record's KEV flag is false, so it is not on the CISA Known Exploited Vulnerabilities list. The record does say a public write up exists, so treat the details as widely available.
What is the permanent fix?
Replace string built SQL with prepared statements that bind the value as a parameter. Then check the rest of the code base for the same pattern, because one flaw like this is often one of several.
Sources
- Safeguard Gold entry for CVE-2025-13247
- https://github.com/L-Bitter/CVE/issues/3
- https://phpgurukul.com/
- https://vuldb.com/?ctiid.332581
- https://vuldb.com/?id.332581
Last reviewed: 19 October 2026.
