shared × unstructured — bad data written permanently, and it spreads

Cross-Session Contamination

Per-request data written into a shared singleton with no validation lets one user's input overwrite the field another user then reads.

01the recipe

In the wild

compound ofCross-Boundary State ExposureCWE-567 Unsynchronized AccessLack of Input ValidationCWE-20 Input ValidationcompoundCWE-488 Session Bleed

example.py

# SMELL: per-request data written into a shared singleton, unguarded.
# (cross-boundary state exposure x lack of input validation)
class Config:                        # one shared instance for the whole process
    locale = "en"
cfg = Config()
def handle(req):
    cfg.locale = req.params["locale"]   # unvalidated, and shared by all requests
    return render(cfg)                  # another request's locale bleeds in here

# RIGHT: validate, and keep per-request state out of shared singletons.
ALLOWED = {"en", "es", "fr"}
def handle(req):
    loc = req.params.get("locale", "en")
    if loc not in ALLOWED:
        loc = "en"
    return render(locale=loc)           # local to this request; nothing shared

A singleton holds one slot for a value every concurrent request writes; with no validation and no isolation, one user's input overwrites the field another user then reads -- their data crosses the session boundary. Validate the input and keep per-request state with the request.

// observed

shared: request B renders with request A's locale (and vice versa)
right: validated, per-request value -- no state crosses the boundary

02weakness catalog

Mapped weaknesses (CWE)

On its own, this defect is catalogued by MITRE as one or more of these weaknesses. The exploitable vulnerability usually appears only when it chains or combines with another.