We found a chain of combining multiple weaknesses in the product that could allow an attacker to become any user in the backend and access any data:
\n
The payment integration plugins Stripe (included in the core system), pretix-mollie, pretix-oppwa, pretix-bitpay, pretix-payone, pretix-secuconnect, pretix-sofort, and pretix-saferpay\n contain a code path that is intended for the transport of session \nparameters from a tab with isolated cookies (e.g. in the pretix widget) \nto a new tab. For this purpose, a set of session parameters is \ncryptographically signed and then passed to the new tab as a URL \nparameter. The plugins perform no further validation of the session \nparameters, other than the cryptographic signature being valid. This is \nfixed with the releases issued today by strictly validating that no \nsession parameters outside of the scope of the respective plugin may be \nset.
An unrelated feature in the core system is used to generate redirect links that obfuscate any Referer\n headers for outgoing links to prevent leakage of secrets in URLs. This \nredirect page also requires cryptographically signed parameters. \nUnfortunately, it uses the same key and salt for the signature as the \npreviously mentioned feature in the payment integration plugins. A \nmotivated attacker with access to at least one event in the backend can \ntrick the system into cryptographically signing arbitrary content using \nspecially crafted links. In combination with the previous issue, the \nattacker could use this to set and modify arbitrary parameters on their \nuser session by injecting the signed parameters into the feature of the \npayment providers. This is fixed with the releases issued today by using\n different salts for the signature for each plugin and feature.
A third, unrelated feature in the core system is used for admin users\n to act on behalf of another user, mostly for debugging purposes. With \nbeing able to insert arbitrary parameters into a session, an attacker \ncan abuse this feature to change their session from their actual user to\n any user in the system by guessing a valid user ID. This is fixed with\n the release today by requiring unguessable information to be contained \nin the session of the user to switch to.
\n/control/users/impersonate/stop in your webserver configuration. In nginx, you can do this by inserting location /control/users/impersonate/stop { deny all; }\n into the correct block. However, this only remedies the most critical \nimpact the other vulnerabilities have, and we still recommend you plan \nan update as soon as possible."}],"value":"If you are unable to update quickly, we recommend to block the URL /control/users/impersonate/stop in your webserver configuration. In nginx, you can do this by inserting location /control/users/impersonate/stop { deny all; }\n into the correct block. However, this only remedies the most critical \nimpact the other vulnerabilities have, and we still recommend you plan \nan update as soon as possible."}],"x_generator":{"engine":"Vulnogram 1.0.2"}}},"cveMetadata":{"assignerOrgId":"655498c3-6ec5-4f0b-aea6-853b334d05a6","assignerShortName":"rami.io","cveId":"CVE-2026-13602","datePublished":"2026-07-01T13:45:30.615Z","dateReserved":"2026-06-29T08:26:50.725Z","dateUpdated":"2026-07-01T15:27:00.431Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-01 15:16:29","lastModifiedDate":"2026-07-02 18:43:45","problem_types":["CWE-20","CWE-323","CWE-20 CWE-20 Improper input validation","CWE-323 CWE-323 Reusing a nonce, key pair in encryption"],"metrics":{"cvssMetricV40":[{"source":"655498c3-6ec5-4f0b-aea6-853b334d05a6","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":7.7,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"HIGH","exploitMaturity":"UNREPORTED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-07-01T15:26:54.400278Z","id":"CVE-2026-13602","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"13602","Ordinal":"1","Title":"Session takeover vulnerability","CVE":"CVE-2026-13602","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"13602","Ordinal":"1","NoteData":"We found a chain of combining multiple weaknesses in the product that could allow an attacker to become any user in the backend and access any data:\n\n\n\n\n\n\n\n * \n\n\nThe payment integration plugins Stripe (included in the core system), pretix-mollie, pretix-oppwa, pretix-bitpay, pretix-payone, pretix-secuconnect, pretix-sofort, and pretix-saferpay\n contain a code path that is intended for the transport of session \nparameters from a tab with isolated cookies (e.g. in the pretix widget) \nto a new tab. For this purpose, a set of session parameters is \ncryptographically signed and then passed to the new tab as a URL \nparameter. The plugins perform no further validation of the session \nparameters, other than the cryptographic signature being valid. This is \nfixed with the releases issued today by strictly validating that no \nsession parameters outside of the scope of the respective plugin may be \nset.\n\n\n\n\n * \n\n\nAn unrelated feature in the core system is used to generate redirect links that obfuscate any Referer\n headers for outgoing links to prevent leakage of secrets in URLs. This \nredirect page also requires cryptographically signed parameters. \nUnfortunately, it uses the same key and salt for the signature as the \npreviously mentioned feature in the payment integration plugins. A \nmotivated attacker with access to at least one event in the backend can \ntrick the system into cryptographically signing arbitrary content using \nspecially crafted links. In combination with the previous issue, the \nattacker could use this to set and modify arbitrary parameters on their \nuser session by injecting the signed parameters into the feature of the \npayment providers. This is fixed with the releases issued today by using\n different salts for the signature for each plugin and feature.\n\n\n\n\n * \n\n\nA third, unrelated feature in the core system is used for admin users\n to act on behalf of another user, mostly for debugging purposes. With \nbeing able to insert arbitrary parameters into a session, an attacker \ncan abuse this feature to change their session from their actual user to\n any user in the system by guessing a valid user ID. This is fixed with\n the release today by requiring unguessable information to be contained \nin the session of the user to switch to.","Type":"Description","Title":"Session takeover vulnerability"}]}}}