web.py CVE-2026-79313

Requires the attacker to already possess a previously valid web.py session cookie AND for the attack to occur after the configured idle timeout but BEFORE the periodic session-cleanup job purges the expired record - the vulnerability is the absence of a last-access-time check when a session is loaded. Limiting factors: the attacker must first acquire the session token (via theft, capture, or leak), impact is confined to the compromised account's privileges, and the exposure window closes once cleanup runs. It is not exploitable by an attacker holding no prior session token, contrary to the PR:N in the published CVSS vector.

Signals conflict sharply. NVD/MITRE assign CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), but that vector is inconsistent with the described flaw: CWE-613 Insufficient Session Expiration lets an attacker who ALREADY holds a previously valid session cookie continue using it past the configured idle timeout. That prerequisite is ignored by the 9.8 vector - a fully unauthenticated attacker with no cookie cannot trigger anything, and impact is bounded by the hijacked account's privileges, not automatic full C/I/A on the host. SSVC largely agrees the raw score overstates urgency: Exploitation=none (no observed exploitation) with Automatable=yes and Technical Impact=total. EPSS is not provided; the CVE is NOT in CISA KEV. The two GitHub references are the vendor source repo and a third-party TraceLoom writeup (an analysis/advisory, not confirmed weaponized exploit code). Net: a genuine session-management weakness but a LOW-to-MEDIUM real-world priority mislabeled as CRITICAL - the 9.8 should be independently downgraded, and this is better treated as a session-lifetime hardening fix than an unauthenticated RCE-class emergency.

An attacker obtains a user's web.py session cookie (via a shared/public terminal, network capture on a non-TLS deployment, or an XSS/logging leak). Even after the configured idle timeout should have expired the session, web.py never checks last-access time on load - so as long as the periodic cleanup job has not yet purged the record, the attacker replays the cookie and continues accessing the victim's protected resources. A third-party analysis (TraceLoom) documents the behavior, but no confirmed weaponized exploit code is published.