GCVE-1-2026-20315 (CVE-2026-107276)

Vulnerability from gna-1 – Published: 2026-10-07 15:36 – Updated: 2026-10-07 15:36
VLAI
Title
MISP Email OTP Race Condition Allows One-Time Password to Be Consumed by Multiple Concurrent Requests
Summary
MISP contains a race condition in the email-based one-time password (OTP) login flow. When two HTTP requests carrying the same valid OTP are submitted concurrently, both can successfully authenticate and establish a session. The root cause is that the OTP value is read from the shared store, validated, and then deleted in separate non-atomic steps, allowing a second in-flight request to read the same value before the first request's deletion takes effect. Preconditions: - The target MISP instance has email OTP login enabled. - The attacker possesses a valid, unexpired OTP (e.g., via email interception or social engineering). - The attacker can issue two HTTP POST requests in close temporal proximity. Impact: - The one-time-use guarantee of the OTP is violated; a single code can yield two authenticated sessions. - This weakens the authentication control and may facilitate unauthorized access if the OTP is shared or intercepted. Affected versions: <2.5.48
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
Supplier · CNA (v2.0.3)
Decision recorded 2026-10-07 15:34 UTC
CWE
  • CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)
  • CWE-367 - Time-of-check Time-of-use (TOCTOU) Race Condition
Assigner
GNA-1 This instance Scorecard
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-07 15:34
Model
qwen3.8:27b
Input
https://github.com/MISP/MISP/commit/ba95e67d5.patch 810e97a648a3…
Confidence
medium
Commit Subject Patch SHA-256
ba95e67d545e fix: [login] Let only one request spend an e-mailed OTP 810e97a648a3…
Fix summary

The fix makes OTP consumption atomic by moving the deletion of the OTP from the shared store into the validation condition itself. The return value of the delete operation (1 if the key was actually removed, 0 otherwise) is now part of the success check, so only the request that successfully removes the OTP from the store is permitted to proceed with login. A session-state cleanup call was also added to remove the OTP user reference from the session.

Patch summary

In UsersController::email_otp(), the $redis->del() call was moved from after the hash_equals comparison into the if-condition as an additional conjunct. The condition now requires $redis->del('misp:otp:' . $user_id) === 1, meaning only the request whose delete actually removed the key (returning 1) can proceed to Auth->login(). A $this->Session->delete('email_otp_user') call was added before the login step to clean up session state. Net change: 6 insertions, 3 deletions in one file.

CVSS rationale

AV:N: Exploitation occurs over the network via HTTP POST. AC:H: Exploiting the race condition requires precise timing of two concurrent requests so both read the OTP before either deletes it; this is non-trivial to achieve reliably. AT:N: No data corruption or manipulation is required. PR:N: The attacker does not need prior authentication to MISP; they only need possession of a valid OTP (e.g., intercepted email). UI:N: No victim interaction beyond the initial login flow is needed. VC:N: No direct confidentiality loss of system data. VI:L: The one-time-use property of the OTP is violated, allowing a second authenticated session. VA:N: No availability impact. SC/SI:L: Limited integrity impact on the authentication process; no cross-system impact. SA:N: No impact on security authority.

Weakness rationale
  • CWE-362 The OTP stored in Redis is a shared resource accessed by concurrent HTTP requests. The original code performed read, compare, and delete as separate non-atomic operations, allowing two concurrent requests to both read and validate the same OTP before either deletes it. This is a textbook race condition on a shared resource.
  • CWE-367 The check (reading and comparing the OTP) and the use (logging in) are separated in time, and the state (OTP presence in the store) can change between the two steps due to a concurrent request. This is a TOCTOU variant of the race condition.
Attack pattern rationale
  • CAPEC-111 The attack pattern involves an adversary issuing two or more concurrent requests to exploit a non-atomic check-and-use sequence on a shared resource (the OTP in Redis). CAPEC-111 directly describes exploiting timing dependencies between sub-processes. This is the closest CAPEC to the observed vulnerability; no more specific CAPEC for OTP replay via race condition exists in the CAPEC catalog.
Assumptions to verify
  • The exact affected version range is not explicitly stated in the patch; the tag boundary v2.5.48 with 39 commits after the fix suggests the fix landed shortly after that tag, but the precise first-fixed version is unconfirmed.
  • The CAPEC-111 mapping is the closest available; no CAPEC specifically covers OTP replay via race condition, so this is the best-fit pattern.
  • CVSS AC:H assumes the race window is narrow and requires precise timing; if the Redis round-trip latency is large, exploitation may be easier, but no evidence supports lowering AC.
  • The commit message states the issue was 'found during the internal review, not externally reported,' but no specific individual is named as finder, so no finder credit is assigned.
  • PR:N assumes the attacker obtains the OTP through out-of-band means (email interception); if MISP requires prior authentication to request an OTP, PR could be L.
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:26 UTC Fix developed Corrective change authored (ba95e67d545efa313435ae39dd481879d72e72e6): fix: [login] Let only one request spend an e-mailed OTP https://github.com/MISP/MISP/commit/ba95e67d5.patch

{
  "containers": {
    "cna": {
      "affected": [
        {
          "cpes": [
            "cpe:2.3:a:misp:misp:*:*:*:*:*:*:*:*"
          ],
          "modules": [
            "UsersController (email OTP login)"
          ],
          "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": "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 race condition in the email-based one-time password (OTP) login flow. When two HTTP requests carrying the same valid OTP are submitted concurrently, both can successfully authenticate and establish a session. The root cause is that the OTP value is read from the shared store, validated, and then deleted in separate non-atomic steps, allowing a second in-flight request to read the same value before the first request\u0027s deletion takes effect.\u003c/p\u003e\u003cp\u003ePreconditions:\u003c/p\u003e\u003cp\u003e- The target MISP instance has email OTP login enabled.\u003c/p\u003e\u003cp\u003e- The attacker possesses a valid, unexpired OTP (e.g., via email interception or social engineering).\u003c/p\u003e\u003cp\u003e- The attacker can issue two HTTP POST requests in close temporal proximity.\u003c/p\u003e\u003cp\u003eImpact:\u003c/p\u003e\u003cp\u003e- The one-time-use guarantee of the OTP is violated; a single code can yield two authenticated sessions.\u003c/p\u003e\u003cp\u003e- This weakens the authentication control and may facilitate unauthorized access if the OTP is shared or intercepted.\u003c/p\u003e\u003cp\u003eAffected versions: \u0026lt;2.5.48\u003c/p\u003e"
            }
          ],
          "value": "MISP contains a race condition in the email-based one-time password (OTP) login flow. When two HTTP requests carrying the same valid OTP are submitted concurrently, both can successfully authenticate and establish a session. The root cause is that the OTP value is read from the shared store, validated, and then deleted in separate non-atomic steps, allowing a second in-flight request to read the same value before the first request\u0027s deletion takes effect.\n\nPreconditions:\n\n- The target MISP instance has email OTP login enabled.\n\n- The attacker possesses a valid, unexpired OTP (e.g., via email interception or social engineering).\n\n- The attacker can issue two HTTP POST requests in close temporal proximity.\n\nImpact:\n\n- The one-time-use guarantee of the OTP is violated; a single code can yield two authenticated sessions.\n\n- This weakens the authentication control and may facilitate unauthorized access if the OTP is shared or intercepted.\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": 6.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "format": "SSVC",
          "other": {
            "content": {
              "options": [
                {
                  "Exploitation": "none"
                },
                {
                  "Automatable": "yes"
                },
                {
                  "Technical Impact": "partial"
                }
              ],
              "role": "Supplier",
              "timestamp": "2026-10-07T15:34:47Z",
              "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-367",
              "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "orgId": "00000000-0000-4000-9000-000000000000"
      },
      "references": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/MISP/MISP/commit/ba95e67d5"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe fix makes OTP consumption atomic by moving the deletion of the OTP from the shared store into the validation condition itself. The return value of the delete operation (1 if the key was actually removed, 0 otherwise) is now part of the success check, so only the request that successfully removes the OTP from the store is permitted to proceed with login. A session-state cleanup call was also added to remove the OTP user reference from the session.\u003c/p\u003e"
            }
          ],
          "value": "The fix makes OTP consumption atomic by moving the deletion of the OTP from the shared store into the validation condition itself. The return value of the delete operation (1 if the key was actually removed, 0 otherwise) is now part of the success check, so only the request that successfully removes the OTP from the store is permitted to proceed with login. A session-state cleanup call was also added to remove the OTP user reference from the session."
        }
      ],
      "title": "MISP Email OTP Race Condition Allows One-Time Password to Be Consumed by Multiple Concurrent Requests",
      "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 exact affected version range is not explicitly stated in the patch; the tag boundary v2.5.48 with 39 commits after the fix suggests the fix landed shortly after that tag, but the precise first-fixed version is unconfirmed.",
                  "The CAPEC-111 mapping is the closest available; no CAPEC specifically covers OTP replay via race condition, so this is the best-fit pattern.",
                  "CVSS AC:H assumes the race window is narrow and requires precise timing; if the Redis round-trip latency is large, exploitation may be easier, but no evidence supports lowering AC.",
                  "The commit message states the issue was \u0027found during the internal review, not externally reported,\u0027 but no specific individual is named as finder, so no finder credit is assigned.",
                  "PR:N assumes the attacker obtains the OTP through out-of-band means (email interception); if MISP requires prior authentication to request an OTP, PR could be L."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-111",
                    "rationale": "The attack pattern involves an adversary issuing two or more concurrent requests to exploit a non-atomic check-and-use sequence on a shared resource (the OTP in Redis). CAPEC-111 directly describes exploiting timing dependencies between sub-processes. This is the closest CAPEC to the observed vulnerability; no more specific CAPEC for OTP replay via race condition exists in the CAPEC catalog."
                  }
                ],
                "commit": "ba95e67d545efa313435ae39dd481879d72e72e6",
                "confidence": "medium",
                "credits": [
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "iglocska"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Claude Opus 5.5 (1M context)"
                  }
                ],
                "cvssRationale": "AV:N: Exploitation occurs over the network via HTTP POST. AC:H: Exploiting the race condition requires precise timing of two concurrent requests so both read the OTP before either deletes it; this is non-trivial to achieve reliably. AT:N: No data corruption or manipulation is required. PR:N: The attacker does not need prior authentication to MISP; they only need possession of a valid OTP (e.g., intercepted email). UI:N: No victim interaction beyond the initial login flow is needed. VC:N: No direct confidentiality loss of system data. VI:L: The one-time-use property of the OTP is violated, allowing a second authenticated session. VA:N: No availability impact. SC/SI:L: Limited integrity impact on the authentication process; no cross-system impact. SA:N: No impact on security authority.",
                "fixSummary": "The fix makes OTP consumption atomic by moving the deletion of the OTP from the shared store into the validation condition itself. The return value of the delete operation (1 if the key was actually removed, 0 otherwise) is now part of the success check, so only the request that successfully removes the OTP from the store is permitted to proceed with login. A session-state cleanup call was also added to remove the OTP user reference from the session.",
                "generatedAt": "2026-10-07T15:34:47.392474Z",
                "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": "810e97a648a36f87d684f509c51c93636711a31daeab31c5bccbc9466249a7e0",
                "patchSummary": "In UsersController::email_otp(), the $redis-\u003edel() call was moved from after the hash_equals comparison into the if-condition as an additional conjunct. The condition now requires $redis-\u003edel(\u0027misp:otp:\u0027 . $user_id) === 1, meaning only the request whose delete actually removed the key (returning 1) can proceed to Auth-\u003elogin(). A $this-\u003eSession-\u003edelete(\u0027email_otp_user\u0027) call was added before the login step to clean up session state. Net change: 6 insertions, 3 deletions in one file.",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "ba95e67d545efa313435ae39dd481879d72e72e6",
                    "date": "Wed, 23 Sep 2026 16:26:22 +0200",
                    "patchSha256": "810e97a648a36f87d684f509c51c93636711a31daeab31c5bccbc9466249a7e0",
                    "source": "https://github.com/MISP/MISP/commit/ba95e67d5.patch",
                    "sourceUrl": "https://github.com/MISP/MISP/commit/ba95e67d5.patch",
                    "subject": "fix: [login] Let only one request spend an e-mailed OTP"
                  }
                ],
                "source": "https://github.com/MISP/MISP/commit/ba95e67d5.patch",
                "ssvc": {
                  "options": [
                    {
                      "Exploitation": "none"
                    },
                    {
                      "Automatable": "yes"
                    },
                    {
                      "Technical Impact": "partial"
                    }
                  ],
                  "role": "Supplier",
                  "timestamp": "2026-10-07T15:34:47Z",
                  "version": "2.0.3"
                },
                "subject": "fix: [login] Let only one request spend an e-mailed OTP",
                "tagVersionBoundary": {
                  "commits_after_fix": 39,
                  "repository": "https://github.com/MISP/MISP",
                  "tag": "v2.5.48",
                  "version": "2.5.48",
                  "version_type": "semver"
                },
                "weaknessRationale": [
                  {
                    "cweId": "CWE-362",
                    "rationale": "The OTP stored in Redis is a shared resource accessed by concurrent HTTP requests. The original code performed read, compare, and delete as separate non-atomic operations, allowing two concurrent requests to both read and validate the same OTP before either deletes it. This is a textbook race condition on a shared resource."
                  },
                  {
                    "cweId": "CWE-367",
                    "rationale": "The check (reading and comparing the OTP) and the use (logging in) are separated in time, and the state (OTP presence in the store) can change between the two steps due to a concurrent request. This is a TOCTOU variant of the race condition."
                  }
                ]
              }
            },
            "bcp-05-x-03": {
              "x_timeline": {
                "events": [
                  {
                    "description": "Corrective change authored (ba95e67d545efa313435ae39dd481879d72e72e6): fix: [login] Let only one request spend an e-mailed OTP",
                    "id": "evt-fix-developed-1",
                    "references": [
                      "https://github.com/MISP/MISP/commit/ba95e67d5.patch"
                    ],
                    "timestamp": "2026-09-23T14:26:22Z",
                    "type": "fix-developed"
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "GCVE-1-2026-20315"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "00000000-0000-4000-9000-000000000000",
    "cveId": "CVE-2026-107276",
    "datePublished": "2026-10-07T15:36:37.527318Z",
    "dateReserved": "2026-10-07T15:36:46.122Z",
    "dateUpdated": "2026-10-07T15:36:46.202908Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1-2026-20315"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}



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…