Vulnerability-Lookup

GHSA-J3GX-2Q66-WG27

Vulnerability from github – Published: 2026-09-27 15:31 – Updated: 2026-09-27 15:31

Details

A secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form's validation logic, bypassing the intended minimum-length and complexity constraints.

The affected component is the user account recovery endpoint (/user/confirm_account/) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py).

Severity

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-101041"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T15:16:27Z",
    "severity": "MODERATE"
  },
  "details": "The account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user\u0027s password with one of their choosing.\n\nA secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form\u0027s validation logic, bypassing the intended minimum-length and complexity constraints.\n\nThe affected component is the user account recovery endpoint (/user/confirm_account/\u003ctoken\u003e) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py).",
  "id": "GHSA-j3gx-2q66-wg27",
  "modified": "2026-09-27T15:31:08Z",
  "published": "2026-09-27T15:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101041"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/5462bab62d76df852619e01eb67da36c023c8c40"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/ad6f22882975516adf193a1a920aaa54025c71d4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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",
      "type": "CVSS_V4"
    }
  ]
}

CVE-2026-101041 (GCVE-0-2026-101041)

Vulnerability from cvelistv5 – Published: 2026-09-27 14:47 – Updated: 2026-09-27 14:47

Title

Vulnerability-Lookup - Race Condition in Account Recovery Token Consumption Allows Password Takeover

Summary

The account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user's password with one of their choosing. A secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form's validation logic, bypassing the intended minimum-length and complexity constraints. The affected component is the user account recovery endpoint (/user/confirm_account/<token>) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py).

Severity

6.3 (Medium)


                        
                          CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

CWE

CWE-362 - Concurrency: Race Condition
CWE-20 - Improper Input Validation

Assigner

CIRCL ENISA root

References

2 references

URL	Tags
https://github.com/vulnerability-lookup/vulnerabi…	patch
https://github.com/vulnerability-lookup/vulnerabi…	patch

Impacted products

1 product

Vendor	Product	Version
vulnerability-lookup	vulnerability-lookup	Affected: 0 , ≤ 6.2.0 (semver)

Credits

Alexandre Dulaunoy Cédric Bonhomme Claude Fable 5.1 avrlab233

GCVE extensions

AI-generated Partially reviewed Confidence: medium Model qwen3.8:27b advisory bcp-05-x-01bcp-05-x-02

AI involvement GCVE-BCP-05-X-01

Whole record AI-generated Partially 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`

Patch provenance GCVE-BCP-05-X-02

Generator: patch2vuln.py on 2026-09-27 14:43
Model: qwen3.8:27b
Input: patch set (2 sources) ccb7572963e8…
Confidence: medium

Commit	Subject	Patch SHA-256
`5462bab62d76`	Fix recovery token consumption race	`75ed8b215e27…`
`ad6f22882975`	fix: [user] Validate the recovery form and harden the token	`c1cecff5ac5f…`

Fix summary

The non-atomic check-then-consume pattern is replaced with a single conditional UPDATE statement (compare-and-set) that atomically verifies the stored SHA-256 nonce digest, updates the password hash, sets is_confirmed, and clears the token in one database operation. Only the first transaction to commit succeeds; all concurrent attempts match zero rows and are rejected with an error. The view now calls form.validate() before processing the password change, enforcing the form's length and equality validators. The dead consume_account_token() method is removed to eliminate the non-atomic consumption path entirely.

Patch summary

Added reset_password_with_account_token() to the User model performing a single conditional UPDATE (WHERE id = ? AND account_token_digest = sha256(nonce)) that sets pwdhash, is_confirmed=True, and account_token_digest=None atomically. Removed the separate consume_account_token() method. Changed the confirm_account view to call form.validate() instead of only comparing password1 and password2 manually. Introduced a _account_token_digest() static helper to centralize the SHA-256 computation (previously three inline calls). Removed synchronize_session=False from the UPDATE execution options so the ORM session stays consistent. Added regression tests for concurrent token consumption (two threads, barrier-synchronized) and for rejection of passwords that fail form validation (empty, three-character, mismatched).

CVSS rationale

AV:N: the recovery endpoint is reachable over the network. AC:H: exploiting the race condition requires precise timing of two concurrent requests, making the attack condition high complexity. AT:N: no active user interaction or deception is required beyond possessing a valid token. PR:N: no prior authentication is needed; the recovery token itself is the credential. UI:N: no user interaction is required. VC:N: the vulnerability does not directly expose confidential data. VI:H: the integrity of the user's password (a critical credential) is directly compromised. VA:N: no availability impact. SC:N: the impact is confined to the vulnerable component. SI:H: the integrity of the user's account (password, confirmation state) is compromised, affecting the user's ability to access their own account. SA:N: no security-authority impact.

Weakness rationale

CWE-362 The primary defect is a TOCTOU race: the token nonce is verified and then consumed in separate operations, allowing two concurrent transactions to both pass verification before either commits. The fix replaces this with an atomic compare-and-set UPDATE, confirming the race condition as the root cause.
CWE-20 The confirm_account view never called form.validate() on POST, so the form's minimum-length and equality validators were bypassed. A valid recovery link alone permitted setting an empty or three-character password. The fix adds the form.validate() call before processing.

Attack pattern rationale

CAPEC-111 The attacker exploits the window between token verification and token consumption by issuing a concurrent request with the same token. Both requests pass the check; the last to commit overwrites the first's password. This is a textbook race-condition attack on a shared resource (the single-use token). CAPEC-111 is the closest available pattern; no CAPEC specifically covers TOCTOU on database-level token consumption, so this is the best match.

Assumptions to verify

The product version and exact release boundary are not specified in the patch metadata; the affected version range is recorded as unspecified.
The CAPEC-111 mapping is the closest available pattern for a database-level TOCTOU race on a single-use token; no CAPEC specifically describes concurrent compare-and-set exploitation, so this is the best available match.
The CVSS AC:H reflects the race-condition aspect; the missing-validation aspect alone would be AC:L, but the patch set is treated as one vulnerability per the caller's instruction.
The vendor is not explicitly identified in the metadata; the GitHub repository name 'vulnerability-lookup' is used as the product identifier.
No specific authentication or deployment preconditions beyond possession of a valid recovery token are stated in the patch; the token is assumed to be delivered out-of-band (e.g., email).
The Co-Authored-By line for Claude Fable 5.1 is treated as a remediation developer credit per the metadata's remediation_developers list; no finder or reporter is identified in the supplied evidence.

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`	4	9	medium	6

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "modules": [
            "website/models/user.py",
            "website/web/views/user.py",
            "website/lib/user_utils.py"
          ],
          "product": "vulnerability-lookup",
          "programFiles": [
            "website/models/user.py",
            "website/web/views/user.py",
            "website/lib/user_utils.py"
          ],
          "repo": "https://github.com/vulnerability-lookup/vulnerability-lookup",
          "vendor": "vulnerability-lookup",
          "versions": [
            {
              "lessThanOrEqual": "6.2.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Alexandre Dulaunoy"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "C\u00e9dric Bonhomme"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Claude Fable 5.1"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "avrlab233"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user\u0027s password with one of their choosing.\u003c/p\u003e\u003cp\u003eA secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form\u0027s validation logic, bypassing the intended minimum-length and complexity constraints.\u003c/p\u003e\u003cp\u003eThe affected component is the user account recovery endpoint (/user/confirm_account/\u0026lt;token\u0026gt;) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py).\u003c/p\u003e"
            }
          ],
          "value": "The account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user\u0027s password with one of their choosing.\n\nA secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form\u0027s validation logic, bypassing the intended minimum-length and complexity constraints.\n\nThe affected component is the user account recovery endpoint (/user/confirm_account/\u003ctoken\u003e) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py)."
        }
      ],
      "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": "LOW",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-362",
              "description": "CWE-362 Concurrency: Race Condition",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-27T14:47:57.012Z",
        "orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "shortName": "CIRCL"
      },
      "references": [
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/5462bab62d76df852619e01eb67da36c023c8c40"
        },
        {
          "name": "Security patch",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/ad6f22882975516adf193a1a920aaa54025c71d4"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe non-atomic check-then-consume pattern is replaced with a single conditional UPDATE statement (compare-and-set) that atomically verifies the stored SHA-256 nonce digest, updates the password hash, sets is_confirmed, and clears the token in one database operation. Only the first transaction to commit succeeds; all concurrent attempts match zero rows and are rejected with an error. The view now calls form.validate() before processing the password change, enforcing the form\u0027s length and equality validators. The dead consume_account_token() method is removed to eliminate the non-atomic consumption path entirely.\u003c/p\u003e"
            }
          ],
          "value": "The non-atomic check-then-consume pattern is replaced with a single conditional UPDATE statement (compare-and-set) that atomically verifies the stored SHA-256 nonce digest, updates the password hash, sets is_confirmed, and clears the token in one database operation. Only the first transaction to commit succeeds; all concurrent attempts match zero rows and are rejected with an error. The view now calls form.validate() before processing the password change, enforcing the form\u0027s length and equality validators. The dead consume_account_token() method is removed to eliminate the non-atomic consumption path entirely."
        }
      ],
      "title": "Vulnerability-Lookup - Race Condition in Account Recovery Token Consumption Allows Password Takeover",
      "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": "partial",
                  "scope": "record",
                  "tags": [
                    "ai-computer-assisted:llm-generated",
                    "ai-computer-assisted:classification"
                  ]
                }
              ]
            },
            "bcp-05-x-02": {
              "x_patch2vuln": {
                "assumptions": [
                  "The product version and exact release boundary are not specified in the patch metadata; the affected version range is recorded as unspecified.",
                  "The CAPEC-111 mapping is the closest available pattern for a database-level TOCTOU race on a single-use token; no CAPEC specifically describes concurrent compare-and-set exploitation, so this is the best available match.",
                  "The CVSS AC:H reflects the race-condition aspect; the missing-validation aspect alone would be AC:L, but the patch set is treated as one vulnerability per the caller\u0027s instruction.",
                  "The vendor is not explicitly identified in the metadata; the GitHub repository name \u0027vulnerability-lookup\u0027 is used as the product identifier.",
                  "No specific authentication or deployment preconditions beyond possession of a valid recovery token are stated in the patch; the token is assumed to be delivered out-of-band (e.g., email).",
                  "The Co-Authored-By line for Claude Fable 5.1 is treated as a remediation developer credit per the metadata\u0027s remediation_developers list; no finder or reporter is identified in the supplied evidence."
                ],
                "capecRationale": [
                  {
                    "capecId": "CAPEC-111",
                    "rationale": "The attacker exploits the window between token verification and token consumption by issuing a concurrent request with the same token. Both requests pass the check; the last to commit overwrites the first\u0027s password. This is a textbook race-condition attack on a shared resource (the single-use token). CAPEC-111 is the closest available pattern; no CAPEC specifically covers TOCTOU on database-level token consumption, so this is the best match."
                  }
                ],
                "commit": "ad6f22882975516adf193a1a920aaa54025c71d4",
                "confidence": "medium",
                "credits": [
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Alexandre Dulaunoy"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "C\u00e9dric Bonhomme"
                  },
                  {
                    "lang": "en",
                    "type": "remediation developer",
                    "value": "Claude Fable 5.1"
                  }
                ],
                "cvssRationale": "AV:N: the recovery endpoint is reachable over the network. AC:H: exploiting the race condition requires precise timing of two concurrent requests, making the attack condition high complexity. AT:N: no active user interaction or deception is required beyond possessing a valid token. PR:N: no prior authentication is needed; the recovery token itself is the credential. UI:N: no user interaction is required. VC:N: the vulnerability does not directly expose confidential data. VI:H: the integrity of the user\u0027s password (a critical credential) is directly compromised. VA:N: no availability impact. SC:N: the impact is confined to the vulnerable component. SI:H: the integrity of the user\u0027s account (password, confirmation state) is compromised, affecting the user\u0027s ability to access their own account. SA:N: no security-authority impact.",
                "fixSummary": "The non-atomic check-then-consume pattern is replaced with a single conditional UPDATE statement (compare-and-set) that atomically verifies the stored SHA-256 nonce digest, updates the password hash, sets is_confirmed, and clears the token in one database operation. Only the first transaction to commit succeeds; all concurrent attempts match zero rows and are rejected with an error. The view now calls form.validate() before processing the password change, enforcing the form\u0027s length and equality validators. The dead consume_account_token() method is removed to eliminate the non-atomic consumption path entirely.",
                "generatedAt": "2026-09-27T14:43:09.207406Z",
                "generator": "patch2vuln.py",
                "model": "qwen3.8:27b",
                "modelComparison": {
                  "rankings": [
                    {
                      "agreementScore": 9,
                      "assumptionCount": 6,
                      "confidence": "medium",
                      "model": "qwen3.8:27b",
                      "score": 4
                    }
                  ],
                  "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": "ccb7572963e8b2435c2ee54cea019a60b1b70a5717cc3848ccd940232eae0b91",
                "patchSummary": "Added reset_password_with_account_token() to the User model performing a single conditional UPDATE (WHERE id = ? AND account_token_digest = sha256(nonce)) that sets pwdhash, is_confirmed=True, and account_token_digest=None atomically. Removed the separate consume_account_token() method. Changed the confirm_account view to call form.validate() instead of only comparing password1 and password2 manually. Introduced a _account_token_digest() static helper to centralize the SHA-256 computation (previously three inline calls). Removed synchronize_session=False from the UPDATE execution options so the ORM session stays consistent. Added regression tests for concurrent token consumption (two threads, barrier-synchronized) and for rejection of passwords that fail form validation (empty, three-character, mismatched).",
                "patchTruncated": false,
                "patches": [
                  {
                    "commit": "5462bab62d76df852619e01eb67da36c023c8c40",
                    "patchSha256": "75ed8b215e2769b5d20b161ddfbde9e0b2975f836397979a94387340b0501ec1",
                    "source": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/5462bab62d76df852619e01eb67da36c023c8c40.patch",
                    "sourceUrl": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/5462bab62d76df852619e01eb67da36c023c8c40.patch",
                    "subject": "Fix recovery token consumption race"
                  },
                  {
                    "commit": "ad6f22882975516adf193a1a920aaa54025c71d4",
                    "patchSha256": "c1cecff5ac5f7804ff42f0583b156cefa2add775cb6f80506c917f84a26bf43d",
                    "source": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/ad6f22882975516adf193a1a920aaa54025c71d4.patch",
                    "sourceUrl": "https://github.com/vulnerability-lookup/vulnerability-lookup/commit/ad6f22882975516adf193a1a920aaa54025c71d4.patch",
                    "subject": "fix: [user] Validate the recovery form and harden the token"
                  }
                ],
                "source": "patch set (2 sources)",
                "subject": "fix: [user] Validate the recovery form and harden the token",
                "weaknessRationale": [
                  {
                    "cweId": "CWE-362",
                    "rationale": "The primary defect is a TOCTOU race: the token nonce is verified and then consumed in separate operations, allowing two concurrent transactions to both pass verification before either commits. The fix replaces this with an atomic compare-and-set UPDATE, confirming the race condition as the root cause."
                  },
                  {
                    "cweId": "CWE-20",
                    "rationale": "The confirm_account view never called form.validate() on POST, so the form\u0027s minimum-length and equality validators were bypassed. A valid recovery link alone permitted setting an empty or three-character password. The fix adds the form.validate() call before processing."
                  }
                ]
              }
            }
          },
          "recordType": "advisory",
          "vulnId": "gcve-1-2026-20252"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
    "assignerShortName": "CIRCL",
    "cveId": "CVE-2026-101041",
    "datePublished": "2026-09-27T14:47:57.012Z",
    "dateReserved": "2026-09-27T14:47:50.804Z",
    "dateUpdated": "2026-09-27T14:47:57.012Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted

GHSA-J3GX-2Q66-WG27

CVE-2026-101041 (GCVE-0-2026-101041)

Fix summary

Patch summary

CVSS rationale

Weakness rationale

Attack pattern rationale

Assumptions to verify

Model comparison

Tags

Sightings

Nomenclature

Related by attack behaviour