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.
Metrics
Affected Vendors & Products
References
| Link | Providers |
|---|---|
| https://github.com/MISP/MISP/commit/f34aee2c7 |
|
History
Thu, 01 Oct 2026 17:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Thu, 01 Oct 2026 08:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | MISP HOTP Token Replay via Stale Session-Cached Counter Allows Second-Factor Authentication Bypass | |
| First Time appeared |
Misp
Misp misp |
|
| Weaknesses | CWE-287 CWE-362 |
|
| CPEs | cpe:2.3:a:misp:misp:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Misp
Misp misp |
|
| References |
| |
| Metrics |
cvssV4_0
|
Status: PUBLISHED
Assigner: CIRCL
Published: 2026-10-01T07:34:02.597Z
Updated: 2026-10-01T15:32:08.372Z
Reserved: 2026-10-01T07:34:00.794Z
Link: CVE-2026-103651
Updated: 2026-10-01T15:32:04.475Z
Status : Deferred
Published: 2026-10-01T08:16:51.020
Modified: 2026-10-01T16:17:37.313
Link: CVE-2026-103651
No data.