CVE-2025-8966 is a high severity (CVSS 7.3) SQL injection in itsourcecode Online Tour and Travel Management System 1.0. The record says manipulating the tname parameter of /admin/operations/tax.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.
The weakness is old and well understood. User input reaches a database query without being kept apart from the SQL text, so the input can change what the query does. The weakness classes are CWE-74 and CWE-89.
What's affected
itsourcecode Online Tour and Travel Management System 1.0, according to the record. The affected component is /admin/operations/tax.php, and the parameter named is tname. 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/zzb1388/cve/issues/37). 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 itsourcecode as the vendor, while the product field in the record carries a mayurik 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 'tax.php' 2>/dev/null
If that finds the file, open it and look at how tname 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 "tax.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 tax.php as a stopgap.
- Replace string built queries that use tname 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.
Unlike a library bug, there is no package to bump here. The code is the application, so the fix is a change to the application's own queries. If the project is not being maintained, that change falls to whoever runs it.
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-8967: pname in /admin/operations/packages.php
- CVE-2025-8968: ID in /admin/disapprove_user.php
- CVE-2025-8969: ID in /admin/approve_user.php
- CVE-2025-8970: ID in /admin/operations/booking.php
- CVE-2025-8971: val-username in /admin/operations/travellers.php
- CVE-2025-8972: email in /admin/page-login.php
- CVE-2025-8981: payment_type in /admin/operations/payment.php
- CVE-2025-8982: curr_code in /admin/operations/currency.php
- CVE-2025-8983: expense_for in /admin/operations/expense.php
- CVE-2025-8984: expense_name in /admin/operations/expense_category.php
- CVE-2025-8993: from_date in /admin/expense_report.php
The record lists a different file and parameter for each, so fixing one file does not close the others.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does a public disclosure mean this is being exploited?
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 tname 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-8966
- Public report linked from the record
- CWE entries used for the weakness classes
- NVD style record for CVE-2025-8966, published 2025-08-14, CVSS 7.3 (HIGH)
Last reviewed: 18 October 2026.
