pretix CVE-2026-101272

Exploitation requires an authenticated token-based API user (PR:L - a valid pretix API token) and is specific to the data-shredding workflow, where generated files are not correctly bound to the authenticating identity because all token-based API users share one session token. Exploitation is sharply limited by several factors: the files are referenced only by randomly generated UUIDs, they exist for only about one day before deletion, the CVSS vector indicates high attack complexity (AC:H) and a present attack requirement (AT:P), and the vendor assesses real-world risk as virtually nil. This is a defense-in-depth regression of a protection intended in 2026.7.1 rather than a directly weaponizable data-exposure path.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor-supplied CVSS 4.0 base score is 2.3 (Low) with vector AV:N/AC:H/AT:P/PR:L/UI:N and only Low confidentiality/integrity impacts; the PR:L metric means a valid API token is required, so this is an authenticated weakness, not an unauthenticated one. The SSVC/priority decision label is 'monitor', the lowest actionable tier, and there is no CISA KEV listing, no EPSS score, and no public exploit identified at time of analysis. The vendor itself states there is 'virtually no risk' because the affected files are named by randomly generated UUIDs and are deleted after one day; the AC:H and AT:P metrics reinforce that triggering the flaw is not straightforward or attacker-controlled on demand. The only reason this was assigned a CVE at all is that it defeats a defense-in-depth control (binding shredding files to the authenticating identity) that was supposed to have been fixed in 2026.7.1. No EPSS data was provided, so widespread-exploitation probability cannot be quantified, but every other signal points the same way: this is a low-severity hardening regression, not an emergency.

A party holding a valid pretix API token performs a data-shredding operation; because all token-based API users share the same session token, the files produced are not correctly bound to the authenticating identity, so another token-based API user could in principle retrieve them. Realistically the attacker would also need to know the randomly generated UUID referencing the file within its one-day lifetime, and no public exploit code exists; the exact trigger mechanics beyond the shared-token binding are not detailed in the available sources.