CVE-2026-103651: MISP HOTP Token Replay via Stale Session-Cached Counter Allows Second-Factor Authentication Bypass
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MISPto a version that resolves this vulnerability.Fixed in 2.5.48
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs a valid session for the target user where the password has already been accepted but the OTP step is still pending. They also need access to at least one HOTP paper-token value for that user.
Which users are exposed?
The issue applies to users with HOTP (paper token) second-factor authentication enabled. The vulnerability relies on the session retaining a stale HOTP counter after a token has been consumed.
Can this be exploited using a token that was already used?
Yes. A previously consumed HOTP token can be replayed through the session that retains the stale counter value, resulting in another successful authentication and counter-state rewind.