| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A logic flaw in the checkout flow allows users to bypass validations performed during the check-in by skipping entire check-in steps. |
| A missing permission check allowed low-privileged users with access to an event but without access to the event's orders to extract some specific information. This information includes the number of attendees and the total revenue. |
| If an attacker is able to convince a victim on a specially crafted link, the victim is logged in to the attacker's customer account. If the victim does not notice this, this might lead to their order details being stored into the attacker's account. The attack only works when the event is available on a different domain than the organizer page. |
| The mechanism binding API-uploaded files to the uploader's authentication method is not working correctly and the same session token is used for all token-based API users. Since API-uploaded files are refered to by randomly generated UUIDs and only exist for a day, there is virtually no risk, but it renders the added protection mechanism useless. |
| Malicious HTML content could be injected into the help texts of various fields with organizer permissions. |
| OAuth credentials (access tokens) are valid for the entirety of their lifetime, even if the application (OAuth client) they are bound to is manually disabled. |
| The default docker image shipped for Venueless did not properly ensure that uploaded SVG files could not be delivered with executable JavaScript content. A valid Content Security Policy is now set. |
| 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. |
| The "quick setup" view presented to users after they first create an
event allows to set up the most critical parts of an event in just a few
clicks. This view did not properly check that the user has permission
to change configuration for the given event. An attacker could use a
well-timed request to create products, quotas, set bank transfer
configuration, or connect a stripe account to an event they do not have
access to. |
| The payment integration pretix-oppwa provides support
for the payment providers VR Payment, Hobex, and potentially others
based on Oppwa's technology. The integration of Oppwa, following their
official documentation, includes a step where the user is redirected
from the payment provider back to our system with a query parameter like
?resourcePath=/v1/checkouts/{checkoutId}/payment in the URL. Our system is then supposed to fetch the status of the transaction from the URL given by baseUrl + resourcePath.
Our plugin pretix-oppwa did so insecurely by
concatenating the parameter form the URL to the base domain of the API
without further validation and, critically, without a / at the end of the baseUrl. Therefore, an attacker could inject a resourcePath argument in a way that causes pretix to call a different
server instead. Since the request includes the access token (API key)
of the Oppwa account, this would leak the access token, giving access to
data contained in the payment provider's system. This is fixed with the
release today by strictly validating the given API URL.
After installing the update, we recommend asking your payment provider for a new access token and updating it in pretix. |
| Malicious HTML content could be injected into the content rendered by the pretix-digital plugin. |
| Our payment integration with Computop-based payment methods did not
properly validate payment status responses. An attacker could use a
successful payment status response from one payment and supply it to the
system for a different payment, gaining access to multiple valid
tickets with only one payment. |
| Our payment integration with Oppwa-based payment methods did not
properly validate payment status responses. An attacker could use a
successful payment status response from one payment and supply it to the
system for a different payment, gaining access to multiple valid
tickets with only one payment. |
| Our payment integration with Mollie did not properly validate payment
status responses. An attacker could use a successful payment status
response from one payment and supply it to the system for a different
payment, gaining access to multiple valid tickets with only one payment. |
| Malicious HTML content could be injected into the content of a page in the pretix-pages plugin. |
| 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. |
| 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. |
| Permissions where checked incorrectly during room creation, allowing attackers to create rooms of types they shouldn't be allowed to create. |
