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. 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. 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. 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.

Vulnerable XML 
<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

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

SAST High

Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.

DAST Moderate

Run dynamic application security testing against the live endpoint.

Runtime Moderate

Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.

Code review Moderate

Code review: flag any new code that handles input from this surface without using the validated framework helpers.

Plexicus auto-fix

Plexicus auto-detects CWE-6 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

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

CWE-334 Parent

Small Space of Random Values

This vulnerability occurs when a system uses a random number generator that produces too few possible values. Attackers can easily predict…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.