Spinning up a thread feels routine in plain Java. Inside a web application container it is a different story. CWE-383 says thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone.
This is a quality weakness more than a classic exploit. MITRE lists the consequence as quality degradation, but the bugs it breeds are the ones that surface under load and are hard to reproduce.
How it happens
A servlet or bean starts its own thread to do background work.
public void doPost(HttpServletRequest req, HttpServletResponse res) {
new Thread(() -> sendReport(req.getParameter("id"))).start();
}
The container knows nothing about that thread. It cannot size it, stop it on undeploy, or pass it the right context. MITRE notes this interferes in unpredictable ways with the behavior of the container, and that even without interference, thread management tends to cause deadlocks, race conditions and other synchronization errors.
How to find it
MITRE says automated static analysis can find some instances. Search web modules for new Thread, Thread.start, and Runnable handed to raw executors.
How to fix it
For EJB, MITRE recommends using framework approaches for parallel execution instead of threads. In practice that means container managed executors, message driven beans or the platform's scheduling services, so the container owns the lifecycle.
Quick check
Is this a security hole or a reliability bug?
MITRE records quality degradation as the consequence. Its security relevance is indirect: race conditions and hangs make a service unstable and harder to defend.
