Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
CWE-6 Variant Incomplete
J2EE Misconfiguration: Insufficient Session-ID Length
This vulnerability occurs when a J2EE application uses session identifiers that are too short, making them easier for attackers to predict or capture.
Definition
What is CWE-6?
This vulnerability occurs when a J2EE application uses session identifiers that are too short, making them easier for attackers to predict or capture.
Session IDs that are too short drastically reduce the number of possible combinations, making them vulnerable to brute-force guessing or enumeration attacks. When an attacker successfully guesses or steals a valid session ID, they can impersonate the legitimate user and hijack their active session, potentially gaining unauthorized access to sensitive data or privileged functions.
To prevent this, developers must ensure session IDs are generated with sufficient length and entropy, typically using a secure random number generator. Longer session IDs exponentially increase the possible values, making them computationally infeasible to guess and significantly raising the security barrier against session hijacking attempts.
Real-world impact
Real-world CVEs caused by CWE-6
No public CVE references are linked to this CWE in MITRE's catalog yet.
How attackers exploit it
Step-by-step attacker path
- 1
The following XML example code is a deployment descriptor for a Java web application deployed on a Sun Java Application Server. This deployment descriptor includes a session configuration property for configuring the session ID length.
- 2
This deployment descriptor has set the session ID length for this Java web application to 8 bytes (or 64 bits). The session ID length for Java web applications should be set to 16 bytes (128 bits) to prevent attackers from guessing and/or stealing a session ID and taking over a user's session.
- 3
Note for most application servers including the Sun Java Application Server the session ID length is by default set to 128 bits and should not be changed. And for many application servers the session ID length cannot be changed from this default setting. Check your application server documentation for the session ID length default setting and configuration options to ensure that the session ID length is set to 128 bits.
Vulnerable code example
Vulnerable XML
The following XML example code is a deployment descriptor for a Java web application deployed on a Sun Java Application Server. This deployment descriptor includes a session configuration property for configuring the session ID length.
<sun-web-app>
...
<session-config>
<session-properties>
<property name="idLengthBytes" value="8">
<description>The number of bytes in this web module's session ID.</description>
</property>
</session-properties>
</session-config>
...
</sun-web-app> Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-6
- Implementation Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks.
- Implementation A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.) With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes. Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.
Detection signals
How to detect CWE-6
Run dynamic application security testing against the live endpoint.
Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.
Code review: flag any new code that handles input from this surface without using the validated framework helpers.
CWE-6
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-6?
How serious is CWE-6?
What languages or platforms are affected by CWE-6?
How can I prevent CWE-6?
How does Plexicus detect and fix CWE-6?
Where can I learn more about CWE-6?
Frequently asked questions
What is CWE-6?
This vulnerability occurs when a J2EE application uses session identifiers that are too short, making them easier for attackers to predict or capture.
How serious is CWE-6?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-6?
MITRE lists the following affected platforms: Java.
How can I prevent CWE-6?
Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks. A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short…
How does Plexicus detect and fix CWE-6?
Plexicus's SAST engine matches the data-flow signature for CWE-6 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-6?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/6.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-6
Resources
Further reading
- MITRE — official CWE-6 https://cwe.mitre.org/data/definitions/6.html
- Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf
- Hold Your Sessions: An Attack on Java Session-id Generation https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/gm05.pdf
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.