CVE-2022-2447

What it actually does

Delayed enforcement of token revocation in the identity service allows tokens marked invalid to remain usable for up to one hour under default configuration, bypassing authorization checks.

Why it matters to the business

Privileged users in affected OpenStack and Red Hat deployments can retain unauthorized access longer than policy intends, raising the chance of data exposure or unauthorized changes during the window.

How an attack unfolds

An attacker with administrative rights issues a token revocation request then continues authenticated operations with the still-valid token during the synchronization lag before full invalidation occurs across the cluster.

How to fix it

Shorten token expiration and revocation check intervals in service configuration; apply the latest available updates to OpenStack Keystone and Red Hat OpenStack Platform components when released.

How to confirm the fix worked

Create a test token, trigger revocation, then attempt authenticated calls at intervals up to one hour to confirm whether access is denied immediately or delayed.

Typical attack path

1. Obtain administrative privileges in the identity service
2. Issue revocation for their own token via the management API
3. Reuse the token to perform additional privileged actions before the revocation propagates
4. Terminate or clean up sessions to avoid post-lag detection

How to detect it

Search authentication and token service logs for usage events that occur after a corresponding revocation record; correlate timestamps between revocation API calls and subsequent successful authentications.

What your security team should do

• Audit current token lifetime and revocation sync settings across all deployments
• Reduce default revocation lag by tuning configuration parameters
• Enable detailed token usage logging and monitor for post-revocation activity
• Prioritize patching once fixed packages become available given public exploit availability