CVE-2025-7950 is a high (CVSS 7.3) SQL injection in code-projects Public Chat Room (version 1.0). The record names no fixed version, so plan on isolating or replacing it. Do not expose the product to untrusted networks until you have confirmed a fix.
What's affected
The record lists version 1.0 as affected. The vulnerable code is in /login.php, through the Username argument.
No fixed version is named in the record or the write-up.
The researcher's issue says user input from the login form is concatenated into the SQL query instead of being bound as a parameter, and that no login is needed. It lists the fixes you would expect: prepared statements, strict input validation, a least privilege database account and regular audits.
The record's CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, a score of 7.3. The GitHub issue was still open with no comments or linked fix when I read it.
The record also says the exploit has been disclosed to the public and may be used. That is not the same as confirmed attacks: this CVE is not in CISA's Known Exploited Vulnerabilities catalog (the record's kev flag is false).
How to check if you're exposed
Start by finding out whether the file exists in any deployment you run:
find /var/www /srv /opt -name "login.php" 2>/dev/null
Then look in your web server logs for requests to it. A busy log with odd values in the Username field is worth a closer read:
grep -h "login.php" /var/log/apache2/access.log* /var/log/nginx/access.log* 2>/dev/null | head -50
If you maintain the code, look for queries built by joining strings, which is the pattern behind this class of bug:
grep -rnE "(mysqli_query|mysql_query)\(" --include=*.php . | head -50
A free in-browser dependency scan at gold.safeguard.sh/scan can show whether this CVE appears in a project's dependency list. Note that it covers packages. Stand-alone applications and firmware are best checked against your own inventory.
What to do now
- Confirm whether you run Public Chat Room and in which version.
- Take it off any internet facing host, or put it behind authentication at the web server or VPN, until a fix exists.
- Check the vendor or project site for a newer release. No fix is named in the record.
- Put a WAF rule in front of the login.php endpoint as a stopgap. A WAF reduces risk but does not fix the code.
- If you maintain the code, replace string built queries with parameterized queries, and use a database account with the least privilege the application needs.
If you maintain a codebase and want to know whether a vulnerable package is actually called, Safeguard's reachability analysis separates packages that are present from code paths that are used.
Why it matters
The weakness class here is CWE-74 (injection), CWE-89 (SQL injection). SQL injection happens when user input is joined into a query string, so the database cannot tell the developer's command from the visitor's data. The standard fix is a parameterized query, which keeps the two apart. When the vulnerable field sits on a login or admin page, the code runs before any check on who is asking.
The record notes that the exploit has been disclosed to the public. Small PHP and Java projects like this are often installed without a security review and never updated, which makes published findings useful to anyone scanning for them.
Quick check
Is there a patch for CVE-2025-7950?
The record does not name a fixed version, and for PAD CMS CERT Polska says none will be published. Treat the product as unpatched, reduce its exposure and check the vendor or project site for news.
Is CVE-2025-7950 being exploited in the wild?
The record's kev flag is false, so it is not in CISA's Known Exploited Vulnerabilities catalog. The record does say the exploit has been disclosed to the public, so assume attackers can find it.
Sources
- Safeguard Gold entry for CVE-2025-7950
- Public write-up on GitHub
- NVD record data for CVE-2025-7950, published 2025-07-22, source cna@vuldb.com
Last reviewed: 18 October 2026.
