CVE-2026-95754 (GCVE-0-2026-95754)
Vulnerability from cvelistv5 – Published: 2026-09-22 14:53 – Updated: 2026-09-22 15:53- CWE-285 - Improper Authentication
| URL | Tags |
|---|---|
| https://github.com/MISP/MISP/commit/3df982ab1 | patch |
qwen3.8:27b
advisory
bcp-05-x-01bcp-05-x-02
Draft vulnerability metadata was generated from a git-format patch using an Ollama-hosted language model. Human validation is required before publication.
| Model | Source | Identifier |
|---|---|---|
| qwen3.8:27b | ollama | qwen3.8:27b |
- Generator
-
patch2vuln.pyon 2026-09-22 14:51 - Model
qwen3.8:27b- Input
-
https://github.com/MISP/MISP/commit/3df982ab1.patch
8ddba4461463… - Confidence
- medium
| Commit | Subject | Patch SHA-256 |
|---|---|---|
3df982ab192e
|
fix: [login] Fetch User.disabled in the pre-auth TOTP lookup | 8ddba4461463… |
Fix summary
The fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior.
Patch summary
A single-line change in app/Controller/UsersController.php appends 'User.disabled' to the fields list of the pre-authentication User find() query in the login() method (line 1385), ensuring the disabled flag is present in the result set when the TOTP branch evaluates it.
CVSS rationale
The vulnerability is reachable over the network (AV:N) via the web login endpoint with low complexity (AC:L), no attack target (AT:N), no prior privileges (PR:N), and no user interaction (UI:N). The only potential impact is a very minor confidentiality difference: a disabled, TOTP-enrolled user receives a TOTP prompt instead of an immediate rejection, which could marginally aid account-status enumeration (VC:L). There is no integrity or availability impact (VI:N, VA:N) and no secondary impacts (SC:N, SI:N, SA:N) because the subsequent identify() call still enforces the disabled-user check. The commit message explicitly characterizes the issue as 'harmless in practice.'
Weakness rationale
- CWE-285 The disabled-user check in the TOTP login branch was ineffective because the required column was not fetched, allowing a disabled user to pass that guard. The subsequent identify() call still enforced the check, limiting the impact. CWE-285 is the narrowest defensible mapping for an authentication-state check that does not function as intended.
Attack pattern rationale
- CAPEC-1 The closest plausible CAPEC is Brute Force, as the scenario involves an attacker attempting to authenticate using known credentials of a disabled, TOTP-enrolled account. The disabled-user guard that should have blocked the attempt at the TOTP branch was ineffective, allowing the attempt to proceed one step further than intended. This mapping is uncertain because the vulnerability does not enable a full authentication bypass (identify() still rejects the user) and the primary effect is a minor information-disclosure difference in the login response rather than a successful brute-force attack.
Assumptions to verify
- The commit message states the issue is 'harmless in practice' because identify() re-checks the user; this advisory treats the security impact as minimal (minor information disclosure only).
- The TOTP feature was introduced in 2023 per the commit message; the exact affected version range is not specified in the patch. The tag boundary v2.5.47 is used as an upper bound for the affected range but is not confirmed as the exact fixed version.
- CAPEC-1 (Brute Force) is the closest available attack pattern; the actual scenario is a minor authentication-guard bypass rather than a full brute-force attack, so the mapping is approximate.
- CVSS VC:L is assigned for the marginal information-disclosure difference in the login response; if the CNA determines no meaningful confidentiality impact exists, VC:N would be more appropriate, resulting in a score of 0.0.
- The PHP version behavior (Warning vs Notice vs Error for undefined array keys) may vary, but in all supported PHP versions the code continues execution with a null value, so the security analysis is unaffected.
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 |
5 | 9 | medium | 5 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95754",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:53:03.966908Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:53:14.911Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"modules": [
"UsersController (login method",
"TOTP branch)"
],
"product": "MISP",
"programFiles": [
"app/Controller/UsersController.php"
],
"repo": "https://github.com/MISP/MISP",
"vendor": "MISP",
"versions": [
{
"lessThan": "2.5.47",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "iglocska"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Claude Fable 5.1"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn MISP\u0027s UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotp_counter. When the TOTP branch subsequently accessed $unauth_user[\u0027User\u0027][\u0027disabled\u0027], the key was absent from the result set, producing a PHP \u0027Undefined array key\u0027 warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe commit message explicitly states this was \u0027harmless in practice\u0027 because the subsequent identify() call re-validates the user and would still reject a disabled account.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs.\u003c/p\u003e"
}
],
"value": "In MISP\u0027s UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotp_counter. When the TOTP branch subsequently accessed $unauth_user[\u0027User\u0027][\u0027disabled\u0027], the key was absent from the result set, producing a PHP \u0027Undefined array key\u0027 warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.\u00a0\n\nThe commit message explicitly states this was \u0027harmless in practice\u0027 because the subsequent identify() call re-validates the user and would still reject a disabled account.\u00a0\n\nThe practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs."
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Brute Force"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/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-285",
"description": "CWE-285 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T14:53:56.006Z",
"orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"shortName": "CIRCL"
},
"references": [
{
"name": "Security patch",
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/3df982ab1"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior.\u003c/p\u003e"
}
],
"value": "The fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior."
}
],
"title": "MISP: Disabled-user check ineffective in pre-authentication TOTP login branch",
"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 commit message states the issue is \u0027harmless in practice\u0027 because identify() re-checks the user; this advisory treats the security impact as minimal (minor information disclosure only).",
"The TOTP feature was introduced in 2023 per the commit message; the exact affected version range is not specified in the patch. The tag boundary v2.5.47 is used as an upper bound for the affected range but is not confirmed as the exact fixed version.",
"CAPEC-1 (Brute Force) is the closest available attack pattern; the actual scenario is a minor authentication-guard bypass rather than a full brute-force attack, so the mapping is approximate.",
"CVSS VC:L is assigned for the marginal information-disclosure difference in the login response; if the CNA determines no meaningful confidentiality impact exists, VC:N would be more appropriate, resulting in a score of 0.0.",
"The PHP version behavior (Warning vs Notice vs Error for undefined array keys) may vary, but in all supported PHP versions the code continues execution with a null value, so the security analysis is unaffected."
],
"capecRationale": [
{
"capecId": "CAPEC-1",
"rationale": "The closest plausible CAPEC is Brute Force, as the scenario involves an attacker attempting to authenticate using known credentials of a disabled, TOTP-enrolled account. The disabled-user guard that should have blocked the attempt at the TOTP branch was ineffective, allowing the attempt to proceed one step further than intended. This mapping is uncertain because the vulnerability does not enable a full authentication bypass (identify() still rejects the user) and the primary effect is a minor information-disclosure difference in the login response rather than a successful brute-force attack."
}
],
"commit": "3df982ab192e05f5369d62af5674c7a874b32756",
"confidence": "medium",
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "iglocska"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Claude Fable 5.1"
}
],
"cvssRationale": "The vulnerability is reachable over the network (AV:N) via the web login endpoint with low complexity (AC:L), no attack target (AT:N), no prior privileges (PR:N), and no user interaction (UI:N). The only potential impact is a very minor confidentiality difference: a disabled, TOTP-enrolled user receives a TOTP prompt instead of an immediate rejection, which could marginally aid account-status enumeration (VC:L). There is no integrity or availability impact (VI:N, VA:N) and no secondary impacts (SC:N, SI:N, SA:N) because the subsequent identify() call still enforces the disabled-user check. The commit message explicitly characterizes the issue as \u0027harmless in practice.\u0027",
"fixSummary": "The fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior.",
"generatedAt": "2026-09-22T14:51:29.308929Z",
"generator": "patch2vuln.py",
"model": "qwen3.8:27b",
"modelComparison": {
"rankings": [
{
"agreementScore": 9,
"assumptionCount": 5,
"confidence": "medium",
"model": "qwen3.8:27b",
"score": 5
}
],
"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": "8ddba4461463bf2e5b115b4bdd168f91b246f1fcd796dc4da8873ed8da2397c0",
"patchSummary": "A single-line change in app/Controller/UsersController.php appends \u0027User.disabled\u0027 to the fields list of the pre-authentication User find() query in the login() method (line 1385), ensuring the disabled flag is present in the result set when the TOTP branch evaluates it.",
"patchTruncated": false,
"patches": [
{
"commit": "3df982ab192e05f5369d62af5674c7a874b32756",
"patchSha256": "8ddba4461463bf2e5b115b4bdd168f91b246f1fcd796dc4da8873ed8da2397c0",
"source": "https://github.com/MISP/MISP/commit/3df982ab1.patch",
"sourceUrl": "https://github.com/MISP/MISP/commit/3df982ab1.patch",
"subject": "fix: [login] Fetch User.disabled in the pre-auth TOTP lookup"
}
],
"source": "https://github.com/MISP/MISP/commit/3df982ab1.patch",
"subject": "fix: [login] Fetch User.disabled in the pre-auth TOTP lookup",
"tagVersionBoundary": {
"commits_after_fix": 271,
"repository": "https://github.com/MISP/MISP",
"tag": "v2.5.47",
"version": "2.5.47",
"version_type": "semver"
},
"weaknessRationale": [
{
"cweId": "CWE-285",
"rationale": "The disabled-user check in the TOTP login branch was ineffective because the required column was not fetched, allowing a disabled user to pass that guard. The subsequent identify() call still enforced the check, limiting the impact. CWE-285 is the narrowest defensible mapping for an authentication-state check that does not function as intended."
}
]
}
}
},
"recordType": "advisory",
"vulnId": "GCVE-1-2026-20024"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"assignerShortName": "CIRCL",
"cveId": "CVE-2026-95754",
"datePublished": "2026-09-22T14:53:56.006Z",
"dateReserved": "2026-09-22T14:53:53.341Z",
"dateUpdated": "2026-09-22T15:53:14.911Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-95754",
"date": "2026-09-23",
"epss": "0.00543",
"percentile": "0.44539"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"modules": [
"UsersController (login method",
"TOTP branch)"
],
"product": "MISP",
"programFiles": [
"app/Controller/UsersController.php"
],
"repo": "https://github.com/MISP/MISP",
"vendor": "MISP",
"versions": [
{
"lessThan": "2.5.47",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In MISP\u0027s UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotp_counter. When the TOTP branch subsequently accessed $unauth_user[\u0027User\u0027][\u0027disabled\u0027], the key was absent from the result set, producing a PHP \u0027Undefined array key\u0027 warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.\u00a0\n\nThe commit message explicitly states this was \u0027harmless in practice\u0027 because the subsequent identify() call re-validates the user and would still reject a disabled account.\u00a0\n\nThe practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs."
}
],
"id": "CVE-2026-95754",
"lastModified": "2026-09-22T16:18:24.163",
"metrics": {
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"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": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/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": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-95754",
"options": [
{
"exploitation": "none"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:53:03.966908Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-09-22T15:17:28.530",
"references": [
{
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"url": "https://github.com/MISP/MISP/commit/3df982ab1"
}
],
"sourceIdentifier": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-285"
}
],
"source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"type": "Secondary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-95754",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-22T15:53:03.966908Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T15:53:10.884Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"modules": [
"UsersController (login method",
"TOTP branch)"
],
"product": "MISP",
"programFiles": [
"app/Controller/UsersController.php"
],
"repo": "https://github.com/MISP/MISP",
"vendor": "MISP",
"versions": [
{
"lessThan": "2.5.47",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "iglocska"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Claude Fable 5.1"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn MISP\u0027s UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotp_counter. When the TOTP branch subsequently accessed $unauth_user[\u0027User\u0027][\u0027disabled\u0027], the key was absent from the result set, producing a PHP \u0027Undefined array key\u0027 warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe commit message explicitly states this was \u0027harmless in practice\u0027 because the subsequent identify() call re-validates the user and would still reject a disabled account.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs.\u003c/p\u003e"
}
],
"value": "In MISP\u0027s UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotp_counter. When the TOTP branch subsequently accessed $unauth_user[\u0027User\u0027][\u0027disabled\u0027], the key was absent from the result set, producing a PHP \u0027Undefined array key\u0027 warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.\u00a0\n\nThe commit message explicitly states this was \u0027harmless in practice\u0027 because the subsequent identify() call re-validates the user and would still reject a disabled account.\u00a0\n\nThe practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs."
}
],
"impacts": [
{
"capecId": "CAPEC-1",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-1 Brute Force"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/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-285",
"description": "CWE-285 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-22T14:53:56.006Z",
"orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"shortName": "CIRCL"
},
"references": [
{
"name": "Security patch",
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/3df982ab1"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior.\u003c/p\u003e"
}
],
"value": "The fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior."
}
],
"title": "MISP: Disabled-user check ineffective in pre-authentication TOTP login branch",
"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 commit message states the issue is \u0027harmless in practice\u0027 because identify() re-checks the user; this advisory treats the security impact as minimal (minor information disclosure only).",
"The TOTP feature was introduced in 2023 per the commit message; the exact affected version range is not specified in the patch. The tag boundary v2.5.47 is used as an upper bound for the affected range but is not confirmed as the exact fixed version.",
"CAPEC-1 (Brute Force) is the closest available attack pattern; the actual scenario is a minor authentication-guard bypass rather than a full brute-force attack, so the mapping is approximate.",
"CVSS VC:L is assigned for the marginal information-disclosure difference in the login response; if the CNA determines no meaningful confidentiality impact exists, VC:N would be more appropriate, resulting in a score of 0.0.",
"The PHP version behavior (Warning vs Notice vs Error for undefined array keys) may vary, but in all supported PHP versions the code continues execution with a null value, so the security analysis is unaffected."
],
"capecRationale": [
{
"capecId": "CAPEC-1",
"rationale": "The closest plausible CAPEC is Brute Force, as the scenario involves an attacker attempting to authenticate using known credentials of a disabled, TOTP-enrolled account. The disabled-user guard that should have blocked the attempt at the TOTP branch was ineffective, allowing the attempt to proceed one step further than intended. This mapping is uncertain because the vulnerability does not enable a full authentication bypass (identify() still rejects the user) and the primary effect is a minor information-disclosure difference in the login response rather than a successful brute-force attack."
}
],
"commit": "3df982ab192e05f5369d62af5674c7a874b32756",
"confidence": "medium",
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "iglocska"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Claude Fable 5.1"
}
],
"cvssRationale": "The vulnerability is reachable over the network (AV:N) via the web login endpoint with low complexity (AC:L), no attack target (AT:N), no prior privileges (PR:N), and no user interaction (UI:N). The only potential impact is a very minor confidentiality difference: a disabled, TOTP-enrolled user receives a TOTP prompt instead of an immediate rejection, which could marginally aid account-status enumeration (VC:L). There is no integrity or availability impact (VI:N, VA:N) and no secondary impacts (SC:N, SI:N, SA:N) because the subsequent identify() call still enforces the disabled-user check. The commit message explicitly characterizes the issue as \u0027harmless in practice.\u0027",
"fixSummary": "The fix adds User.disabled to the fields array of the pre-authentication find() query so that the disabled-user check in the TOTP branch reads the actual column value and correctly rejects disabled users before they reach the TOTP verification step, restoring the intended guard behavior.",
"generatedAt": "2026-09-22T14:51:29.308929Z",
"generator": "patch2vuln.py",
"model": "qwen3.8:27b",
"modelComparison": {
"rankings": [
{
"agreementScore": 9,
"assumptionCount": 5,
"confidence": "medium",
"model": "qwen3.8:27b",
"score": 5
}
],
"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": "8ddba4461463bf2e5b115b4bdd168f91b246f1fcd796dc4da8873ed8da2397c0",
"patchSummary": "A single-line change in app/Controller/UsersController.php appends \u0027User.disabled\u0027 to the fields list of the pre-authentication User find() query in the login() method (line 1385), ensuring the disabled flag is present in the result set when the TOTP branch evaluates it.",
"patchTruncated": false,
"patches": [
{
"commit": "3df982ab192e05f5369d62af5674c7a874b32756",
"patchSha256": "8ddba4461463bf2e5b115b4bdd168f91b246f1fcd796dc4da8873ed8da2397c0",
"source": "https://github.com/MISP/MISP/commit/3df982ab1.patch",
"sourceUrl": "https://github.com/MISP/MISP/commit/3df982ab1.patch",
"subject": "fix: [login] Fetch User.disabled in the pre-auth TOTP lookup"
}
],
"source": "https://github.com/MISP/MISP/commit/3df982ab1.patch",
"subject": "fix: [login] Fetch User.disabled in the pre-auth TOTP lookup",
"tagVersionBoundary": {
"commits_after_fix": 271,
"repository": "https://github.com/MISP/MISP",
"tag": "v2.5.47",
"version": "2.5.47",
"version_type": "semver"
},
"weaknessRationale": [
{
"cweId": "CWE-285",
"rationale": "The disabled-user check in the TOTP login branch was ineffective because the required column was not fetched, allowing a disabled user to pass that guard. The subsequent identify() call still enforced the check, limiting the impact. CWE-285 is the narrowest defensible mapping for an authentication-state check that does not function as intended."
}
]
}
}
},
"recordType": "advisory",
"vulnId": "GCVE-1-2026-20024"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"assignerShortName": "CIRCL",
"cveId": "CVE-2026-95754",
"datePublished": "2026-09-22T14:53:56.006Z",
"dateReserved": "2026-09-22T14:53:53.341Z",
"dateUpdated": "2026-09-22T15:53:14.911Z",
"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 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.