<?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-04T23:46:54.777362+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-64521</id>
    <title>BIT-authentik-2025-64521 — authentik deactivated service accounts can authenticate to OAuth</title>
    <updated>2026-10-04T23:46:54.780228+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, when authenticating with client_id and client_secret to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves adding a policy to the application that explicitly checks if the service account is still valid, and deny access if not.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bit-authentik-2025-64521"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-261350</id>
    <title>EUVD-2026-261350</title>
    <updated>2026-10-04T23:46:54.780276+00:00</updated>
    <content>EUVD-2026-261350</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-261350"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-64521</id>
    <title>fkie_cve-2025-64521</title>
    <updated>2026-10-04T23:46:54.780291+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, when authenticating with client_id and client_secret to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves adding a policy to the application that explicitly checks if the service account is still valid, and deny access if not.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-64521"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-xr73-jq5p-ch8r</id>
    <title>GHSA-xr73-jq5p-ch8r — authentik allows a deactivated Service account to authenticate to OAuth</title>
    <updated>2026-10-04T23:46:54.780315+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>When authenticating with `client_id` and `client_secret` to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account.</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>You can add a policy to your application that explicitly checks if the service account is still valid, and deny access if not.</p>
<p>```python
return request.user.is_active
```</p>
<p>### For more information</p>
<p>If you have any questions or comments about this advisory:</p>
<p>- Email us at [security@goauthentik.io](mailto:security@goauthentik.io).</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-xr73-jq5p-ch8r"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2025-237</id>
    <title>PYSEC-2025-237</title>
    <updated>2026-10-04T23:46:54.780344+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: authentik-client</p>
<p>authentik is an open-source Identity Provider. Prior to versions 2025.8.5 and 2025.10.2, when authenticating with client_id and client_secret to an OAuth provider, authentik creates a service account for the provider. In previous authentik versions, authentication for this account was possible even when the account was deactivated. Other permissions are correctly applied and federation with other providers still take assigned policies correctly into account. authentik versions 2025.8.5 and 2025.10.2 fix this issue. A workaround involves adding a policy to the application that explicitly checks if the service account is still valid, and deny access if not.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2025-237"/>
  </entry>
</feed>
