web.py EUVD-2026-84489

Exploitation requires the attacker to first fix/plant a specific session_id value in the victim's browser cookie for the target web.py application, and then the victim must actually visit the app and successfully authenticate (log in) while that attacker-known session_id is in place - because Session._load() trusts the cookie's session_id and _save() never rotates it after login. Limiting factors: the flaw is only meaningful for web.py 0.76 applications that implement authenticated sessions using the built-in Session component; it needs victim user interaction (UI:R) and a working cookie-setting/fixation vector, and the resulting compromise is scoped to the individual victim's account rather than the whole application or server.

The MITRE/CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N, base 6.8) describes a network-reachable, unauthenticated session-fixation flaw that nonetheless carries two significant real-world dampeners: high attack complexity (AC:H) and required user interaction (UI:R). This is consistent with the classic session-fixation pattern - the attacker cannot act alone but must first plant a known session_id in the victim's browser and then wait for that specific victim to authenticate. There is no EPSS score, no CISA KEV listing, and no proof-of-concept exploit code referenced (the TraceLoom GitHub link is a third-party CVE write-up, not weaponized code), so this is 'no public exploit identified at time of analysis.' The high C:H/I:H impact reflects full authenticated-session takeover, but the practical risk is bounded by AC:H + UI:R and by the product's limited deployment footprint. Net: a legitimate confidentiality/integrity flaw worth patching, but not an emergency - it is a moderate-CVSS, conditional-exploitation issue rather than a mass-exploited priority. Note the impact metrics C:H/I:H are somewhat generous for session fixation (impact is scoped to the individual victim's account, not the whole system); the 6.8 score is defensible but sits at the optimistic end.

An attacker plants a known session_id in a victim's browser (e.g., via a crafted link or cookie-injection vector) and lures the victim to the web.py application, where the victim then logs in. Because Session._load() reads the session_id straight from the cookie and _save() reuses it with no rotation after authentication, the fixed session_id now carries the victim's authenticated state, and the attacker replays that same session_id to hijack the account. No public exploit code exists, and success depends on the victim interacting and successfully authenticating during the fixed session (AC:H, UI:R).