CWE-579 is a J2EE reliability bug. The application stores a non-serializable object as an HttpSession attribute.
It does not look dangerous, and it is not an attack in itself. MITRE lists the consequence as quality degradation. But it breaks a feature that large Java deployments rely on: session replication.
How it happens
MITRE explains the background. A J2EE application can run across multiple JVMs for reliability and performance. To make them look like one application, the container can replicate an HttpSession across JVMs, so that if one becomes unavailable another can step in without disrupting the user. This only works if all session data is serializable.
MITRE's example adds a class to the session even though the class does not implement Serializable:
// Vulnerable: DataGlob is not Serializable
public class DataGlob {
String globName;
String globValue;
public void addToSession(HttpSession session) {
session.setAttribute("glob", this);
}
}
On a single server it works. When clustering or failover is turned on, replication fails for that session, and users can lose state, get logged out, or see errors after a failover.
What an attacker gains
MITRE lists quality degradation only. There is no direct data access. The practical cost is availability and consistency: failures that appear exactly when a node goes down, which is also when you can least afford surprises.
How to find it
MITRE says automated static analysis can find some instances. You can also review every setAttribute call and check the type being stored, and test failover in a staging cluster with real session contents.
How to fix it
MITRE's mitigation: the values the product stores as session attributes must implement the Serializable interface for replication to work.
// Fixed
public class DataGlob implements java.io.Serializable {
private static final long serialVersionUID = 1L;
String globName;
String globValue;
...
}
Also check fields. A serializable class that holds a non-serializable field, such as a connection or stream, still fails. Mark such fields transient and rebuild them when needed, or keep heavy objects out of the session and store identifiers instead.
Be careful with serialization more broadly. Deserializing untrusted data is a different and serious problem, so keep session data simple and never accept serialized objects from clients.
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.
Quick check
Why must session attributes be serializable?
So the container can copy the session to other JVMs for failover and load balancing.
What about non-serializable fields inside a serializable class?
They still break serialization. Mark them transient or keep them out of the session.
