CVE-2024-21722 is a security vulnerability that targets systems with Multi-Factor Authentication (MFA) or Two-Factor Authentication (2FA). In apps or services where this vulnerability exists, if an administrator or user changes their MFA methods—for example, adding/removing an authentication app or a phone number—the *existing logged-in sessions* are not forced to re-authenticate. That means anyone already logged in can keep using the account, even if their MFA credentials have changed. This issue can leave accounts open to hijacking or persistent unauthorized access.

Why This Matters

A key idea behind MFA is: even if your password is stolen, a hacker still needs your second factor (like an SMS code or authenticator app). But, what happens if you realize something's fishy and change your MFA methods *after* a breach or device loss? With this bug, the attacker could stay logged in, undisturbed, even after you change your authentication. That completely *defeats the safety purpose of MFA.*

Here’s a simplified code snippet showing what not to do when handling MFA changes

def update_mfa_methods(user, new_methods):
    # This updates the database with new MFA methods
    user.mfa_methods = new_methods
    save(user)
    # Problem: Active sessions are NOT terminated!
    return "MFA methods updated"

What’s missing? You must revoke active sessions after sensitive MFA changes.

Here’s what should happen

def update_mfa_methods(user, new_methods):
    user.mfa_methods = new_methods
    save(user)
    # SECURE: Invalidate all active sessions!
    session_manager.logout_all_sessions(user)
    return "MFA methods updated and sessions terminated"

- logout_all_sessions(user) is a placeholder for whatever method your system uses to log out all devices tied to that account.

Victim (or admin) realizes weird activity. They remove old MFA device and add a new one.

3. Attacker’s existing session is *not* disrupted — they can keep browsing, download data, or change settings.

Even after the victim updates MFA, the attacker stays inside.

This scenario is sadly not theoretical. It’s how actual breaches persist after “fixes” – users think they’ve kicked the hacker out, but the session is still valid.

Suppose you have a typical Flask login system

@app.route('/update_mfa', methods=['POST'])
@login_required
def update_mfa():
    user = current_user
    new_methods = request.form.get('mfa_methods')
    user.update_mfa_methods(new_methods)
    db.session.commit()
    # BAD: missing session termination
    return jsonify({'status': 'MFA updated'})

To fix

@app.route('/update_mfa', methods=['POST'])
@login_required
def update_mfa():
    user = current_user
    new_methods = request.form.get('mfa_methods')
    user.update_mfa_methods(new_methods)
    db.session.commit()
    logout_user()  # Kicks out the current session
    session.clear()  # Removes session cookies
    return jsonify({'status': 'MFA updated, logged out'})

If possible, also revoke *all* tokens/sessions for the user, not just the current one.

Any *web app, cloud service, or identity provider* that

- Allows users to modify or reset MFA/2FA devices

Does not kill active sessions after those security-critical changes

This includes (but isn’t limited to): custom web apps, SaaS platforms, federated identity providers, and some on-prem products.

For Administrators/Developers

- Audit your authentication system: when MFA/2FA methods are changed, old sessions *must* die.

For End Users

- After changing MFA methods, log out from all devices, and ask admins to force-logout all sessions if possible.

Resources and References

- NIST Special Publication 800-63B – Digital Identity Guidelines
- OWASP cheatsheet: Session Management
- CVE record: CVE-2024-21722 at MITRE

Final Thoughts

CVE-2024-21722 is a perfect example of how security is not just about the *components* (MFA, strong passwords), but the *connections* and *workflows* between them. If you add layers, but the doors between them stay open, attackers win.

Always review your session management: Log out, revoke, and force new logins after every security-critical change!

Timeline

Published on: 02/29/2024 01:44:03 UTC
Last modified on: 10/30/2024 18:35:02 UTC