CVE-2025-8935 is a high severity (CVSS 7.3) SQL injection in 1000 Projects Sales Management System 1.0. The record says manipulating the Username parameter of /superstore/custcmp.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
1000 Projects Sales Management System 1.0, according to the record. The affected component is /superstore/custcmp.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 GitHub report (https://github.com/lan041221/cvec/issues/6). On 18 October 2026 that page returned not found for me, so I could not read the write-up. Everything here comes from the record. If the report has moved or been removed, that does not tell you the application is safe.
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 'custcmp.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 "custcmp.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 custcmp.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.
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
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-8936: select2 in /superstore/dist/dordupdate.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 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-8935
- Public report linked from the record (not readable when I checked)
- CWE entries used for the weakness classes
- NVD style record for CVE-2025-8935, published 2025-08-14, CVSS 7.3 (HIGH)
Last reviewed: 18 October 2026.
