CVE-2026-103651 (GCVE-0-2026-103651)

Vulnerability from cvelistv5 – Published: 2026-10-01 07:34 – Updated: 2026-10-01 15:32
VLAI
Title
MISP HOTP Token Replay via Stale Session-Cached Counter Allows Second-Factor Authentication Bypass
Summary
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.
SSVC
Exploitation: none Automatable: no Technical Impact: total
Supplier · CIRCL (v2.0.3)
Decision recorded 2026-10-01 07:22 UTC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-01 15:31 UTC
CWE
  • CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)
  • CWE-287 - Improper Authentication
References
Impacted products
Vendor Product Version CPE status
MISP MISP Affected: 0 , < 2.5.48 (semver)
    cpe:2.3:a:misp:misp:*:*:*:*:*:*:*:*
Create a notification for this product.
GCVE extensions
bcp-05-x-01
AI-assisted vulnerability information annotation
GCVE-BCP-05-X-01
Whole record AI-generated Human-reviewed GNA-1

Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.

ai-computer-assisted:llm-generatedai-computer-assisted:classification
Model Source Identifier
qwen3.8:27b ollama qwen3.8:27b
bcp-05-x-02
Patch-to-vulnerability generation provenance
GCVE-BCP-05-X-02
Generator
patch2vuln.py on 2026-10-01 07:22
Model
qwen3.8:27b
Input
https://github.com/MISP/MISP/commit/f34aee2c7.patch 9ec05e4a3d95…
Confidence
medium
Commit Subject Patch SHA-256
f34aee2c74e1 fix: [security] Burn paper OTP tokens against the stored 9ec05e4a3d95…
Fix summary

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.

Patch summary

In UsersController::otp(), the inline HOTP verification block (which used the session-cached $user['hotp_counter']) is replaced with a call to a new private method __consumeHotp(). This method acquires a Redis SETNX lock (misp:otp:hotp_lock:{userId}, 10 s TTL), re-fetches the user's totp secret and hotp_counter from the database, verifies the submitted OTP against the stored counter, increments and saves the counter, and releases the lock in a finally block. The otp_user session key is now deleted after both TOTP and HOTP successful login paths. Net change: +36 / -5 lines in app/Controller/UsersController.php.

CVSS rationale

AV:N – MISP is a network-accessible web application. AC:H – exploitation requires a valid session with the password step already completed, possession of a valid HOTP token value, and the session must still hold the stale cached counter; multiple preconditions must align. AT:N – no manipulation of the target system is needed. PR:L – the attacker must be an authenticated user with a pending OTP session. UI:N – no additional user interaction is required beyond the initial login flow. VC:H – successful exploitation grants full access to the target user's MISP account and its data. VI:H – the attacker can perform any action the user is authorized to perform, and the counter corruption may affect subsequent legitimate authentication. VA:N – no denial-of-service impact is evident. SC/SI/SA:N – no secondary system impact is indicated by the patch.

Weakness rationale
  • CWE-362 The HOTP counter is shared mutable state accessed without synchronization. The session-cached copy becomes stale relative to the database copy, and no lock is held during read-verify-increment, allowing a concurrent or replayed request to operate on the old value.
  • CWE-287 The OTP verification logic accepts a token that has already been consumed because it compares against a stale cached counter rather than the authoritative stored counter, effectively weakening the second-factor authentication check.
Attack pattern rationale
  • CAPEC-111 The vulnerability is exploited by exploiting the time window between the session-cached counter being set (at password entry) and the token being consumed, allowing a replayed token to be validated against the stale value. CAPEC-111 (Race Condition) is the closest available CAPEC pattern; the attack is not a classic TOCTOU on a file or memory location but rather a stale-cache race on a shared counter, which falls under the broader race-condition category. No more specific CAPEC for session-cached credential state replay exists in the CAPEC catalog, so this is the best available match.
Assumptions to verify
  • The tag_version_boundary metadata (v2.5.48, 41 commits after fix) is interpreted as the first release containing the fix; no explicit fixed_version or affected_version was provided in the metadata.
  • The CAPEC-111 mapping is the closest available pattern; the vulnerability is specifically a stale-session-cache replay rather than a classic TOCTOU race, and no more precise CAPEC exists in the catalog.
  • CVSS PR:L assumes the attacker already has a valid authenticated session (password step completed); if the threat model requires unauthenticated access, PR would be None but AC would remain High.
  • The Redis lock is assumed to be available in the deployment; if Redis is not configured, the locking mechanism may be bypassed, though this is a deployment concern not reflected in the patch.
  • The Co-Authored-By line references an AI assistant; it is recorded as a tool credit rather than a human remediation developer.
Model comparison

Selected qwen3.8:27b by deterministic-consensus-v1
The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required.

Model Score Agreement Confidence Assumptions
qwen3.8:27b 7 11 medium 5
bcp-05-x-03
Vulnerability handling and disclosure timeline
GCVE-BCP-05-X-03
  1. 2026-09-23 14:20 UTC Fix developed Corrective change authored (f34aee2c74e111fffd07e8ddde8e4843ccf998db): fix: [security] Burn paper OTP tokens against the stored https://github.com/MISP/MISP/commit/f34aee2c7.patch
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-103651",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-01T15:31:56.170497Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-01T15:32:08.372Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "cpes": [
            "cpe:2.3:a:misp:misp:*:*:*:*:*:*:*:*"
          ],
          "modules": [
            "app/Controller/UsersController.php"
          ],
          "product": "MISP",
          "programFiles": [
            "app/Controller/UsersController.php"
          ],
          "repo": "https://github.com/MISP/MISP",
          "vendor": "MISP",
          "versions": [
            {
              "lessThan": "2.5.48",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Tanguy Snoeck of NCIA"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "iglocska"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Claude Opus 5.5 (1M context)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMISP 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.\u003c/p\u003e\u003cp\u003eThe HOTP verification logic compared the submitted token against a counter value that was cached in the user\u0027s 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.\u003c/p\u003e\u003cp\u003ePreconditions:\u003c/p\u003e\u003cp\u003e- The target user has HOTP (paper token) second-factor authentication enabled.\u003c/p\u003e\u003cp\u003e- The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).\u003c/p\u003e\u003cp\u003e- The attacker has access to at least one HOTP token value (e.g., a paper token list).\u003c/p\u003e\u003cp\u003eSecurity impact:\u003c/p\u003e\u003cp\u003e- Bypass of the second authentication factor, allowing unauthorized access to a user\u0027s MISP account.\u003c/p\u003e\u003cp\u003e- Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.\u003c/p\u003e\u003cp\u003eAffected versions: \u0026lt;2.5.48.\u003c/p\u003e"
            }
          ],
          "value": "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.\n\nThe HOTP verification logic compared the submitted token against a counter value that was cached in the user\u0027s 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.\n\nPreconditions:\n\n- The target user has HOTP (paper token) second-factor authentication enabled.\n\n- The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).\n\n- The attacker has access to at least one HOTP token value (e.g., a paper token list).\n\nSecurity impact:\n\n- Bypass of the second authentication factor, allowing unauthorized access to a user\u0027s MISP account.\n\n- Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.\n\nAffected versions: \u003c2.5.48."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-111",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-111 Race Condition"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.6,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "format": "SSVC",
          "other": {
            "content": {
              "options": [
                {
                  "Exploitation": "none"
                },
                {
                  "Automatable": "no"
                },
                {
                  "Technical Impact": "total"
                }
              ],
              "role": "Supplier",
              "timestamp": "2026-10-01T07:22:27Z",
              "version": "2.0.3"
            },
            "type": "SSVC"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-362",
              "description": "CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-01T07:34:02.597Z",
        "orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "shortName": "CIRCL"
      },
      "references": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/MISP/MISP/commit/f34aee2c7"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe 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.\u003c/p\u003e"
            }
          ],
          "value": "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."
        }
      ],
      "title": "MISP HOTP Token Replay via Stale Session-Cached Counter Allows Second-Factor Authentication Bypass",
      "x_gcve": [
        {
          "extensions": {
            "bcp-05-x-01": {
              "ai_annotations": [
                {
                  "ai_level": "generated",
                  "description": "Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.",
                  "gna_source": 1,
                  "models": [
                    {
                      "gna_source": 1,
                      "identifier": "qwen3.8:27b",
                      "name": "qwen3.8:27b",
                      "source": "ollama"
                    }
                  ],
                  "review_status": "full",
                  "scope": "record",
                  "tags": [
                    "ai-computer-assisted:llm-generated",
                    "ai-computer-assisted:classification"
                  ]
                }
              ]
            },
            "bcp-05-x-02": {
              "x_patch2vuln": {
                "assumptions": [
                  "The tag_version_boundary metadata (v2.5.48, 41 commits after fix) is interpreted as the first release containing the fix; no explicit fixed_version or affected_version was provided in the metadata.",
                  "The CAPEC-111 mapping is the closest available pattern; the vulnerability is specifically a stale-session-cache replay rather than a classic TOCTOU race, and no more precise CAPEC exists in the catalog.",
                  "CVSS PR:L assumes the attacker already has a valid authenticated session (password step completed); if the threat model requires unauthenticated access, PR would be None but AC would remain High.",
                  "The Redis lock is assumed to be available in the deployment; if Redis is not configured, the locking mechanism may be bypassed, though this is a deployment concern not reflected in the patch.",
                  "The Co-Authored-By line references an AI assistant; it is recorded as a tool credit rather than a human remediation developer."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-111",
                    "rationale": "The vulnerability is exploited by exploiting the time window between the session-cached counter being set (at password entry) and the token being consumed, allowing a replayed token to be validated against the stale value. CAPEC-111 (Race Condition) is the closest available CAPEC pattern; the attack is not a classic TOCTOU on a file or memory location but rather a stale-cache race on a shared counter, which falls under the broader race-condition category. No more specific CAPEC for session-cached credential state replay exists in the CAPEC catalog, so this is the best available match."
                  }
                ],
                "commit": "f34aee2c74e111fffd07e8ddde8e4843ccf998db",
                "confidence": "medium",
                "credits": [
                  {
                    "lang": "en",
                    "type": "reporter",
                    "value": "Tanguy Snoeck of NCIA"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "iglocska"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Claude Opus 5.5 (1M context)"
                  }
                ],
                "cvssRationale": "AV:N \u2013 MISP is a network-accessible web application. AC:H \u2013 exploitation requires a valid session with the password step already completed, possession of a valid HOTP token value, and the session must still hold the stale cached counter; multiple preconditions must align. AT:N \u2013 no manipulation of the target system is needed. PR:L \u2013 the attacker must be an authenticated user with a pending OTP session. UI:N \u2013 no additional user interaction is required beyond the initial login flow. VC:H \u2013 successful exploitation grants full access to the target user\u0027s MISP account and its data. VI:H \u2013 the attacker can perform any action the user is authorized to perform, and the counter corruption may affect subsequent legitimate authentication. VA:N \u2013 no denial-of-service impact is evident. SC/SI/SA:N \u2013 no secondary system impact is indicated by the patch.",
                "fixSummary": "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.",
                "generatedAt": "2026-10-01T07:22:27.568266Z",
                "generator": "patch2vuln.py",
                "model": "qwen3.8:27b",
                "modelComparison": {
                  "rankings": [
                    {
                      "agreementScore": 11,
                      "assumptionCount": 5,
                      "confidence": "medium",
                      "model": "qwen3.8:27b",
                      "score": 7
                    }
                  ],
                  "selectedModel": "qwen3.8:27b",
                  "selectionMethod": "deterministic-consensus-v1",
                  "selectionNotice": "The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required."
                },
                "patchSha256": "9ec05e4a3d95b183604c7e89e3fbb93950ac4d23dfe478809b868b6dfe85bad6",
                "patchSummary": "In UsersController::otp(), the inline HOTP verification block (which used the session-cached $user[\u0027hotp_counter\u0027]) is replaced with a call to a new private method __consumeHotp(). This method acquires a Redis SETNX lock (misp:otp:hotp_lock:{userId}, 10 s TTL), re-fetches the user\u0027s totp secret and hotp_counter from the database, verifies the submitted OTP against the stored counter, increments and saves the counter, and releases the lock in a finally block. The otp_user session key is now deleted after both TOTP and HOTP successful login paths. Net change: +36 / -5 lines in app/Controller/UsersController.php.",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "f34aee2c74e111fffd07e8ddde8e4843ccf998db",
                    "date": "Wed, 23 Sep 2026 16:20:38 +0200",
                    "patchSha256": "9ec05e4a3d95b183604c7e89e3fbb93950ac4d23dfe478809b868b6dfe85bad6",
                    "source": "https://github.com/MISP/MISP/commit/f34aee2c7.patch",
                    "sourceUrl": "https://github.com/MISP/MISP/commit/f34aee2c7.patch",
                    "subject": "fix: [security] Burn paper OTP tokens against the stored"
                  }
                ],
                "source": "https://github.com/MISP/MISP/commit/f34aee2c7.patch",
                "ssvc": {
                  "options": [
                    {
                      "Exploitation": "none"
                    },
                    {
                      "Automatable": "no"
                    },
                    {
                      "Technical Impact": "total"
                    }
                  ],
                  "role": "Supplier",
                  "timestamp": "2026-10-01T07:22:27Z",
                  "version": "2.0.3"
                },
                "subject": "fix: [security] Burn paper OTP tokens against the stored",
                "tagVersionBoundary": {
                  "commits_after_fix": 41,
                  "repository": "https://github.com/MISP/MISP",
                  "tag": "v2.5.48",
                  "version": "2.5.48",
                  "version_type": "semver"
                },
                "weaknessRationale": [
                  {
                    "cweId": "CWE-362",
                    "rationale": "The HOTP counter is shared mutable state accessed without synchronization. The session-cached copy becomes stale relative to the database copy, and no lock is held during read-verify-increment, allowing a concurrent or replayed request to operate on the old value."
                  },
                  {
                    "cweId": "CWE-287",
                    "rationale": "The OTP verification logic accepts a token that has already been consumed because it compares against a stale cached counter rather than the authoritative stored counter, effectively weakening the second-factor authentication check."
                  }
                ]
              }
            },
            "bcp-05-x-03": {
              "x_timeline": {
                "events": [
                  {
                    "description": "Corrective change authored (f34aee2c74e111fffd07e8ddde8e4843ccf998db): fix: [security] Burn paper OTP tokens against the stored",
                    "id": "evt-fix-developed-1",
                    "references": [
                      "https://github.com/MISP/MISP/commit/f34aee2c7.patch"
                    ],
                    "timestamp": "2026-09-23T14:20:38Z",
                    "type": "fix-developed"
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "GCVE-1-2026-20307"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
    "assignerShortName": "CIRCL",
    "cveId": "CVE-2026-103651",
    "datePublished": "2026-10-01T07:34:02.597Z",
    "dateReserved": "2026-10-01T07:34:00.794Z",
    "dateUpdated": "2026-10-01T15:32:08.372Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "cpes": [
                  "cpe:2.3:a:misp:misp:*:*:*:*:*:*:*:*"
                ],
                "modules": [
                  "app/Controller/UsersController.php"
                ],
                "product": "MISP",
                "programFiles": [
                  "app/Controller/UsersController.php"
                ],
                "repo": "https://github.com/MISP/MISP",
                "vendor": "MISP",
                "versions": [
                  {
                    "lessThan": "2.5.48",
                    "status": "affected",
                    "version": "0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "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.\n\nThe HOTP verification logic compared the submitted token against a counter value that was cached in the user\u0027s 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.\n\nPreconditions:\n\n- The target user has HOTP (paper token) second-factor authentication enabled.\n\n- The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).\n\n- The attacker has access to at least one HOTP token value (e.g., a paper token list).\n\nSecurity impact:\n\n- Bypass of the second authentication factor, allowing unauthorized access to a user\u0027s MISP account.\n\n- Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.\n\nAffected versions: \u003c2.5.48."
          }
        ],
        "id": "CVE-2026-103651",
        "lastModified": "2026-10-01T16:17:37.313",
        "metrics": {
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "HIGH",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 7.6,
                "baseSeverity": "HIGH",
                "confidentialityRequirement": "NOT_DEFINED",
                "exploitMaturity": "NOT_DEFINED",
                "integrityRequirement": "NOT_DEFINED",
                "modifiedAttackComplexity": "NOT_DEFINED",
                "modifiedAttackRequirements": "NOT_DEFINED",
                "modifiedAttackVector": "NOT_DEFINED",
                "modifiedPrivilegesRequired": "NOT_DEFINED",
                "modifiedSubAvailabilityImpact": "NOT_DEFINED",
                "modifiedSubConfidentialityImpact": "NOT_DEFINED",
                "modifiedSubIntegrityImpact": "NOT_DEFINED",
                "modifiedUserInteraction": "NOT_DEFINED",
                "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
                "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
                "modifiedVulnIntegrityImpact": "NOT_DEFINED",
                "privilegesRequired": "LOW",
                "providerUrgency": "NOT_DEFINED",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "valueDensity": "NOT_DEFINED",
                "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "HIGH",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
              "ssvcData": {
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "Supplier",
                "timestamp": "2026-10-01T07:22:27Z",
                "version": "2.0.3"
              }
            },
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-103651",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-01T15:31:56.170497Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-10-01T08:16:51.020",
        "references": [
          {
            "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
            "url": "https://github.com/MISP/MISP/commit/f34aee2c7"
          }
        ],
        "sourceIdentifier": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-287"
              },
              {
                "lang": "en",
                "value": "CWE-362"
              }
            ],
            "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-103651",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-01T15:31:56.170497Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-01T15:32:04.475Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "cpes": [
                "cpe:2.3:a:misp:misp:*:*:*:*:*:*:*:*"
              ],
              "modules": [
                "app/Controller/UsersController.php"
              ],
              "product": "MISP",
              "programFiles": [
                "app/Controller/UsersController.php"
              ],
              "repo": "https://github.com/MISP/MISP",
              "vendor": "MISP",
              "versions": [
                {
                  "lessThan": "2.5.48",
                  "status": "affected",
                  "version": "0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "reporter",
              "value": "Tanguy Snoeck of NCIA"
            },
            {
              "lang": "en",
              "type": "remediation developer",
              "value": "iglocska"
            },
            {
              "lang": "en",
              "type": "remediation developer",
              "value": "Claude Opus 5.5 (1M context)"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cp\u003eMISP 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.\u003c/p\u003e\u003cp\u003eThe HOTP verification logic compared the submitted token against a counter value that was cached in the user\u0027s 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.\u003c/p\u003e\u003cp\u003ePreconditions:\u003c/p\u003e\u003cp\u003e- The target user has HOTP (paper token) second-factor authentication enabled.\u003c/p\u003e\u003cp\u003e- The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).\u003c/p\u003e\u003cp\u003e- The attacker has access to at least one HOTP token value (e.g., a paper token list).\u003c/p\u003e\u003cp\u003eSecurity impact:\u003c/p\u003e\u003cp\u003e- Bypass of the second authentication factor, allowing unauthorized access to a user\u0027s MISP account.\u003c/p\u003e\u003cp\u003e- Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.\u003c/p\u003e\u003cp\u003eAffected versions: \u0026lt;2.5.48.\u003c/p\u003e"
                }
              ],
              "value": "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.\n\nThe HOTP verification logic compared the submitted token against a counter value that was cached in the user\u0027s 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.\n\nPreconditions:\n\n- The target user has HOTP (paper token) second-factor authentication enabled.\n\n- The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).\n\n- The attacker has access to at least one HOTP token value (e.g., a paper token list).\n\nSecurity impact:\n\n- Bypass of the second authentication factor, allowing unauthorized access to a user\u0027s MISP account.\n\n- Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.\n\nAffected versions: \u003c2.5.48."
            }
          ],
          "impacts": [
            {
              "capecId": "CAPEC-111",
              "descriptions": [
                {
                  "lang": "en",
                  "value": "CAPEC-111 Race Condition"
                }
              ]
            }
          ],
          "metrics": [
            {
              "cvssV4_0": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "HIGH",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "baseScore": 7.6,
                "baseSeverity": "HIGH",
                "privilegesRequired": "LOW",
                "providerUrgency": "NOT_DEFINED",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "valueDensity": "NOT_DEFINED",
                "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "HIGH",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "format": "CVSS",
              "scenarios": [
                {
                  "lang": "en",
                  "value": "GENERAL"
                }
              ]
            },
            {
              "format": "SSVC",
              "other": {
                "content": {
                  "options": [
                    {
                      "Exploitation": "none"
                    },
                    {
                      "Automatable": "no"
                    },
                    {
                      "Technical Impact": "total"
                    }
                  ],
                  "role": "Supplier",
                  "timestamp": "2026-10-01T07:22:27Z",
                  "version": "2.0.3"
                },
                "type": "SSVC"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "GENERAL"
                }
              ]
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-362",
                  "description": "CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-287",
                  "description": "CWE-287 Improper Authentication",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-10-01T07:34:02.597Z",
            "orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
            "shortName": "CIRCL"
          },
          "references": [
            {
              "name": "Security patch",
              "tags": [
                "patch"
              ],
              "url": "https://github.com/MISP/MISP/commit/f34aee2c7"
            }
          ],
          "solutions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cp\u003eThe 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.\u003c/p\u003e"
                }
              ],
              "value": "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."
            }
          ],
          "title": "MISP HOTP Token Replay via Stale Session-Cached Counter Allows Second-Factor Authentication Bypass",
          "x_gcve": [
            {
              "extensions": {
                "bcp-05-x-01": {
                  "ai_annotations": [
                    {
                      "ai_level": "generated",
                      "description": "Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.",
                      "gna_source": 1,
                      "models": [
                        {
                          "gna_source": 1,
                          "identifier": "qwen3.8:27b",
                          "name": "qwen3.8:27b",
                          "source": "ollama"
                        }
                      ],
                      "review_status": "full",
                      "scope": "record",
                      "tags": [
                        "ai-computer-assisted:llm-generated",
                        "ai-computer-assisted:classification"
                      ]
                    }
                  ]
                },
                "bcp-05-x-02": {
                  "x_patch2vuln": {
                    "assumptions": [
                      "The tag_version_boundary metadata (v2.5.48, 41 commits after fix) is interpreted as the first release containing the fix; no explicit fixed_version or affected_version was provided in the metadata.",
                      "The CAPEC-111 mapping is the closest available pattern; the vulnerability is specifically a stale-session-cache replay rather than a classic TOCTOU race, and no more precise CAPEC exists in the catalog.",
                      "CVSS PR:L assumes the attacker already has a valid authenticated session (password step completed); if the threat model requires unauthenticated access, PR would be None but AC would remain High.",
                      "The Redis lock is assumed to be available in the deployment; if Redis is not configured, the locking mechanism may be bypassed, though this is a deployment concern not reflected in the patch.",
                      "The Co-Authored-By line references an AI assistant; it is recorded as a tool credit rather than a human remediation developer."
                    ],
                    "capecRationale": [
                      {
                        "capecId": "CAPEC-111",
                        "rationale": "The vulnerability is exploited by exploiting the time window between the session-cached counter being set (at password entry) and the token being consumed, allowing a replayed token to be validated against the stale value. CAPEC-111 (Race Condition) is the closest available CAPEC pattern; the attack is not a classic TOCTOU on a file or memory location but rather a stale-cache race on a shared counter, which falls under the broader race-condition category. No more specific CAPEC for session-cached credential state replay exists in the CAPEC catalog, so this is the best available match."
                      }
                    ],
                    "commit": "f34aee2c74e111fffd07e8ddde8e4843ccf998db",
                    "confidence": "medium",
                    "credits": [
                      {
                        "lang": "en",
                        "type": "reporter",
                        "value": "Tanguy Snoeck of NCIA"
                      },
                      {
                        "lang": "en",
                        "type": "remediation developer",
                        "value": "iglocska"
                      },
                      {
                        "lang": "en",
                        "type": "remediation developer",
                        "value": "Claude Opus 5.5 (1M context)"
                      }
                    ],
                    "cvssRationale": "AV:N \u2013 MISP is a network-accessible web application. AC:H \u2013 exploitation requires a valid session with the password step already completed, possession of a valid HOTP token value, and the session must still hold the stale cached counter; multiple preconditions must align. AT:N \u2013 no manipulation of the target system is needed. PR:L \u2013 the attacker must be an authenticated user with a pending OTP session. UI:N \u2013 no additional user interaction is required beyond the initial login flow. VC:H \u2013 successful exploitation grants full access to the target user\u0027s MISP account and its data. VI:H \u2013 the attacker can perform any action the user is authorized to perform, and the counter corruption may affect subsequent legitimate authentication. VA:N \u2013 no denial-of-service impact is evident. SC/SI/SA:N \u2013 no secondary system impact is indicated by the patch.",
                    "fixSummary": "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.",
                    "generatedAt": "2026-10-01T07:22:27.568266Z",
                    "generator": "patch2vuln.py",
                    "model": "qwen3.8:27b",
                    "modelComparison": {
                      "rankings": [
                        {
                          "agreementScore": 11,
                          "assumptionCount": 5,
                          "confidence": "medium",
                          "model": "qwen3.8:27b",
                          "score": 7
                        }
                      ],
                      "selectedModel": "qwen3.8:27b",
                      "selectionMethod": "deterministic-consensus-v1",
                      "selectionNotice": "The selected result is closest to model consensus; this heuristic does not establish factual correctness and human review remains required."
                    },
                    "patchSha256": "9ec05e4a3d95b183604c7e89e3fbb93950ac4d23dfe478809b868b6dfe85bad6",
                    "patchSummary": "In UsersController::otp(), the inline HOTP verification block (which used the session-cached $user[\u0027hotp_counter\u0027]) is replaced with a call to a new private method __consumeHotp(). This method acquires a Redis SETNX lock (misp:otp:hotp_lock:{userId}, 10 s TTL), re-fetches the user\u0027s totp secret and hotp_counter from the database, verifies the submitted OTP against the stored counter, increments and saves the counter, and releases the lock in a finally block. The otp_user session key is now deleted after both TOTP and HOTP successful login paths. Net change: +36 / -5 lines in app/Controller/UsersController.php.",
                    "patchTruncated": false,
                    "patches": [
                      {
                        "commit": "f34aee2c74e111fffd07e8ddde8e4843ccf998db",
                        "date": "Wed, 23 Sep 2026 16:20:38 +0200",
                        "patchSha256": "9ec05e4a3d95b183604c7e89e3fbb93950ac4d23dfe478809b868b6dfe85bad6",
                        "source": "https://github.com/MISP/MISP/commit/f34aee2c7.patch",
                        "sourceUrl": "https://github.com/MISP/MISP/commit/f34aee2c7.patch",
                        "subject": "fix: [security] Burn paper OTP tokens against the stored"
                      }
                    ],
                    "source": "https://github.com/MISP/MISP/commit/f34aee2c7.patch",
                    "ssvc": {
                      "options": [
                        {
                          "Exploitation": "none"
                        },
                        {
                          "Automatable": "no"
                        },
                        {
                          "Technical Impact": "total"
                        }
                      ],
                      "role": "Supplier",
                      "timestamp": "2026-10-01T07:22:27Z",
                      "version": "2.0.3"
                    },
                    "subject": "fix: [security] Burn paper OTP tokens against the stored",
                    "tagVersionBoundary": {
                      "commits_after_fix": 41,
                      "repository": "https://github.com/MISP/MISP",
                      "tag": "v2.5.48",
                      "version": "2.5.48",
                      "version_type": "semver"
                    },
                    "weaknessRationale": [
                      {
                        "cweId": "CWE-362",
                        "rationale": "The HOTP counter is shared mutable state accessed without synchronization. The session-cached copy becomes stale relative to the database copy, and no lock is held during read-verify-increment, allowing a concurrent or replayed request to operate on the old value."
                      },
                      {
                        "cweId": "CWE-287",
                        "rationale": "The OTP verification logic accepts a token that has already been consumed because it compares against a stale cached counter rather than the authoritative stored counter, effectively weakening the second-factor authentication check."
                      }
                    ]
                  }
                },
                "bcp-05-x-03": {
                  "x_timeline": {
                    "events": [
                      {
                        "description": "Corrective change authored (f34aee2c74e111fffd07e8ddde8e4843ccf998db): fix: [security] Burn paper OTP tokens against the stored",
                        "id": "evt-fix-developed-1",
                        "references": [
                          "https://github.com/MISP/MISP/commit/f34aee2c7.patch"
                        ],
                        "timestamp": "2026-09-23T14:20:38Z",
                        "type": "fix-developed"
                      }
                    ]
                  }
                }
              },
              "recordType": "advisory",
              "vulnId": "GCVE-1-2026-20307"
            }
          ]
        }
      },
      "cveMetadata": {
        "assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "assignerShortName": "CIRCL",
        "cveId": "CVE-2026-103651",
        "datePublished": "2026-10-01T07:34:02.597Z",
        "dateReserved": "2026-10-01T07:34:00.794Z",
        "dateUpdated": "2026-10-01T15:32:08.372Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…