CVE-2019-25697 is an unauthenticated SQL injection in CMSsite 1.0, scored 8.2 (high). The cat_id value that category.php receives is used in a database query without safe handling. The record names no patched version, so remove the application from public access and replace it or fix the query yourself.
What's affected
The record lists CMSsite 1.0 by victoralagwu, a small PHP content management project hosted on GitHub. The affected page is category.php and the affected parameter is cat_id, which arrives in a GET request.
The record does not name a fixed version. The reference link points to the repository archive for the master branch, not to a release note.
The record describes extraction of sensitive information such as usernames and credentials. The CVSS vector is AV:N/AC:L/PR:N/UI:N, so no login is needed.
How to check if you're exposed
CMSsite is not distributed through a package manager, so check by hand.
- Search your servers and repositories for a directory named CMSsite or for a file called category.php that reads a cat_id value.
- Look in the code for any place where cat_id is joined into a query string. If it is, that copy is affected whatever the version label says.
- Review access logs for requests to category.php with unusual cat_id values, such as long text, quote characters or SQL keywords.
- Confirm whether the site is reachable from the internet.
What to do now
- Find every copy of CMSsite, including student projects and demo sites that were never taken down.
- Take public copies offline or restrict them by IP address until the code is fixed.
- Rewrite the category query to use a prepared statement, and cast cat_id to an integer before use.
- Review the rest of the code for the same pattern in other pages.
- If the site held real accounts, force password resets and check that passwords were not reused elsewhere.
Why it matters
The weakness is CWE-89, SQL injection. The application builds a database query by putting request data straight into the query text. The database cannot tell which part is the developer's instruction and which part came from the visitor, so crafted input can change what the query does.
Projects like this are often built as learning exercises and then left running on a public host. The risk is not that the code is unusual, it is that nobody is watching it. A forgotten site with a user table is an easy source of credentials that people reuse on other services.
The fix for this class is well understood. Use parameterized queries or prepared statements so that input is always treated as data, validate values against an allowlist where only a few are valid, and give the application database account only the rights it needs. None of this is complicated, but it has to be applied to every query in the code base, which is why one reported parameter is often a sign of others.
Quick check
What makes this one easy to reach?
It needs no login. A single GET request to category.php with a changed cat_id is the entry point described in the record.
Does a web application firewall fix it?
It can reduce risk but it does not change the vulnerable code. Fix the query.
Sources
Last reviewed: 19 October 2026.