<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 08:05:17 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-318012</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-318012</link>
      <description>EUVD-2026-318012</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-318012</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43983</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43983</link>
      <description>&lt;p&gt;Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to your services. Prior to 2.6.0, The createTokenFromRefreshToken function (oidc_service.go) validates the refresh token&amp;#39;s cryptographic integrity but does not re-validate the user&amp;#39;s current authorization state before issuing new tokens. This allows (1) the client to refresh the token indefinitely after authorization revocation, (2) the refresh token to continue to work after the account is disabled, and (3) the token to work after the client is removed from the group. This vulnerability is fixed in 2.6.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to your services. Prior to 2.6.0, The createTokenFromRefreshToken function (oidc_service.go) validates the refresh token&amp;#39;s cryptographic integrity but does not re-validate the user&amp;#39;s current authorization state before issuing new tokens. This allows (1) the client to refresh the token indefinitely after authorization revocation, (2) the refresh token to continue to work after the account is disabled, and (3) the token to work after the client is removed from the group. This vulnerability is fixed in 2.6.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43983</guid>
    </item>
    <item>
      <title>GHSA-w6p7-2fxx-4f44 — Pocket ID: OIDC refresh token flow bypasses authorization revocation, account disabling, and group restrictions</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-w6p7-2fxx-4f44</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/pocket-id/pocket-id/backend&lt;/p&gt;
&lt;p&gt;# OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group Restrictions&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The `createTokenFromRefreshToken` function (oidc_service.go:451) validates the refresh token&amp;#39;s cryptographic integrity but does not re-validate the user&amp;#39;s current authorization state before issuing new tokens. This allows three bypasses:&lt;/p&gt;
&lt;p&gt;1. **Authorization revocation bypass**: After a user revokes an OIDC client&amp;#39;s authorization, the client can continue refreshing tokens indefinitely because `RevokeAuthorizedClient` does not delete associated refresh tokens, and the refresh flow does not check if the authorization record still exists.&lt;/p&gt;
&lt;p&gt;2. **Disabled user bypass**: After an admin disables a user account, pre-existing refresh tokens continue to work because the OIDC token endpoint does not check `user.Disabled`. Session-based access is properly blocked by auth middleware, but the OIDC refresh path bypasses it entirely.&lt;/p&gt;
&lt;p&gt;3. **Group restriction bypass**: After removing a user from an OIDC client&amp;#39;s allowed user groups, the refresh token continues to work because `createTokenFromRefreshToken` does not call `IsUserGroupAllowedToAuthorize`.&lt;/p&gt;
&lt;p&gt;Each refresh rotates the token with a fresh 30-day expiry, enabling perpetual access.&lt;/p&gt;
&lt;p&gt;## Target&lt;/p&gt;
&lt;p&gt;- **Repository**: pocket-id/pocket-id
- **Version**: HEAD (626adbf), also affects v2.5.0 and all versions with refresh token support&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;`createTokenFromRefreshToken` (oidc_service.go:451-547) performs the following checks…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/pocket-id/pocket-id/backend&lt;/p&gt;
&lt;p&gt;# OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group Restrictions&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The `createTokenFromRefreshToken` function (oidc_service.go:451) validates the refresh token&amp;#39;s cryptographic integrity but does not re-validate the user&amp;#39;s current authorization state before issuing new tokens. This allows three bypasses:&lt;/p&gt;
&lt;p&gt;1. **Authorization revocation bypass**: After a user revokes an OIDC client&amp;#39;s authorization, the client can continue refreshing tokens indefinitely because `RevokeAuthorizedClient` does not delete associated refresh tokens, and the refresh flow does not check if the authorization record still exists.&lt;/p&gt;
&lt;p&gt;2. **Disabled user bypass**: After an admin disables a user account, pre-existing refresh tokens continue to work because the OIDC token endpoint does not check `user.Disabled`. Session-based access is properly blocked by auth middleware, but the OIDC refresh path bypasses it entirely.&lt;/p&gt;
&lt;p&gt;3. **Group restriction bypass**: After removing a user from an OIDC client&amp;#39;s allowed user groups, the refresh token continues to work because `createTokenFromRefreshToken` does not call `IsUserGroupAllowedToAuthorize`.&lt;/p&gt;
&lt;p&gt;Each refresh rotates the token with a fresh 30-day expiry, enabling perpetual access.&lt;/p&gt;
&lt;p&gt;## Target&lt;/p&gt;
&lt;p&gt;- **Repository**: pocket-id/pocket-id
- **Version**: HEAD (626adbf), also affects v2.5.0 and all versions with refresh token support&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;`createTokenFromRefreshToken` (oidc_service.go:451-547) performs the following checks…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-w6p7-2fxx-4f44</guid>
    </item>
  </channel>
</rss>
