<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T11:57:36.308484+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-268733</id>
    <title>EUVD-2026-268733</title>
    <updated>2026-10-03T11:57:36.312729+00:00</updated>
    <content>EUVD-2026-268733</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-268733"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-2415</id>
    <title>fkie_cve-2026-2415</title>
    <updated>2026-10-03T11:57:36.312759+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>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:</p>
<p>*  
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.</p>
<p>*  
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 o…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-2415"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-r8p8-qw9w-j9qv</id>
    <title>GHSA-r8p8-qw9w-j9qv — pretix unsafely evaluates variables in emails</title>
    <updated>2026-10-03T11:57:36.312808+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: pretix</p>
<p>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:</p>
<p>-  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.</p>
<p>-  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, thi…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-r8p8-qw9w-j9qv"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-110</id>
    <title>PYSEC-2026-110</title>
    <updated>2026-10-03T11:57:36.312849+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: pretix</p>
<p>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:</p>
<p>*  
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.</p>
<p>*  
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 o…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-110"/>
  </entry>
</feed>
