CVE-2025-7155 is a high severity (7.3) SQL injection in PHPGurukul Online Notes Sharing System 1.0. The sessionid argument handled by /Dashboard (Cookie Handler) 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: PHPGurukul Online Notes Sharing System, version 1.0 (the only version named in the record).
- Component:
/Dashboard (Cookie Handler), which is the code that reads the session cookie for the dashboard. - Parameter:
sessionid. - 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. There is a wrinkle in the sources. The researcher's write-up is titled as an XPath injection, while the NVD description says the original disclosure suspects XPath injection but that the payload it supplied looks like SQL injection. This post follows the record and treats it as SQL injection (CWE-89). If you review the code yourself, confirm which query language the cookie value reaches.
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
/Dashboard. - 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
sessionidor 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
/Dashboard, 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
/Dashboardas 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
The weakness here is the oldest one in web development. A request value is concatenated into a SQL statement instead of being passed as a bound parameter, so the database may treat part of the value as SQL.
The class is tracked as CWE-89 (SQL injection) under the broader CWE-74 (injection). The flaw sits in the code that reads the session cookie for the dashboard, so the data behind it is what is at risk: records in the Online Notes Sharing System 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-7155?
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 /Dashboard 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
- Online-Notes-Sharing-System-Php-Gurukul-Python/Online-Notes-Sharing-System-Php-Gurukul-Python-Xpath-Injection.md at main · Vanshdhawan188/Online-Notes-Sharing-System-Php-Gurukul-Python
- PHPGurukul site
- Gold page for CVE-2025-7155
- NVD record for CVE-2025-7155, 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.