Emails sent by pretix can utilize placeholders that will be filled with customer data. For example, when {name}\n is used in an email template, it will be replaced with the buyer's \nname for the final email. This mechanism contained two security-relevant\n bugs:
It was possible to exfiltrate information about the pretix system through specially crafted placeholder names such as {{event.__init__.__code__.co_filename}}.\n This way, an attacker with the ability to control email templates \n(usually every user of the pretix backend) could retrieve sensitive \ninformation from the system configuration, including even database \npasswords or API keys. pretix does include mechanisms to prevent the usage of such \nmalicious placeholders, however due to a mistake in the code, they were \nnot fully effective for the email subject.
Placeholders in subjects and plain text bodies of emails were \nwrongfully evaluated twice. Therefore, if the first evaluation of a \nplaceholder again contains a placeholder, this second placeholder was \nrendered. This allows the rendering of placeholders controlled by the \nticket buyer, and therefore the exploitation of the first issue as a \nticket buyer. Luckily, the only buyer-controlled placeholder available \nin pretix by default (that is not validated in a way that prevents the \nissue) is {invoice_company}, which is very unusual (but not\n impossible) to be contained in an email subject template. In addition \nto broadening the attack surface of the first issue, this could \ntheoretically also leak information about an order to one of the \nattendees within that order. However, we also consider this scenario \nvery unlikely under typical conditions.