CVE-2026-111685 is a high severity (CVSS 7.5) unauthenticated SQL injection in IceCMS through 4.1.5. A crafted num path parameter on the findresourcebynum route reaches the database query, allowing data theft. The record names no fixed version, so block the route and watch for a patch.
What's affected
IceCMS 4.1.5 and earlier, per the record and VulnCheck. The vulnerable route is /WebResource/findresourcebynum, and the record says the num parameter is added after a LIMIT clause through QueryWrapper.last(). I could not confirm a fixed release from the pages I fetched, so check the project's releases and issue tracker before you rely on one.
No login is required. Anyone who can reach the site can send the request.
Scoring note: the record's 7.5 is a CVSS 3.1 base score. VulnCheck's advisory also lists 8.7 under CVSS 4.0. Both describe the same flaw, and the two versions weigh the factors differently.
How to check if you're exposed
Confirm the IceCMS version. Search your own code if you forked it for QueryWrapper.last() calls that take request input:
grep -rn "\.last(" --include=*.java .
In web server logs, look for requests to the resource route with a num value that is not a plain number.
What to do now
- Find every IceCMS deployment and its version.
- Block or filter the findresourcebynum route at your proxy or WAF while no fix is confirmed.
- Restrict the database account used by the app to the minimum privileges it needs.
- Review logs for non numeric values in the num parameter and treat matches as a possible data breach.
- Rotate credentials stored in the database if you find signs of access.
- Upgrade when a confirmed fix is released.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Keep a record of what you checked and what you changed. Note the version found, the date, the action taken and who approved it. If the advisory is later updated, for example with a fixed release, you will know which systems need another pass, and an auditor or a colleague can follow your reasoning.
Why it matters
This is CWE-89, SQL injection. The code builds part of a query by appending a request value to the SQL text. QueryWrapper.last() writes its argument into the statement verbatim, so the framework's usual parameter binding does not apply to it.
The fix pattern is plain. Validate the value as a number and bind it as a parameter, never append it. Because the route needs no login, a scanner can find it without any foothold. It is not listed in CISA KEV.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why does last() matter?
It inserts text into the SQL string without binding, so request input placed there is not protected.
Is a WAF enough?
It can reduce risk, but the code path stays vulnerable. Treat it as a temporary measure.
Sources
Last reviewed: 18 October 2026.
