| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| A new API endpoint introduced in pretix 2025 that is supposed to
return all check-in events of a specific event in fact returns all
check-in events belonging to the respective organizer. This allows an
API consumer to access information for all other events under the same
organizer, even those they should not have access to.
These records contain information on the time and result of every ticket scan as well as the ID of the matched ticket. Example:
{
"id": 123,
"successful": true,
"error_reason": null,
"error_explanation": null,
"position": 321,
"datetime": "2020-08-23T09:00:00+02:00",
"list": 456,
"created": "2020-08-23T09:00:00+02:00",
"auto_checked_in": false,
"gate": null,
"device": 1,
"device_id": 1,
"type": "entry"
}
An unauthorized user usually has no way to match these IDs (position) back to individual people. |
| Emails sent by pretix can utilize placeholders that will be filled with customer data. For example, when {name}
is used in an email template, it will be replaced with the buyer's
name for the final email. This mechanism contained two security-relevant
bugs:
*
It was possible to exfiltrate information about the pretix system through specially crafted placeholder names such as {{event.__init__.__code__.co_filename}}.
This way, an attacker with the ability to control email templates
(usually every user of the pretix backend) could retrieve sensitive
information from the system configuration, including even database
passwords or API keys. pretix does include mechanisms to prevent the usage of such
malicious placeholders, however due to a mistake in the code, they were
not fully effective for the email subject.
*
Placeholders in subjects and plain text bodies of emails were
wrongfully evaluated twice. Therefore, if the first evaluation of a
placeholder again contains a placeholder, this second placeholder was
rendered. This allows the rendering of placeholders controlled by the
ticket buyer, and therefore the exploitation of the first issue as a
ticket buyer. Luckily, the only buyer-controlled placeholder available
in pretix by default (that is not validated in a way that prevents the
issue) is {invoice_company}, which is very unusual (but not
impossible) to be contained in an email subject template. In addition
to broadening the attack surface of the first issue, this could
theoretically also leak information about an order to one of the
attendees within that order. However, we also consider this scenario
very unlikely under typical conditions.
Out of caution, we recommend that you rotate all passwords and API keys contained in your pretix.cfg https://docs.pretix.eu/self-hosting/config/ file. |
| Emails sent by pretix can utilize placeholders that will be filled with customer data. For example, when {name}
is used in an email template, it will be replaced with the buyer's
name for the final email. This mechanism contained a security-relevant bug:
It was possible to exfiltrate information about the pretix system through specially crafted placeholder names such as {{event.__init__.__code__.co_filename}}.
This way, an attacker with the ability to control email templates
(usually every user of the pretix backend) could retrieve sensitive
information from the system configuration, including even database
passwords or API keys. pretix does include mechanisms to prevent the usage of such
malicious placeholders, however due to a mistake in the code, they were
not fully effective for this plugin.
Out of caution, we recommend that you rotate all passwords and API keys contained in your pretix.cfg file. |
| Emails sent by pretix can utilize placeholders that will be filled with customer data. For example, when {name}
is used in an email template, it will be replaced with the buyer's
name for the final email. This mechanism contained a security-relevant bug:
It was possible to exfiltrate information about the pretix system through specially crafted placeholder names such as {{event.__init__.__code__.co_filename}}.
This way, an attacker with the ability to control email templates
(usually every user of the pretix backend) could retrieve sensitive
information from the system configuration, including even database
passwords or API keys. pretix does include mechanisms to prevent the usage of such
malicious placeholders, however due to a mistake in the code, they were
not fully effective for this plugin.
Out of caution, we recommend that you rotate all passwords and API keys contained in your pretix.cfg https://docs.pretix.eu/self-hosting/config/ file. |
| Multiple API endpoints allowed access to sensitive files from other users by knowing the UUID of the file that were not intended to be accessible by UUID only. |
| An API endpoint allowed access to sensitive files from other users by knowing the UUID of the file that were not intended to be accessible by UUID only. |
| Emails sent by pretix can utilize placeholders that will be filled with customer data. For example, when {name} is used in an email template, it will be replaced with the buyer's name for the final email. If the name of the attendee contained HTML or Markdown formatting, this was rendered as HTML in the resulting email. This way, a user could inject links or other formatted text through a maliciously formatted name. Since pretix applies a strict allow list approach to allowed HTML tags, this could not be abused for XSS or similarly dangerous attack chains. However, it can be used to manipulate emails in a way that makes user-provided content appear in a trustworthy and credible way, which can be abused for phishing. |
| pretix before 2024.1.1 mishandles file validation. |
