CVE-2025-8973 is a high severity (CVSS 7.3) SQL injection in SourceCodester Cashier Queuing System 1.0. The record says manipulating the Username parameter of /Actions.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
SourceCodester Cashier Queuing System 1.0, according to the record. The affected component is /Actions.php, and the parameter named is Username. 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/30). 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 SourceCodester as the vendor, while the product field in the record carries an oretnom23 entry. Match on the file path and version when you check your own install.
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 'Actions.php' 2>/dev/null
If that finds the file, open it and look at how Username 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 "Actions.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 Actions.php as a stopgap.
- Replace string built queries that use Username 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.
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 is the fastest safe step if there is no patch?
Take the application off the open internet or put it behind a login, VPN or IP allowlist, then change the queries that use Username 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-8973
- Public report linked from the record
- CWE entries used for the weakness classes
- NVD style record for CVE-2025-8973, published 2025-08-14, CVSS 7.3 (HIGH)
Last reviewed: 18 October 2026.
