CVE-2023-49442 is a critical deserialization flaw, scored 9.8, in JEECG 4.0 and earlier: jeecgFormDemoController allows arbitrary code execution through a crafted POST request. The record names no fixed version, so check the project's releases and keep the demo controller unreachable from any network.
What's affected
The record says deserialization of untrusted data in jeecgFormDemoController in JEECG 4.0 and earlier allows attackers to run arbitrary code through a crafted POST request. The NVD vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
The only reference is a researcher blog post. I did not fetch it, because it may describe exploitation in detail and the record already states the weakness. The record lists no fixed version, so nothing here confirms a patched release. Check the JEECG project's release notes and issue tracker.
How to check if you're exposed
Find JEECG in your Java projects through the build files. For Maven, list the dependency tree.
mvn dependency:tree | grep -i jeecg
For Gradle, run the dependencies task and search for the same name.
gradle dependencies | grep -i jeecg
If you deploy JEECG as an application rather than a library, read its version from the project files or the admin page. Version 4.0 and earlier is in the affected range.
Then check whether a route that maps to the demo form controller is exposed in your deployment.
What to do now
- Find every JEECG deployment and read its version.
- Check the project's repository for a release or commit that addresses CVE-2023-49442, since the record names no fix.
- Remove or block demo controllers and sample code from any deployment that faces a network.
- Place the application behind authentication and a web application firewall rule that restricts the affected route, if you cannot patch.
- Review logs for unexpected POST requests to demo endpoints and for new processes on the host.
Why it matters
The weakness is deserialization of untrusted data, CWE-502. When an application rebuilds objects from bytes that an outsider controls, the process can be pushed into running code that the developers never intended.
Demo and example controllers are often shipped with a framework and forgotten in production. They tend to skip authentication because they were written to show a feature, not to protect data. KEV status is false for this CVE, so this post does not claim exploitation in the wild.
Reachability analysis helps here. A dependency scan tells you JEECG is present, and a check of whether the demo route is wired up tells you whether you can be hit.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is a demo controller risky?
Demo code is often left unauthenticated and unreviewed, and when it deserializes input it gives attackers a direct route into the application.
Sources
Researcher post referenced by NVD (not fetched)
Last reviewed: 19 October 2026.
