CWE-488: Exposure of Data Element to Wrong Session
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
Last updated
Overview
Data can "bleed" from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool. In the case of Servlets, developers sometimes do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition.
Real-world CVEs
33 recorded CVEs are caused by CWE-488 (Exposure of Data Element to Wrong Session). The highest-severity and most recent are shown first. 14 new CWE-488 CVEs have been recorded so far in 2026 (8 in 2025).
- CVE-2026-16326
consul-mcp-server vulnerable to cross-tenant credential reuse in streamable-HTTP stateless mode
Critical · CVSS 10.0 · EPSS 22th2026-07-29 - CVE-2026-16498
terraform-mcp-server vulnerable to cross-tenant credential reuse in streamable-HTTP stateless mode
Critical · CVSS 10.0 · EPSS 38th2026-07-28 - CVE-2024-38367
CoacoaPods trunk sessions verification step could be manipulated for owner session hijacking
Critical · CVSS 9.6 · EPSS 96th2024-07-01 - CVE-2025-47928
Spotipy repo vulnerable to secrets exfiltration via `pull_request_target`
Common consequences
What can happen when CWE-488 is exploited.
Read Application Data
Affects: Confidentiality
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-488, grouped by where in the lifecycle they apply.
Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions.
Use a static analysis tool to scan the code for information leakage vulnerabilities (e.g. Singleton Member Field).
In a multithreading environment, storing user data in Servlet member fields introduces a data access race condition. Do not use member fields to store information in the Servlet.
How to detect it
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following Servlet stores the value of a request parameter in a member field and then later echoes the parameter value to the response output stream.
Vulnerable example
public class GuestBook extends HttpServlet {While this code will work perfectly in a single-user environment, if two users access the Servlet at approximately the same time, it is possible for the two request handler threads to interleave in the following way: Thread 1: assign "Dick" to name Thread 2: assign "Jane" to name Thread 1: print "Jane, thanks for visiting!" Thread 2: print "Jane, thanks for visiting!" Thereby showing the first user the second user's name.
Terminology & mappings
Mapped taxonomies
- 7 Pernicious Kingdoms: Data Leaking Between Users
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-488.
- What is CWE-488?
- The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
- What CVEs are caused by CWE-488?
- 33 recorded CVEs are attributed to CWE-488, including CVE-2026-16326, CVE-2026-16498, CVE-2024-38367.
- How do you prevent CWE-488?
- Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions.
- How is CWE-488 detected?
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
- What are the consequences of CWE-488?
- Exploiting CWE-488 can lead to: Read Application Data.
- Is CWE-488 actively exploited?
- 33 recorded CVEs are caused by CWE-488; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-488) (opens in a new tab)
- CWE-488 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-488
Get alerted the moment a new CWE-488 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.