Updates

• Affected products

Comments
This is not affecting version 0.15.5 - due to the reasons below:

in short - not relevant to this version:

The state is tied to the user's session
An attacker cannot supply a valid state from their own session to be used in the victim's session
The get_session_data method uses session.pop() which removes the state from the session, ensuring it's only used once
more detailed:
State is stored in request.session, which is tied to the user's session cookie
An attacker cannot access the victim's session (assuming proper session security)
If an attacker tricks a victim into visiting the callback with the attacker's state, get_session_data will return None (the victim's session doesn't have that state), and validation fails
This is different from the cache-backed vulnerability where state was stored globally and not bound to a user session.

The architecture differs from the vulnerable pattern described in the CVE:

Version 0.15.5 uses a simpler state management system:
set_session_data() and get_session_data() store data in the session directly using keys like {name}authlib{key}
Cache is only used for OAuth1 request tokens (not OAuth2 state), and even then it stores a session ID in the session and the actual token in cache (see authlib/integrations/flask_client/oauth_registry.py )
State management:
1.OAuth2 state is stored directly in session via set_session_data(request, 'state', state)
2.Retrieved via get_session_data(request, 'state') which pops it from session enforces one-time use.
3.The session key format includes the client name: dev_authlib_state
4.There is NO cache-backed state storage pattern (Cache is only used for OAuth1 tokens with session-bound keys.)