CVE-2025-3799 is a high severity SQL injection flaw (CVSS 7.3) in WCMS 11. It affects app/controllers/AnonymousController.php through the email and username argument and needs no login. The record lists no fixed version, so check the project page, restrict access, and rewrite the query with prepared statements.
What's affected
The record names WCMS version 11. The affected file is app/controllers/AnonymousController.php, and the argument is email and username. The record also says other parameters might be affected. The record lists no fixed version.
The record lists the weakness as CWE-74 (improper neutralization of special elements in output used by a downstream component) and CWE-89 (SQL injection). The CVSS 3.1 score is 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. The vector shows the flaw can be reached over the network, and no login is needed. Confidentiality impact is rated low, integrity low and availability low.
The record says the exploit has been disclosed to the public and may be used. It does not say the flaw is exploited in the wild, and the CISA Known Exploited Vulnerabilities flag is false. Treat any copy that is reachable from the internet as the priority.
How to check if you're exposed
- Find out whether you run this software. Search your web roots for the affected file name:
find /var/www -type f -name 'AnonymousController.php' 2>/dev/null
- Confirm the version from the project files or install notes and compare it with version 11.
- Look at how the value of email and username reaches a query. Concatenating request input into a SQL string is the pattern the record describes:
grep -n 'query\|execute\|SELECT' app/controllers/AnonymousController.php 2>/dev/null
- Review access logs for requests to that file with unusual characters in the parameter, and database logs for errors at the same times.
If you manage many repositories, the free in-browser dependency scan covers the libraries your projects pull in, and the Gold directory lets you look up other CVEs by product. Neither replaces reviewing the code of an application you deploy by hand.
What to do now
- Take the application off the public internet or put it behind a login, VPN or allow list until it is reviewed.
- Check the vendor or project page for a newer release. The record gives no fixed version, so the advisory should be checked before you plan an upgrade.
- Replace string built SQL in the affected file with prepared statements, and cast numeric inputs to the expected type.
- Run the database account with the least privilege the application needs, and keep read and write accounts separate where you can.
- Search the rest of the codebase for the same query pattern and fix every match, not just the reported file.
- Watch web server and database logs for repeated errors from the affected page.
Why it matters
SQL injection happens when text from a request is placed into a database query without being kept apart from the query itself. The database then cannot tell data from instructions. Depending on the account the application uses, that can mean reading records, changing them or both. The fix is well understood: use parameterized queries and validate the type of every input.
Small applications of this kind tend to repeat a coding habit across many files. When one parameter is reported, others nearby are often built the same way. That is why a reported flaw in one file is a good reason to review the whole project.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a fixed version?
The record does not list one. Check the vendor or project page and the record's references before assuming a patch exists, and apply the mitigations above in the meantime.
Sources
- Gold entry for CVE-2025-3799
- NVD record for CVE-2025-3799, published 2025-04-19, as summarized above
- Reference listed in the record
- Reference listed in the record
- Reference listed in the record
- Reference listed in the record
Last reviewed: 18 October 2026.
