<?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-06T22:30:08.675787+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/bit-authentik-2025-64708</id>
    <title>BIT-authentik-2025-64708 — authentik invitation expiry is delayed by at least 5 minutes</title>
    <updated>2026-10-06T22:30:08.695029+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Bitnami: authentik</p>
<p>authentik is an open-source Identity Provider. Prior to versions 2025.8.5 and 2025.10.2, in previous authentik versions, invitations were considered valid regardless if they are expired or not, thus relying on background tasks to clean up expired ones. In a normal scenario this can take up to 5 minutes because the cleanup of expired objects is scheduled to run every 5 minutes. However, with a large amount of tasks in the backlog, this might take longer. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves creating a policy that explicitly checks whether the invitation is still valid, and then bind it to the invitation stage on the invitation flow, and denying access if the invitation is not valid.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bit-authentik-2025-64708"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-261460</id>
    <title>EUVD-2026-261460</title>
    <updated>2026-10-06T22:30:08.695087+00:00</updated>
    <content>EUVD-2026-261460</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-261460"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-64708</id>
    <title>fkie_cve-2025-64708</title>
    <updated>2026-10-06T22:30:08.695104+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>authentik is an open-source Identity Provider. Prior to versions 2025.8.5 and 2025.10.2, in previous authentik versions, invitations were considered valid regardless if they are expired or not, thus relying on background tasks to clean up expired ones. In a normal scenario this can take up to 5 minutes because the cleanup of expired objects is scheduled to run every 5 minutes. However, with a large amount of tasks in the backlog, this might take longer. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves creating a policy that explicitly checks whether the invitation is still valid, and then bind it to the invitation stage on the invitation flow, and denying access if the invitation is not valid.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-64708"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-ch7q-53v8-73pc</id>
    <title>GHSA-ch7q-53v8-73pc — authentik's invitation expiry is delayed by at least 5 minutes</title>
    <updated>2026-10-06T22:30:08.695129+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: goauthentik.io</p>
<p>### Summary</p>
<p>In previous authentik versions, invitations were considered valid regardless if they are expired or not, thus relying on background tasks to clean up expired ones. In a normal scenario this can take up to 5 minutes because the cleanup of expired objects is scheduled to run every 5 minutes. However, with a large amount of tasks in the backlog, this might take longer.</p>
<p>### Patches</p>
<p>authentik 2025.8.5 and 2025.10.2 fix this issue; for other versions the workaround below can be used.</p>
<p>### Workarounds</p>
<p>Users can create a policy that explicitly checks whether the invitation is still valid, and then bind it to the invitation stage on your invitation flow, and deny access if the invitation is not valid.</p>
<p>```python
return not context['flow_plan'].context['invitation'].is_expired
```</p>
<p>### For more information</p>
<p>If users have any questions or comments about this advisory:</p>
<p>- Email the authentik team at [security@goauthentik.io](mailto:security@goauthentik.io).</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-ch7q-53v8-73pc"/>
  </entry>
</feed>
