{"api_version":"1","generated_at":"2026-10-01T17:12:03+00:00","cve":"CVE-2026-103655","urls":{"html":"https://cve.report/CVE-2026-103655","api":"https://cve.report/api/cve/CVE-2026-103655.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-103655","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-103655"},"summary":{"title":"MISP TOTP Code Replay Allows Duplicate Authentication Within Validity Period","description":"MISP contains a vulnerability in its two-factor authentication (TOTP) verification process that permits a valid one-time code to be accepted more than once within its time-based validity window.\n\nThe issue exists in the user login flow where a TOTP code is verified as a second authentication factor. Because the system did not record whether a given TOTP period had already been consumed, the same code remained valid for its entire time window (typically 30 seconds). An attacker who captures a legitimate code during a user's login could replay it to authenticate a second session as that user.\n\nPreconditions:\n\n- The target user has TOTP-based two-factor authentication enabled.\n\n- The attacker is in a position to observe or intercept the TOTP code during a legitimate login (e.g., network-level interception, shoulder surfing, or a compromised client).\n\n- The replay must occur within the TOTP validity period.\n\nSecurity impact:\n\n- Unauthorized account access by replaying a captured one-time code.\n\n- Potential compromise of threat-intelligence data and administrative functions accessible to the targeted user.\n\nAffected versions: MISP contains a vulnerability in its two-factor authentication (TOTP) verification process that permits a valid one-time code to be accepted more than once within its time-based validity window.

The issue exists in the user login flow where a TOTP code is verified as a second authentication factor. Because the system did not record whether a given TOTP period had already been consumed, the same code remained valid for its entire time window (typically 30 seconds). An attacker who captures a legitimate code during a user's login could replay it to authenticate a second session as that user.

Preconditions:

- The target user has TOTP-based two-factor authentication enabled.

- The attacker is in a position to observe or intercept the TOTP code during a legitimate login (e.g., network-level interception, shoulder surfing, or a compromised client).

- The replay must occur within the TOTP validity period.

Security impact:

- Unauthorized account access by replaying a captured one-time code.

- Potential compromise of threat-intelligence data and administrative functions accessible to the targeted user.

Affected versions: <v2.5.48.

"}],"value":"MISP contains a vulnerability in its two-factor authentication (TOTP) verification process that permits a valid one-time code to be accepted more than once within its time-based validity window.\n\nThe issue exists in the user login flow where a TOTP code is verified as a second authentication factor. Because the system did not record whether a given TOTP period had already been consumed, the same code remained valid for its entire time window (typically 30 seconds). An attacker who captures a legitimate code during a user's login could replay it to authenticate a second session as that user.\n\nPreconditions:\n\n- The target user has TOTP-based two-factor authentication enabled.\n\n- The attacker is in a position to observe or intercept the TOTP code during a legitimate login (e.g., network-level interception, shoulder surfing, or a compromised client).\n\n- The replay must occur within the TOTP validity period.\n\nSecurity impact:\n\n- Unauthorized account access by replaying a captured one-time code.\n\n- Potential compromise of threat-intelligence data and administrative functions accessible to the targeted user.\n\nAffected versions: The fix introduces a single-use enforcement mechanism for TOTP codes. Upon successful verification, the system records the TOTP period step in a Redis key scoped to the user and step number, using a SET-NX (set-if-not-exists) operation with a TTL of three times the TOTP period. Any subsequent attempt to authenticate with a code from the same period will fail the SET-NX check and be rejected, effectively making each TOTP code single-use within its validity window.

"}],"value":"The fix introduces a single-use enforcement mechanism for TOTP codes. Upon successful verification, the system records the TOTP period step in a Redis key scoped to the user and step number, using a SET-NX (set-if-not-exists) operation with a TTL of three times the TOTP period. Any subsequent attempt to authenticate with a code from the same period will fail the SET-NX check and be rejected, effectively making each TOTP code single-use within its validity window."}],"title":"MISP TOTP Code Replay Allows Duplicate Authentication Within Validity Period","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 affected version range is inferred from the tag_version_boundary (v2.5.48, 40 commits after fix); the exact first affected version is not stated in the patch metadata and is recorded as unspecified.","The TOTP validity period is assumed to be the standard 30 seconds based on the OTPHP library default; the patch does not hard-code a specific period value.","The CAPEC-122 mapping is the closest available pattern; no CAPEC specifically addresses one-time-code replay, so the mapping carries uncertainty.","CVSS AC is rated High because exploitation requires intercepting a valid TOTP code during a live login and replaying it within a short time window; if the attacker already possesses the code (e.g., via a compromised client), complexity would be lower.","The Redis dependency for the fix is assumed to be available in the deployment; if Redis is unavailable, the fix's behavior is not specified in the patch.","The Co-Authored-By line references an AI tool (Claude Opus 5.5); it is credited as a tool rather than a human remediation developer."],"capecRationale":[{"capecId":"CAPEC-122","rationale":"The closest available CAPEC pattern is Session Hijacking, as the attacker gains unauthorized access to a user's authenticated session by replaying a captured credential (the TOTP code). The mapping is imperfect because the attack targets a one-time authentication token rather than a persistent session identifier, and the window is very short (one TOTP period). No CAPEC specifically covers one-time-code replay, so CAPEC-122 is the best available match."}],"commit":"a020fa47b6c3cb5b43d841afe2ccf149889fad6b","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: the TOTP code is transmitted over the network during login. AC:H: exploitation requires the attacker to intercept a valid TOTP code during a legitimate login and replay it within the short validity window (typically 30 s), which is a non-trivial timing and positioning requirement. AT:N: no manipulation of the target system is needed. PR:N: the attacker is unauthenticated. UI:N: no user interaction beyond the victim's normal login is required. VC:H / VI:H: successful exploitation grants full access to the targeted user's account, including threat-intelligence data and administrative capabilities. VA:L: the attacker could disrupt services by modifying or deleting data. SC/SI/SA:N: no impact on secondary systems is evidenced.","fixSummary":"The fix introduces a single-use enforcement mechanism for TOTP codes. Upon successful verification, the system records the TOTP period step in a Redis key scoped to the user and step number, using a SET-NX (set-if-not-exists) operation with a TTL of three times the TOTP period. Any subsequent attempt to authenticate with a code from the same period will fail the SET-NX check and be rejected, effectively making each TOTP code single-use within its validity window.","generatedAt":"2026-10-01T07:52:44.000034Z","generator":"patch2vuln.py","model":"qwen3.8:27b","modelComparison":{"rankings":[{"agreementScore":11,"assumptionCount":6,"confidence":"medium","model":"qwen3.8:27b","score":6}],"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":"6fce2d1f789e3b4c0cbb7b4d81079334f66f1707bb5422f49915393cab88143f","patchSummary":"In app/Controller/UsersController.php, the otp() method was modified to capture the current timestamp and pass it to the TOTP verify call. A new private method __claimTotpStep() was added, which computes the TOTP step (intdiv of elapsed time over period), constructs a Redis key of the form misp:otp:totp_used:{userId}:{step}, and attempts a SET with NX and EX (3x period) flags via RedisTool. The login proceeds only if both the TOTP verification and the claim succeed. Thirteen lines added, one line modified.","patchTruncated":false,"patches":[{"commit":"a020fa47b6c3cb5b43d841afe2ccf149889fad6b","date":"Wed, 23 Sep 2026 16:24:44 +0200","patchSha256":"6fce2d1f789e3b4c0cbb7b4d81079334f66f1707bb5422f49915393cab88143f","source":"https://github.com/MISP/MISP/commit/a020fa47b.patch","sourceUrl":"https://github.com/MISP/MISP/commit/a020fa47b.patch","subject":"fix: [security] Refuse a TOTP code that was already used to"}],"source":"https://github.com/MISP/MISP/commit/a020fa47b.patch","ssvc":{"options":[{"Exploitation":"none"},{"Automatable":"yes"},{"Technical Impact":"total"}],"role":"Supplier","timestamp":"2026-10-01T07:52:44Z","version":"2.0.3"},"subject":"fix: [security] Refuse a TOTP code that was already used to","tagVersionBoundary":{"commits_after_fix":40,"repository":"https://github.com/MISP/MISP","tag":"v2.5.48","version":"2.5.48","version_type":"semver"},"weaknessRationale":[{"cweId":"CWE-294","rationale":"The TOTP verification logic accepted the same code multiple times within its validity period because no state was tracked to mark a period as consumed. This is a logical flaw in the authentication mechanism that permits replay of a valid one-time credential, fitting CWE-294 more precisely than the broader CWE-287."}]}},"bcp-05-x-03":{"x_timeline":{"events":[{"description":"Corrective change authored (a020fa47b6c3cb5b43d841afe2ccf149889fad6b): fix: [security] Refuse a TOTP code that was already used to","id":"evt-fix-developed-1","references":["https://github.com/MISP/MISP/commit/a020fa47b.patch"],"timestamp":"2026-09-23T14:24:44Z","type":"fix-developed"}]}}},"recordType":"advisory","vulnId":"GCVE-1-2026-20194"}]}},"cveMetadata":{"assignerOrgId":"5a6e4751-2f3f-4070-9419-94fb35b644e8","assignerShortName":"CIRCL","cveId":"CVE-2026-103655","datePublished":"2026-10-01T08:08:55.013Z","dateReserved":"2026-10-01T08:08:52.909Z","dateUpdated":"2026-10-01T15:25:55.269Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-01 09:17:07","lastModifiedDate":"2026-10-01 16:17:37","problem_types":["CWE-294","CWE-294 CWE-294 Authentication Bypass via Logical Flaw"],"metrics":{"cvssMetricV40":[{"source":"5a6e4751-2f3f-4070-9419-94fb35b644e8","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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","baseScore":9.3,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"ssvcV203":[{"source":"5a6e4751-2f3f-4070-9419-94fb35b644e8","ssvcData":{"timestamp":"2026-10-01T07:52:43Z","options":[{"exploitation":"none"},{"automatable":"yes"},{"technicalImpact":"total"}],"role":"Supplier","version":"2.0.3"}},{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-10-01T15:25:45.460434Z","id":"CVE-2026-103655","options":[{"exploitation":"none"},{"automatable":"yes"},{"technicalImpact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"103655","Ordinal":"1","Title":"MISP TOTP Code Replay Allows Duplicate Authentication Within Val","CVE":"CVE-2026-103655","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"103655","Ordinal":"1","NoteData":"MISP contains a vulnerability in its two-factor authentication (TOTP) verification process that permits a valid one-time code to be accepted more than once within its time-based validity window.\n\nThe issue exists in the user login flow where a TOTP code is verified as a second authentication factor. Because the system did not record whether a given TOTP period had already been consumed, the same code remained valid for its entire time window (typically 30 seconds). An attacker who captures a legitimate code during a user's login could replay it to authenticate a second session as that user.\n\nPreconditions:\n\n- The target user has TOTP-based two-factor authentication enabled.\n\n- The attacker is in a position to observe or intercept the TOTP code during a legitimate login (e.g., network-level interception, shoulder surfing, or a compromised client).\n\n- The replay must occur within the TOTP validity period.\n\nSecurity impact:\n\n- Unauthorized account access by replaying a captured one-time code.\n\n- Potential compromise of threat-intelligence data and administrative functions accessible to the targeted user.\n\nAffected versions: