CWE-574 is an Enterprise JavaBeans rule violation: the bean uses thread synchronization primitives. The EJB specification says an enterprise bean must not use them to synchronize execution of multiple instances.
The reason, quoted by MITRE: some containers run all bean instances in one JVM, while others spread them across several. A synchronized block coordinates threads in one JVM only. In a distributed container it silently stops doing what you think.
How it happens
A developer wants to protect shared state and reaches for synchronized inside a bean, as in the record's Customer entity example. It works in a single JVM test. After the application is clustered, two instances on two JVMs update the same data at once, and the lock protects nothing.
// Vulnerable: lock only covers one JVM
@Stateless
public class CounterBean {
private static int count;
public synchronized void bump() { count++; }
}
What an attacker gains
MITRE lists quality degradation. The practical risk is inconsistent data under load, which a concurrent attacker can provoke.
How to find it
Search bean classes for synchronized, wait, notify and lock classes. The record lists no detection methods.
How to fix it
MITRE's mitigation: do not use synchronization primitives when writing EJBs. Let the container manage concurrency, and use database transactions, optimistic locking or a container managed singleton with declared lock semantics.
// Use the container: declare the transaction, let the database enforce it
@Stateless
public class CounterBean {
@PersistenceContext EntityManager em;
public void bump() {
Counter c = em.find(Counter.class, 1L, LockModeType.PESSIMISTIC_WRITE);
c.setCount(c.getCount() + 1);
}
}
Quick check
Why is synchronized wrong in a bean?
It only coordinates threads inside one JVM, and containers may distribute instances across several.
The free in-browser scan at gold.safeguard.sh/scan lists the dependencies in your manifest. No login is needed, the file stays on your machine, and it handles up to 100 dependencies.
