<?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://vulnerability.circl.lu</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, 05 Oct 2026 16:38:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-46715 — Flask-Security-Too OAuth reauthentication freshness bypass via cross- user OAuth identity acceptance</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-46715</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; pallets-eco Flask-Security-Too&lt;/p&gt;
&lt;p&gt;Flask-Security-Too allows users to add security features to their Flask applicationa. Version 5.8.0&amp;#39;s OAuth reauthentication flow can mark a session as fresh after verifying an OAuth account that belongs to a different user. If an attacker can operate an already-authenticated but stale victim session, they can complete OAuth verification using their own OAuth identity. The victim session is then treated as recently reauthenticated, allowing freshness-protected account actions to proceed. Version 5.8.1 contains a fix for this issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; pallets-eco Flask-Security-Too&lt;/p&gt;
&lt;p&gt;Flask-Security-Too allows users to add security features to their Flask applicationa. Version 5.8.0&amp;#39;s OAuth reauthentication flow can mark a session as fresh after verifying an OAuth account that belongs to a different user. If an attacker can operate an already-authenticated but stale victim session, they can complete OAuth verification using their own OAuth identity. The victim session is then treated as recently reauthenticated, allowing freshness-protected account actions to proceed. Version 5.8.1 contains a fix for this issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-46715</guid>
    </item>
    <item>
      <title>GHSA-97r5-pg8x-p63p — Flask-Security-Too OAuth reauthentication freshness bypass via cross-   user OAuth identity acceptance</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-97r5-pg8x-p63p</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Flask-Security-Too&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Flask-Security-Too 5.8.0&amp;#39;s OAuth reauthentication flow can mark a
  session as fresh after verifying an OAuth account that belongs to a
  different user.&lt;/p&gt;
&lt;p&gt;If an attacker can operate an already-authenticated but stale victim
  session, they can complete OAuth verification using their own OAuth
  identity. The victim session is then treated as recently
  reauthenticated, allowing freshness-protected account actions to
  proceed. This was reproduced against the built-in `/change-username`
  route.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The issue is in the OAuth verification callback.&lt;/p&gt;
&lt;p&gt;`_oauth_response_common()` resolves the OAuth provider identity to a
  Flask-Security user:&lt;/p&gt;
&lt;p&gt;- `flask_security/oauth_glue.py:101-108`&lt;/p&gt;
&lt;p&gt;`oauth_verify_response()` then accepts any resolved user and updates
  the current session freshness timestamp:&lt;/p&gt;
&lt;p&gt;- `flask_security/oauth_glue.py:182-214`
  - `flask_security/oauth_glue.py:201-204`&lt;/p&gt;
&lt;p&gt;The missing check is that the OAuth-resolved user must match the
  current authenticated session user. In the failing case:&lt;/p&gt;
&lt;p&gt;- current session user: `victim@example.com`
  - OAuth verified user: `attacker@example.com`
  - session marked fresh: yes&lt;/p&gt;
&lt;p&gt;So the attacker is not logging in as the victim, but they are
  satisfying the victim session&amp;#39;s reauthentication requirement with a
  different account.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;Tested version:&lt;/p&gt;
&lt;p&gt;- `Flask-Security-Too 5.8.0`
  - tag `5.8.0`
  - commit `08288dff6907e413d848a16aaf43fc2c2b2a3b72`&lt;/p&gt;
&lt;p&gt;Used a minimal Flask app with:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Flask-Security-Too&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Flask-Security-Too 5.8.0&amp;#39;s OAuth reauthentication flow can mark a
  session as fresh after verifying an OAuth account that belongs to a
  different user.&lt;/p&gt;
&lt;p&gt;If an attacker can operate an already-authenticated but stale victim
  session, they can complete OAuth verification using their own OAuth
  identity. The victim session is then treated as recently
  reauthenticated, allowing freshness-protected account actions to
  proceed. This was reproduced against the built-in `/change-username`
  route.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The issue is in the OAuth verification callback.&lt;/p&gt;
&lt;p&gt;`_oauth_response_common()` resolves the OAuth provider identity to a
  Flask-Security user:&lt;/p&gt;
&lt;p&gt;- `flask_security/oauth_glue.py:101-108`&lt;/p&gt;
&lt;p&gt;`oauth_verify_response()` then accepts any resolved user and updates
  the current session freshness timestamp:&lt;/p&gt;
&lt;p&gt;- `flask_security/oauth_glue.py:182-214`
  - `flask_security/oauth_glue.py:201-204`&lt;/p&gt;
&lt;p&gt;The missing check is that the OAuth-resolved user must match the
  current authenticated session user. In the failing case:&lt;/p&gt;
&lt;p&gt;- current session user: `victim@example.com`
  - OAuth verified user: `attacker@example.com`
  - session marked fresh: yes&lt;/p&gt;
&lt;p&gt;So the attacker is not logging in as the victim, but they are
  satisfying the victim session&amp;#39;s reauthentication requirement with a
  different account.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;Tested version:&lt;/p&gt;
&lt;p&gt;- `Flask-Security-Too 5.8.0`
  - tag `5.8.0`
  - commit `08288dff6907e413d848a16aaf43fc2c2b2a3b72`&lt;/p&gt;
&lt;p&gt;Used a minimal Flask app with:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-97r5-pg8x-p63p</guid>
    </item>
  </channel>
</rss>
