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: * 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 contain a code path that is intended for the transport of session parameters from a tab with isolated cookies (e.g. in the pretix widget) to a new tab. For this purpose, a set of session parameters is cryptographically signed and then passed to the new tab as a URL parameter. The plugins perform no further validation of the session parameters, other than the cryptographic signature being valid. This is fixed with the releases issued today by strictly validating that no session parameters outside of the scope of the respective plugin may be set. * An unrelated feature in the core system is used to generate redirect links that obfuscate any Referer headers for outgoing links to prevent leakage of secrets in URLs. This redirect page also requires cryptographically signed parameters. Unfortunately, it uses the same key and salt for the signature as the previously mentioned feature in the payment integration plugins. A motivated attacker with access to at least one event in the backend can trick the system into cryptographically signing arbitrary content using specially crafted links. In combination with the previous issue, the attacker could use this to set and modify arbitrary parameters on their user session by injecting the signed parameters into the feature of the payment providers. This is fixed with the releases issued today by using different salts for the signature for each plugin and feature. * A third, unrelated feature in the core system is used for admin users to act on behalf of another user, mostly for debugging purposes. With being able to insert arbitrary parameters into a session, an attacker can abuse this feature to change their session from their actual user to any user in the system by guessing a valid user ID. This is fixed with the release today by requiring unguessable information to be contained in the session of the user to switch to.

Malicious HTML content could be injected into the email address of an order, which pretix showed without sanitization on the confirmation page for individual tickets in that order.

Content injected to PDF rendering contexts could, in many places, include HTML content including <img> tags. If the src attribute of these images pointed to an URL, the PDF rendering engine would download the image from that place and display it, thereby leaking information about the rendering server and possibly creating an SSRF vector in the local network.

Malicious HTML content could be injected into the page pretix shows when redirection to an untrusted page occurs. Since this page has a Content-Security-Policy, this can mainly be used for phishing purposes.

Malicious HTML content contained in the layout specification of a PDF ticket or badge layout was executed when the PDF editor is opened in the browser. This could allow one backend user to inject JavaScript into the browser context of another backend user. Due to requirements of the PDF rendering and editing libraries used, this is one of the few pages in our backend that do not have a strong Content-Security-Policy that would render this capability useless for most scenarios.

When creating an export of all reusable media, the secrets of connected gift cards were included in the export even if the user creating the export does not have permission to view gift cards. This is inconsistent with the UI and API where only the first letters of the gift card secret are shown. Therefore, it allows circumventing a permission boundary.

When creating an export through the pretix API, API clients are returned an UUID value for their export job (a long, random string like 35742818-c375-4d15-839f-d49aecce94d6). Using this UUID, the API client can then request the actual file for download. The same kind of UUID is used in other places in pretix when temporary files are generated for internal use or download. One remaining API endpoint, however, wrongfully did not verify if the UUID used for download actually belongs to a file that is supposed to be downloadable and belongs to the correct user. In reality, this is hard to exploit because an attacker would need to have access to a valid UUID for the file they desire which is unlikely to happen without a separate security problem giving them access to logs etc.