MISP contains a vulnerability in its one-time password (OTP) authentication flow that allows replay of a consumed HOTP (paper) token and rewinding of the token counter.
The HOTP verification logic compared the submitted token against a counter value that was cached in the user's session at the time the password was entered, rather than against the authoritative counter stored in the database. Because the session-cached counter is not updated after a token is successfully consumed, an attacker who holds a valid session (password already submitted) can reuse a previously burned HOTP token. The stale cached counter still matches the replayed token, granting a second successful authentication and effectively rewinding the counter state.
Preconditions:
-
The target user has HOTP (paper token) second-factor authentication enabled.
-
The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).
-
The attacker has access to at least one HOTP token value (e.g., a paper token list).
Security impact:
-
Bypass of the second authentication factor, allowing unauthorized access to a user's MISP account.
-
Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.
Affected versions: <2.5.48.
The fix replaces the session-cached HOTP counter lookup with a direct read of the authoritative counter from the database, performed under a Redis-based distributed lock scoped to the user. The token is verified against the current stored counter, the counter is incremented and persisted atomically within the locked section, and the lock is released in a finally block. Additionally, the cached OTP user session entry is deleted immediately after a successful login (for both TOTP and HOTP paths), preventing the stale session state from being reused.