CVE-2025-8960 is a high severity (CVSS 7.3) SQL injection in Campcodes Online Flight Booking Management System 1.0. The record says manipulating the ID parameter of /admin/save_airlines.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.
This is the classic form of the bug. A value from the request is built into a SQL statement, and the database cannot tell the developer's query from the visitor's input. The weakness classes are CWE-74 and CWE-89.
What's affected
Campcodes Online Flight Booking Management System 1.0, according to the record. The affected component is /admin/save_airlines.php, and the parameter named is ID. 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 write-up on Yuque (https://www.yuque.com/yuqueyonghuvrsrwv/dhlxlu/ykgg3tumuaefd0ft). On 18 October 2026 that page returned a 401 unauthorized response for me, so I could not read it. Everything here comes from the record. A page that needs a login is not a sign the flaw is harmless.
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.
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 'save_airlines.php' 2>/dev/null
If that finds the file, open it and look at how ID 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 "save_airlines.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 save_airlines.php as a stopgap.
- Replace string built queries that use ID 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.
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.
There is no dependency to upgrade. The vulnerable code is the application itself, which means the remedy is an edit to its queries, made by the vendor or by you.
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
Other CVEs in the same product were published on the same days. Each one is a separate entry point in the same codebase, which tells you more than any single entry does:
- CVE-2025-8952: Username in /admin/ajax.php?action=login
- CVE-2025-8957: departure_airport_id in /flights.php
The record lists a different file and parameter for each, so fixing one file does not close the others.
Quick check
Is this CVE on the CISA KEV list?
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 ID 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-8960
- Public report linked from the record (not readable when I checked)
- CWE entries used for the weakness classes
- NVD style record for CVE-2025-8960, published 2025-08-14, CVSS 7.3 (HIGH)
Last reviewed: 18 October 2026.
