Listen to this Post
How the mentioned CVE works:
The vulnerability stems from faulty transaction isolation in MySQL and MariaDB when `innodb_snapshot_isolation` is OFF (default in many versions). Normally, REPEATABLE READ using snapshot isolation prevents non-repeatable reads and phantom rows. However, with this flaw, concurrent transactions can observe stale snapshot states that ignore recent row updates. Specifically, when a token (e.g., TOTP, HOTP, WebAuthN challenge) is consumed and marked as used, a racing transaction that began earlier may still see the token as unused due to improper visibility of the committed write. This occurs because the database fails to enforce the expected isolation boundary – the second transaction’s snapshot does not reflect the first transaction’s committed changes. Attackers can trigger this by timing two parallel requests: one consuming a token, another reusing the same token within the same microsecond window. Successful exploitation requires precise race condition, but automated scripts can achieve it. The flaw affects any token type designed for single use, breaking idempotency and replay protection. MariaDB introduced `innodb_snapshot_isolation` as a tunable in versions 10.6.18, 10.11.8, 11.0.6, 11.1.5, 11.2.4, 11.4.2, default OFF. MySQL (any version) lacks this setting entirely and is always vulnerable unless application-level locks are used. The root cause is missing `SELECT FOR UPDATE` row locking prior to token validation/update, allowing lost updates. Fix requires explicit pessimistic locking or enabling snapshot isolation (MariaDB ≥11.6.2 defaults ON). Without fix, an attacker can bypass one-time guarantees, e.g., replay OTP or reuse authentication challenges.
dailycve form:
Platform: Database Server
Version: MariaDB<11.6.2,MySQL
Vulnerability : One-time token reuse
Severity: Medium
date: 2026-05-18
Prediction: Already patched Dec2024
What Undercode Say:
Check current innodb_snapshot_isolation setting (MariaDB)
mysql -e "SHOW VARIABLES LIKE 'innodb_snapshot_isolation';"
Enable workaround (set to ON)
mysql -e "SET GLOBAL innodb_snapshot_isolation = ON;"
Verify fix version (MariaDB 11.6.2+)
mysql -e "SELECT VERSION();"
Application-level fix: use SELECT FOR UPDATE
mysql -e "START TRANSACTION; SELECT token FROM tokens WHERE id=1 FOR UPDATE; UPDATE tokens SET used=1 WHERE id=1; COMMIT;"
Simulate race condition (bash loop)
for i in {1..100}; do (curl -X POST /use/token?val=123 & curl -X POST /use/token?val=123 &); done
How Exploit:
- Attacker captures a valid one-time token (e.g., TOTP code).
- Attacker sends two almost simultaneous requests to validate/consume the same token.
3. Transaction A begins, reads token as unused.
- Transaction B begins before A commits, also reads token as unused (stale snapshot).
- Both transactions validate and try to mark token as used.
- First commit succeeds; second commit overwrites or ignores the used state.
7. Token is reused, bypassing one-time restriction.
Protection from this CVE
- Upgrade MariaDB to ≥11.6.2 (default
innodb_snapshot_isolation=ON). - Enable `innodb_snapshot_isolation` manually on older MariaDB versions.
- For MySQL, implement explicit row locking: `SELECT … FOR UPDATE` before token update.
- Use optimistic locking with version numbers or unique constraints on consumed tokens.
- Reduce race window by using stored procedures with serializable isolation level.
Impact
- Replay of TOTP/HOTP codes, breaking two-factor authentication.
- Reuse of WebAuthN challenges, allowing authentication bypass.
- Any multi-factor or anti-replay mechanism relying on database-unique one-time tokens is compromised.
- Attackers can gain unauthorized access, perform replay attacks, and circumvent audit trails.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
