<?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>2fa — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/2fa/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 03 Apr 2026 03:29:59 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/2fa/feed.xml" rel="self" type="application/rss+xml"/><item><title>Better Auth Two-Factor Authentication Bypass Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2024-01-02-better-auth-2fa-bypass/</link><pubDate>Fri, 03 Apr 2026 03:29:59 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-02-better-auth-2fa-bypass/</guid><description>Better Auth versions prior to 1.4.9 have a critical two-factor authentication bypass vulnerability; when session.cookieCache is enabled, the initial sign-in session may be improperly cached, allowing attackers with valid credentials to bypass 2FA.</description><content:encoded><![CDATA[<p>Better Auth versions prior to 1.4.9 contain a critical vulnerability that can lead to two-factor authentication (2FA) bypass. The vulnerability arises when the <code>session.cookieCache</code> is enabled. In this configuration, the initial session created during the login process can be prematurely cached before the 2FA verification is completed. Consequently, subsequent session lookups might use this cached session, circumventing the necessary 2FA check. This issue allows an attacker who possesses valid primary credentials to gain unauthorized access to protected application routes without completing the mandated second authentication factor. Any application leveraging <code>better-auth</code> with 2FA and session cookie caching enabled is potentially vulnerable.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>User attempts to log in with valid username and password.</li>
<li>The application, running a vulnerable version of <code>better-auth</code> with <code>session.cookieCache</code> enabled, creates a session.</li>
<li>The session is cached due to the <code>session.cookieCache</code> setting, <em>before</em> the 2FA challenge is presented.</li>
<li>The user is prompted for their second factor (e.g., TOTP code).</li>
<li>Instead of providing the 2FA code, the attacker intercepts or reuses the cached session cookie.</li>
<li>The attacker presents the cached session cookie to the application.</li>
<li>The application retrieves the cached session, which it prematurely considers valid.</li>
<li>The attacker gains access to protected resources without completing 2FA.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability allows attackers with valid usernames and passwords to bypass two-factor authentication, gaining unauthorized access to sensitive application resources. The number of affected applications is unknown, but all applications using <code>better-auth</code> with 2FA and session caching are potentially at risk. A successful attack could lead to data breaches, account takeovers, and other serious security incidents.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade to <code>better-auth</code> version 1.4.9 or later to patch the vulnerability.</li>
<li>Disable <code>session.cookieCache</code> when using two-factor authentication as a temporary mitigation.</li>
<li>If disabling <code>session.cookieCache</code> is not feasible, implement server-side checks to ensure 2FA is completed before granting full session validity (requires code modification).</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>authentication</category><category>2fa</category><category>bypass</category><category>better-auth</category></item><item><title>Admidio Inverted 2FA Reset Allows Privilege Escalation</title><link>https://feed.craftedsignal.io/briefs/2024-01-admidio-2fa-bypass/</link><pubDate>Mon, 22 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-admidio-2fa-bypass/</guid><description>A logic error in Admidio's two-factor authentication reset inverts the authorization check, allowing non-admin users to remove other users' TOTP, including administrators, reducing their security to password-only authentication in versions 5.0.8 and earlier.</description><content:encoded><![CDATA[<p>Admidio, a web-based content management system for organizations, contains a critical vulnerability in its two-factor authentication (2FA) reset mechanism. The vulnerability, present in versions 5.0.8 and earlier, stems from an inverted authorization check within the <code>modules/profile/two_factor_authentication.php</code> script. This flaw enables non-administrative users, specifically group leaders with profile edit rights, to disable 2FA for other users, including administrator accounts. The vulnerability was reported on April 29, 2026. By exploiting this flaw, attackers can bypass 2FA, gaining unauthorized access to privileged accounts and potentially compromising the entire Admidio installation. This highlights the importance of rigorous security audits and proper authorization checks in web applications.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker compromises or gains access to a non-admin user account within Admidio that possesses <code>hasRightEditProfile()</code> permission over an administrator account.</li>
<li>The attacker crafts a POST request to <code>/adm_program/modules/profile/two_factor_authentication.php</code> with the <code>mode</code> parameter set to <code>reset</code> and the <code>user_uuid</code> parameter set to the UUID of the target administrator account.</li>
<li>The server-side script <code>modules/profile/two_factor_authentication.php</code> executes the flawed authorization check at line 84. Due to the inverted logic (<code>!==</code> instead of <code>===</code>), the check incorrectly grants permission to the non-admin user to reset the administrator&rsquo;s 2FA.</li>
<li>The server removes the TOTP configuration associated with the administrator&rsquo;s account from the database or configuration files.</li>
<li>The attacker can now attempt to log in to the administrator account using only the password, bypassing the 2FA requirement.</li>
<li>If the attacker knows or can guess the administrator&rsquo;s password (via credential stuffing, brute force, or other means), they successfully gain access to the account.</li>
<li>With administrator privileges, the attacker can perform a variety of malicious actions, such as creating new accounts, modifying website content, or accessing sensitive data.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The vulnerability allows attackers to bypass two-factor authentication on administrator accounts in Admidio installations. This can lead to unauthorized access to sensitive data, modification of website content, and potentially full control over the affected system. While the number of affected installations is unknown, organizations using vulnerable versions of Admidio are at risk. Success of the attack results in complete compromise of the Admidio instance and the data it manages.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Apply the recommended fix by changing <code>!==</code> to <code>===</code> on line 84 of <code>modules/profile/two_factor_authentication.php</code> to correct the authorization logic (see Overview).</li>
<li>Deploy the Sigma rule <code>Detect Admidio 2FA Reset Request</code> to detect attempts to exploit this vulnerability by monitoring HTTP POST requests to the vulnerable endpoint (see Rules).</li>
<li>Upgrade Admidio to a patched version that incorporates the fix for CVE-2026-41660.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>2fa</category><category>bypass</category><category>privilege-escalation</category><category>admidio</category></item></channel></rss>