CVE-2025-7157 is a high severity (7.3) SQL injection in code-projects Online Note Sharing 1.0. The username/password argument handled by /login.php reaches a database query unsafely. The record lists no fixed version, so limit access, repair the query with a prepared statement, or retire the application.
What's affected
- Product: code-projects Online Note Sharing, version 1.0 (the only version named in the record).
- Component:
/login.php, which is the login page. - Parameter:
username/password. - Fixed version: none is listed in the record or in the sources we could reach. Check the vendor site for a newer release before assuming one exists.
The NVD record scores this 7.3 (High, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L). The description, which comes from VulDB, calls the issue "critical". Both statements are in the record, so treat the CVSS score as the formal rating and the word "critical" as VulDB's own wording.
The record sets no KEV flag, and none of the pages we fetched say the issue is exploited against real systems. It does say a public disclosure exists, and that is enough reason to treat the flaw as known to attackers.
How to check if you're exposed
This is a self-hosted PHP application, not a package from a registry, so there is no package manager command that answers the question. Work through these checks instead.
- Find out whether you run it. Search your web roots and deployment inventory for the product name and for the file
/login.php. - Confirm the version. The record only names 1.0, so if you cannot tell which release you have, assume you are affected.
- Look at how the file builds its query. In the source, search for places where
username/passwordor the matching request variable is joined into a SQL string. A grep such as the one below shows candidates.
grep -rn "mysqli_query\|mysql_query\|->query(" /var/www/html | grep -i "\$_\(GET\|POST\|REQUEST\|COOKIE\)"
- Review web server and database logs for unusual values sent to
/login.php, such as stray quotes, SQL keywords or very long inputs. Repeated errors from the database layer are a warning sign. - Check whether the application is reachable from the internet. The record describes a remote attack with no privileges and no user interaction, so internet exposure is what raises the urgency.
What to do now
- Take the application off the public internet, or place it behind a VPN or an IP allow list, until it is fixed.
- Replace the vulnerable query with a prepared statement. In PHP with mysqli the pattern looks like this.
$stmt = $mysqli->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email);
$stmt->execute();
- Run the application's database account with the fewest rights it needs. It should not own the schema or have file or administrative privileges.
- Add a web application firewall rule or request validation in front of
/login.phpas a stopgap, and do not count it as a fix. - Check the vendor site for a patched release. If none exists, plan to replace the application and review the rest of its pages for the same pattern.
- Rotate any credentials stored in the database if logs suggest someone probed the endpoint.
Why it matters
This is injection in the classic sense. The code takes a value from the request and uses it inside a query without separating data from command. The record tags it CWE-74 and CWE-89 for that reason.
The class is tracked as CWE-89 (SQL injection) under the broader CWE-74 (injection). The flaw sits in the login page, so the data behind it is what is at risk: records in the Online Note Sharing database, and possibly stored credentials. The vector in the record rates confidentiality, integrity and availability each as low impact, which is why the score stops at 7.3. Real impact depends on what the database account can reach.
The pattern repeats across small PHP applications. When one page builds queries by string concatenation, others usually do too, and public disclosures tend to arrive in groups. Fixing one parameter and leaving the rest leaves the same exposure in place.
Quick check
Is there a patch for CVE-2025-7157?
The record lists no fixed version. Check the vendor site and the advisory yourself. Until a release exists, restrict access and fix the query in your own copy.
Can I find this in my own stack without a package manager?
Yes, but it takes code review. Search for the file /login.php and for any query that includes request values without binding. A static scan of your own source can speed this up, and the free in-browser dependency scan at gold.safeguard.sh/scan covers the libraries your projects pull in alongside it.
Sources
- code-projects online-notes-sharing 1 SQL Injection · Issue #3 · yihaofuweng/cve
- code-projects site
- Gold page for CVE-2025-7157
- NVD record for CVE-2025-7157, published 2025-07-08, CNA VulDB.
- Gold page for CWE-89
The researcher issue linked from the record was read and matches the record.
Last reviewed: 18 October 2026.