<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>EduMFA (&lt; 2.9.1) — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/edumfa--2.9.1/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Mon, 18 May 2026 15:37:43 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/edumfa--2.9.1/feed.xml" rel="self" type="application/rss+xml"/><item><title>eduMFA Token Reusage Vulnerability due to Incorrect InnoDB Snapshot Isolation</title><link>https://feed.craftedsignal.io/briefs/2026-05-edumfa-token-reusage/</link><pubDate>Mon, 18 May 2026 15:37:43 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-edumfa-token-reusage/</guid><description>eduMFA versions prior to 2.9.1 are vulnerable to token reusage due to incorrect InnoDB snapshot isolation in MySQL and MariaDB versions prior to 11.6.2 (or newer with innodb_snapshot_isolation=off), affecting token types such as TOTP, HOTP, and likely WebAuthN, where tokens are intended for single use, requiring racing the transaction for exploitation.</description><content:encoded><![CDATA[<p>A vulnerability exists in eduMFA versions prior to 2.9.1 related to the handling of transaction isolation within the database layer. Specifically, when eduMFA is deployed with MySQL or MariaDB versions prior to 11.6.2 (or newer versions with <code>innodb_snapshot_isolation</code> explicitly set to OFF), it is possible for attackers to reuse token values due to faulty transaction isolation. This is because the database might not properly serialize token usage, allowing multiple requests to validate the same token before it is invalidated. The affected token types include TOTP, HOTP, and potentially WebAuthN, all of which rely on single-use tokens. Exploitation requires racing conditions. The vulnerability was addressed in eduMFA version 2.9.1.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>User initiates a multi-factor authentication process.</li>
<li>eduMFA generates a time-based or counter-based one-time password (TOTP or HOTP).</li>
<li>The token and associated user data are written to the database.</li>
<li>Attacker initiates multiple authentication requests using the same token value in rapid succession.</li>
<li>Due to incorrect InnoDB snapshot isolation, multiple authentication requests may read the same uncommitted token value from the database before it is invalidated by the first successful authentication.</li>
<li>The database validates the token for each of the attacker&rsquo;s requests, as the isolation level does not prevent concurrent reads before write.</li>
<li>If the race succeeds, multiple authentication sessions are established using the same token.</li>
<li>The attacker gains unauthorized access to the user&rsquo;s account.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability allows an attacker to bypass multi-factor authentication and gain unauthorized access to user accounts. This could lead to data breaches, account compromise, and other malicious activities. The number of potentially affected users depends on the deployment size of eduMFA and the number of users relying on TOTP, HOTP or WebAuthN for authentication. Sectors that rely on eduMFA for authentication are potentially at risk.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade eduMFA to version 2.9.1 to apply the fix that locks rows prior to write with SELECT FOR UPDATE.</li>
<li>If upgrading is not immediately feasible, set <code>innodb_snapshot_isolation</code> to ON in MariaDB configurations (default in MariaDB &gt;= 11.6.2) as a workaround.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>vulnerability</category><category>mfa</category><category>token reusage</category></item><item><title>eduMFA Passkey Replay Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2026-05-edumfa-passkey-replay/</link><pubDate>Mon, 18 May 2026 15:37:32 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-edumfa-passkey-replay/</guid><description>eduMFA versions prior to 2.9.1 are vulnerable to replay attacks due to a missing expiration flag in userless Passkey/WebAuthn challenges, potentially leading to unauthorized access.</description><content:encoded><![CDATA[<p>eduMFA versions prior to 2.9.1 are susceptible to a replay attack vulnerability affecting userless Passkey/WebAuthn authentication. This flaw stems from the absence of an expiration flag within the challenge generated during the authentication process. Consequently, an attacker could potentially capture a valid, unexpired challenge and reuse it to bypass authentication, even after the legitimate user&rsquo;s session has ended or the challenge should have expired. This issue was addressed in eduMFA version 2.9.1 by implementing validity information for userless challenges. Defenders should prioritize upgrading vulnerable instances of eduMFA to version 2.9.1 or later to mitigate this risk.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>User initiates a userless Passkey/WebAuthn authentication request against an eduMFA instance running a version prior to 2.9.1.</li>
<li>eduMFA generates a challenge without proper expiration or validity constraints.</li>
<li>Attacker intercepts the challenge during transmission or retrieves it from a compromised system.</li>
<li>The legitimate user completes the authentication, granting access to protected resources.</li>
<li>Attacker replays the previously intercepted challenge to the eduMFA instance.</li>
<li>Due to the missing expiration check, eduMFA incorrectly validates the replayed challenge as legitimate.</li>
<li>Attacker gains unauthorized access to the protected resources, impersonating the original user.</li>
<li>Attacker performs actions within the system using the compromised session, potentially escalating privileges or exfiltrating sensitive data.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability allows attackers to bypass multi-factor authentication and gain unauthorized access to systems and data protected by eduMFA. This can lead to data breaches, financial losses, and reputational damage. The impact is significant as it undermines the security guarantees provided by multi-factor authentication, especially in environments relying on userless Passkey/WebAuthn authentication.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade all eduMFA installations to version 2.9.1 or later to remediate the vulnerability as described in the overview.</li>
<li>Deploy the Sigma rule &ldquo;Detect eduMFA Passkey Replay Attempt&rdquo; to identify potential replay attacks by monitoring for multiple authentication attempts using the same challenge.</li>
<li>If immediate patching is not possible, consider temporarily disabling userless login as suggested in the advisory.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>replay-attack</category><category>authentication</category><category>webauthn</category></item></channel></rss>