GHSA-f66q-9rf6-8795: WebAuthn Re-authentication Freshness Bypass in Flask-Security-Too

The security package Flask-Security-Too implements WebAuthn support to facilitate passwordless and multi-factor authentication. To secure highly sensitive operations, the library utilizes session freshness validation via the @auth_required(within=...) decorator. When a user attempts to access a protected resource, the server checks if the session was authenticated within a specified time window.

If the session is stale, the application enforces re-authentication before the request can proceed. Users can satisfy this requirement using their registered WebAuthn credentials. The vulnerability resides in this re-authentication workflow and permits an attacker to falsify the freshness status of a session.

The attack surface requires the attacker to be an authenticated user on the same application instance. This vulnerability is classified under CWE-305, allowing an attacker to utilize WebAuthn as an alternate channel to bypass re-authentication requirements.

The flaw is located in the webauthn_verify_response view within flask_security/webauthn.py. When a re-authentication flow is initiated, the application issues a challenge and expects a cryptographic WebAuthn assertion in response. This response is validated using the WebAuthnSigninResponseForm.

During validation, the form parses the credential identifier from the client's assertion and retrieves the associated database user. However, the backend validation logic fails to check whether this retrieved user matches the active current_user of the session. The signature validation is processed successfully as long as the credential belongs to any valid user in the database.

Because of this validation oversight, once the signature is verified, the server executes session["fs_paa"] = time.time(). This line unconditionally updates the security freshness timestamp on the active session. Consequently, the victim's session is designated as fresh based on the cryptographic proof of the attacker's WebAuthn key.

The vulnerable code segment demonstrates the absence of identity binding verification. In flask_security/webauthn.py at commit 5c44c76e33a20b67d02115e26d2da4bab18c094e, the application processes the signature validation as follows:

@auth_required(lambda: cv("API_ENABLED_METHODS"))
def webauthn_verify_response(token: str) -> ResponseValue:
    form = t.cast(
        WebAuthnSigninResponseForm, build_form_from_request("wan_signin_response_form")
    )
    # ... verification steps ...
    if form.validate_on_submit():
        # Code updates last use data
        form.cred.lastuse_datetime = _security.datetime_factory()
        _datastore.put(form.cred)
 
        # Unconditional update of session freshness
        session["fs_paa"] = time.time()

The WebAuthnSigninResponseForm.validate method resolves the user object strictly from the credential ID query. It executes self.user = _datastore.find_user_from_webauthn(self.cred). It never compares this self.user instance against the active session user, allowing cross-user re-authentication assertions to succeed.

This behavior contrasts with the patched OAuth flow implemented in a previous release. The OAuth re-authentication path explicitly checks if user and user.email == current_user.email before updating the session freshness parameter. The lack of an equivalent check on the WebAuthn code path leaves the freshness mechanism exposed.

An exploitation sequence requires the attacker to possess an active account on the deployment and a registered WebAuthn credential. The attacker must also have access to the victim's session, which has entered a stale freshness state. This scenario often occurs in shared workstation environments or when session tokens are partially exfiltrated.

The attacker initiates the re-authentication sequence within the victim's session by making a request to the /wan-verify endpoint. The server responds with a WebAuthn challenge wrapped in a temporary state token. Because these state tokens lack user binding, they are highly portable.

Instead of utilizing the victim's credentials, the attacker signs this challenge using their own WebAuthn key. The attacker then submits the assertion back to the endpoint. The backend validates the assertion against the attacker's public key, marks the form as valid, and advances the session freshness timer on the victim's active session.

The impact of this security freshness bypass is significant, as it completely subverts the isolation between authentication strengths. Freshness gates are critical defense-in-depth mechanisms designed to protect highly sensitive operations from unauthorized modification. These operations include password resets, multi-factor authentication enrollment, and email modifications.

By leveraging this bypass, an attacker can modify the security parameters of the victim's account. This allows the attacker to register a permanent authenticating credential under their control or change the primary email address. This results in complete and persistent account takeover.

The vulnerability does not allow direct initial access but acts as a privilege escalation and security bypass tool. It elevates a standard, stale session to a fresh administrative-grade session. No user interaction from the victim is required once the session is active.

Remediation requires upgrading the flask-security-too package to version 5.8.2 or later. This patch introduces a verification step to ensure the WebAuthn assertion belongs to the active session owner. The security check compares the user object retrieved from the credential with the session's active user identity.

If upgrading immediately is not feasible, deployers should disable WebAuthn re-authentication. This can be accomplished by removing WebAuthn from the allowed verification options in the configuration. Adjust the SECURITY_WAN_ALLOW_AS_VERIFY parameter to exclude WebAuthn verification.

In addition, implementing robust monitoring of the /wan-verify endpoint can help identify anomalous behavior. Security teams should monitor for instances where the authenticated session user differs from the user owner of the WebAuthn credential utilized during re-authentication.