<?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>Mon, 12 Oct 2026 20:13:22 +0000</lastBuildDate>
    <item>
      <title>BIT-parse-2026-30967 — Parse Server OAuth2 authentication adapter account takeover via identity spoofing</title>
      <link>https://cve.radiocsirt.org/vuln/bit-parse-2026-30967</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: parse&lt;/p&gt;
&lt;p&gt;Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2. and 8.6.22, the OAuth2 authentication adapter, when configured without the useridField option, only verifies that a token is active via the provider&amp;#39;s token introspection endpoint, but does not verify that the token belongs to the user identified by authData.id. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user. This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with oauth2: true) without setting the useridField option. This vulnerability is fixed in 9.5.2. and 8.6.22.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: parse&lt;/p&gt;
&lt;p&gt;Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2. and 8.6.22, the OAuth2 authentication adapter, when configured without the useridField option, only verifies that a token is active via the provider&amp;#39;s token introspection endpoint, but does not verify that the token belongs to the user identified by authData.id. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user. This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with oauth2: true) without setting the useridField option. This vulnerability is fixed in 9.5.2. and 8.6.22.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bit-parse-2026-30967</guid>
    </item>
    <item>
      <title>EUVD-2026-275514</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-275514</link>
      <description>EUVD-2026-275514</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-275514</guid>
    </item>
    <item>
      <title>fkie_cve-2026-30967</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-30967</link>
      <description>&lt;p&gt;Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2-alpha.9. and 8.6.22, the OAuth2 authentication adapter, when configured without the useridField option, only verifies that a token is active via the provider&amp;#39;s token introspection endpoint, but does not verify that the token belongs to the user identified by authData.id. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user. This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with oauth2: true) without setting the useridField option. This vulnerability is fixed in 9.5.2-alpha.9. and 8.6.22.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2-alpha.9. and 8.6.22, the OAuth2 authentication adapter, when configured without the useridField option, only verifies that a token is active via the provider&amp;#39;s token introspection endpoint, but does not verify that the token belongs to the user identified by authData.id. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user. This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with oauth2: true) without setting the useridField option. This vulnerability is fixed in 9.5.2-alpha.9. and 8.6.22.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-30967</guid>
    </item>
    <item>
      <title>GHSA-fr88-w35c-r596 — Parse Server OAuth2 authentication adapter account takeover via identity spoofing</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-fr88-w35c-r596</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: parse-server&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The OAuth2 authentication adapter, when configured without the `useridField` option, only verifies that a token is active via the provider&amp;#39;s token introspection endpoint, but does not verify that the token belongs to the user identified by `authData.id`. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user.&lt;/p&gt;
&lt;p&gt;This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with `oauth2: true`) without setting the `useridField` option.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The vulnerability is fixed by defaulting `useridField` to `sub`, which is the standard subject identifier field defined by [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662). The adapter now always validates the token&amp;#39;s identity against the claimed user ID, even when `useridField` is not explicitly configured.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Set the `useridField` option to the appropriate field name for your OAuth2 provider (e.g. `sub`) in the Parse Server authentication configuration.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-fr88-w35c-r596
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.22&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: parse-server&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The OAuth2 authentication adapter, when configured without the `useridField` option, only verifies that a token is active via the provider&amp;#39;s token introspection endpoint, but does not verify that the token belongs to the user identified by `authData.id`. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user.&lt;/p&gt;
&lt;p&gt;This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with `oauth2: true`) without setting the `useridField` option.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The vulnerability is fixed by defaulting `useridField` to `sub`, which is the standard subject identifier field defined by [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662). The adapter now always validates the token&amp;#39;s identity against the claimed user ID, even when `useridField` is not explicitly configured.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Set the `useridField` option to the appropriate field name for your OAuth2 provider (e.g. `sub`) in the Parse Server authentication configuration.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-fr88-w35c-r596
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.22&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-fr88-w35c-r596</guid>
    </item>
  </channel>
</rss>
