<?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 11:57:49 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-317429</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-317429</link>
      <description>EUVD-2026-317429</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-317429</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44166</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44166</link>
      <description>&lt;p&gt;Pocketbase is an open source web backend written in go. Prior to 0.22.42 and 0.37.4, in some situations, if an attacker knows the email address of the victim they can create and link an unverified PocketBase user in advance by authenticating with one of the OAuth2 app providers, e.g. &amp;#34;A&amp;#34;. When the victim gets invited or decides to sign up to your app on their own with provider &amp;#34;B&amp;#34; (PocketBase OAuth2 auth requires to be with a different provider because we don&amp;#39;t allow multiple OAuth2 accounts from the same provider to be associated to a single PocketBase user), the user created previously by the attacker will be autolinked, upgraded to &amp;#34;verified&amp;#34; and its old password reset. This vulnerability is fixed in 0.22.42 and 0.37.4.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Pocketbase is an open source web backend written in go. Prior to 0.22.42 and 0.37.4, in some situations, if an attacker knows the email address of the victim they can create and link an unverified PocketBase user in advance by authenticating with one of the OAuth2 app providers, e.g. &amp;#34;A&amp;#34;. When the victim gets invited or decides to sign up to your app on their own with provider &amp;#34;B&amp;#34; (PocketBase OAuth2 auth requires to be with a different provider because we don&amp;#39;t allow multiple OAuth2 accounts from the same provider to be associated to a single PocketBase user), the user created previously by the attacker will be autolinked, upgraded to &amp;#34;verified&amp;#34; and its old password reset. This vulnerability is fixed in 0.22.42 and 0.37.4.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44166</guid>
    </item>
    <item>
      <title>GHSA-pq7p-mc74-g65w — PocketBase vulnerable to account pre-hijacking via OAuth2 unverfied-&gt;verified autolinking upgrade</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pq7p-mc74-g65w</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/pocketbase/pocketbase&lt;/p&gt;
&lt;p&gt;A pre-hijacking issue was discovered with the OAuth2 autolinking by [Alardiians](https://github.com/Alardiians).&lt;/p&gt;
&lt;p&gt;In some situations, if an attacker knows the email address of the victim they can create and link an **unverified** PocketBase user in advance by authenticating with one of the OAuth2 app providers, e.g. &amp;#34;A&amp;#34;. When the victim gets invited or decides to sign up to your app on their own with provider &amp;#34;B&amp;#34; _(PocketBase OAuth2 auth requires to be with a different provider because we don&amp;#39;t allow multiple OAuth2 accounts from the same provider to be associated to a single PocketBase user)_, the user created previously by the attacker will be autolinked, upgraded to **&amp;#34;verified&amp;#34;** and its old password reset.&lt;/p&gt;
&lt;p&gt;The upgrade flow operates within the expectations but the problem is that I forgot to clear the previous OAuth2 link(s) leaving the attacker to still have access to the initially created user.&lt;/p&gt;
&lt;p&gt;Or in other words, the vulnerability is similar to the [mixed password + OAuth2 auth pre-hijacking issue](https://github.com/pocketbase/pocketbase/security/advisories/GHSA-m93w-4fxv-r35v) that we had in the past but with a slightly different angle.&lt;/p&gt;
&lt;p&gt;So with that in mind, and to avoid introducing breaking changes to the auth flows, a new fix was applied that automatically deletes all such pre-existing OAuth2 links on &amp;#34;unverified&amp;#34; to &amp;#34;verified&amp;#34; upgrades.&lt;/p&gt;
&lt;p&gt;**While the vulnerability requires some prerequisites, it is considered severe and it is strongly recommended to upgrade to v…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/pocketbase/pocketbase&lt;/p&gt;
&lt;p&gt;A pre-hijacking issue was discovered with the OAuth2 autolinking by [Alardiians](https://github.com/Alardiians).&lt;/p&gt;
&lt;p&gt;In some situations, if an attacker knows the email address of the victim they can create and link an **unverified** PocketBase user in advance by authenticating with one of the OAuth2 app providers, e.g. &amp;#34;A&amp;#34;. When the victim gets invited or decides to sign up to your app on their own with provider &amp;#34;B&amp;#34; _(PocketBase OAuth2 auth requires to be with a different provider because we don&amp;#39;t allow multiple OAuth2 accounts from the same provider to be associated to a single PocketBase user)_, the user created previously by the attacker will be autolinked, upgraded to **&amp;#34;verified&amp;#34;** and its old password reset.&lt;/p&gt;
&lt;p&gt;The upgrade flow operates within the expectations but the problem is that I forgot to clear the previous OAuth2 link(s) leaving the attacker to still have access to the initially created user.&lt;/p&gt;
&lt;p&gt;Or in other words, the vulnerability is similar to the [mixed password + OAuth2 auth pre-hijacking issue](https://github.com/pocketbase/pocketbase/security/advisories/GHSA-m93w-4fxv-r35v) that we had in the past but with a slightly different angle.&lt;/p&gt;
&lt;p&gt;So with that in mind, and to avoid introducing breaking changes to the auth flows, a new fix was applied that automatically deletes all such pre-existing OAuth2 links on &amp;#34;unverified&amp;#34; to &amp;#34;verified&amp;#34; upgrades.&lt;/p&gt;
&lt;p&gt;**While the vulnerability requires some prerequisites, it is considered severe and it is strongly recommended to upgrade to v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pq7p-mc74-g65w</guid>
    </item>
  </channel>
</rss>
