pretix CVE-2026-101271

Exploitation requires an attacker to already hold a valid, unexpired OAuth access token bound to a specific OAuth client (application) in pretix, and for an administrator to have manually disabled that client afterward. The token continues to work only until its normal lifetime expires - there is no way to extend it - so the exposure window is bounded by the original token TTL. This is authenticated access (PR:L, a valid token is a prerequisite) with high complexity (AC:H) and a required attack condition (AT:P per the vendor vector); it does not enable unauthenticated access against a default configuration. The limiting factors are significant: the token must pre-exist the disable action, remain within its lifetime, and the attacker must possess it.

This is a low-severity access-control weakness, not a high-CVSS scramble. All signals point the same low direction: the vendor's own CVSS 4.0 vector (CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N) yields only 2.1, driven by high attack complexity (AC:H), a required attack condition (AT:P), required privileges (PR:L), user interaction (UI:P), and uniformly Low impact metrics. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept - so this is 'no public exploit identified at time of analysis.' The core issue is improper credential revocation: an OAuth access token remains valid for its full natural lifetime even after an administrator manually disables the OAuth client it is bound to, defeating the assumption that disabling an app immediately cuts off its access. The realistic risk is narrow and conditional - it only matters for a token that was already issued to an app that an operator later disabled, and only until that token would have expired anyway. Confirmed as a vendor self-report by rami.io (pretix's maker) with a fix shipped in release 2026.7.1. Note the CWE is listed as N/A and the 'Information Disclosure' tag only partially fits - the flaw is fundamentally insufficient credential/session revocation (CWE-613-style), which happens to allow continued read/write access rather than being a pure disclosure bug.

An administrator disables a compromised or decommissioned OAuth application in pretix, believing this immediately revokes its access. An attacker (or the decommissioned integration) still holding a previously-issued access token continues to call the pretix API with that token until it naturally expires, reading or modifying event/order data the token's scope permits. No public exploit code exists; exploitation requires already possessing a valid, not-yet-expired token bound to the disabled client.