MISP has a security issue that can let a user gain more access than their API key is supposed to allow.
A read-only API key should only let someone view information. However, after logging in with such a key, a specific MISP function could accidentally restore the user’s normal account permissions. This means someone with a read-only API key could potentially gain write, delete, or even administrator access if their underlying account has those permissions.
Exploiting the issue requires a valid read-only API key and a single request to the affected function.
The main impact is that MISP’s API key restrictions can be bypassed, allowing actions that the API key was specifically meant to prevent.
Version affected: <2.5.47
"}],"value":"MISP has a security issue that can let a user gain more access than their API key is supposed to allow.\n\nA read-only API key should only let someone view information. However, after logging in with such a key, a specific MISP function could accidentally restore the user’s normal account permissions. This means someone with a read-only API key could potentially gain write, delete, or even administrator access if their underlying account has those permissions.\n\nExploiting the issue requires a valid read-only API key and a single request to the affected function.\n\nThe main impact is that MISP’s API key restrictions can be bypassed, allowing actions that the API key was specifically meant to prevent.\n\n\n\n\nVersion affected: <2.5.47"}],"impacts":[{"capecId":"CAPEC-114","descriptions":[{"lang":"en","value":"CAPEC-114 Exploiting Incorrectly Configured Privileges"}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":8.7,"baseSeverity":"HIGH","privilegesRequired":"LOW","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-269","description":"CWE-269 Improper Privilege Management","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-21T12:42:53.242Z","orgId":"5a6e4751-2f3f-4070-9419-94fb35b644e8","shortName":"CIRCL"},"references":[{"name":"Security patch","tags":["patch"],"url":"https://github.com/MISP/MISP/commit/fd27e592a"}],"solutions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"The fix removes the call to User::getAuthUser() and Auth::login() from the updateLoginTime() method, which was re-authenticating the user with their full role permissions. It replaces this with a call to _refreshAuth(), which refreshes the authentication state while preserving the current (restricted) permission level associated with the API key, preventing privilege escalation.
"}],"value":"The fix removes the call to User::getAuthUser() and Auth::login() from the updateLoginTime() method, which was re-authenticating the user with their full role permissions. It replaces this with a call to _refreshAuth(), which refreshes the authentication state while preserving the current (restricted) permission level associated with the API key, preventing privilege escalation."}],"title":"MISP Privilege Escalation: Read-Only API Key User Can Regain Full Role via updateLoginTime","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":"review","scope":"record","tags":["ai-computer-assisted:llm-generated","ai-computer-assisted:classification"]}]},"bcp-05-x-02":{"x_patch2vuln":{"assumptions":["The tag_version_boundary indicates the fix commit is 141 commits before v2.5.47, implying v2.5.47 contains the fix; versions prior to v2.5.47 are assumed affected. No explicit version range is stated in the patch.","The _refreshAuth() method is assumed to preserve the current API-key-scoped permission level rather than re-fetching full role permissions; this is inferred from the commit subject and the removal of getAuthUser()/Auth::login().","The 'full role' referenced in the commit subject is assumed to be a higher-privilege role (e.g., admin or site admin) compared to the read-only API key scope.","CAPEC-114 is the closest available attack pattern; no CAPEC specifically models session privilege escalation via authentication refresh, so this mapping carries some uncertainty.","CVSS impact metrics (VC/VI/VA) assume the user's full role grants broad administrative access to the MISP instance; actual impact depends on the specific role assigned to the user."],"capecRationale":[{"capecId":"CAPEC-114","rationale":"The vulnerability arises because the updateLoginTime endpoint incorrectly reconfigures the user's privilege level during session refresh, upgrading from the API-key-scoped read-only permissions to the user's full role. The attacker exploits this misconfiguration by simply calling the endpoint. CAPEC-114 is the closest match as it covers scenarios where an application incorrectly assigns or maintains privilege levels. Uncertainty: no CAPEC specifically covers 'session privilege escalation via auth refresh,' so this is the best available approximation."}],"commit":"fd27e592a617f21934f4a2c424e0578287affb36","confidence":"medium","credits":[{"lang":"en","type":"reporter","value":"Jeroen Pinoy"},{"lang":"en","type":"remediation developer","value":"iglocska"}],"cvssRationale":"AV:N - the endpoint is accessible over the network via HTTP POST. AC:L - the attack requires only a single POST request to a known endpoint; no race conditions or complex timing. AT:N - no manipulation of the target system is needed beyond the API call. PR:L - the attacker must possess a valid read-only API key (authenticated user). UI:N - no user interaction is required. VC:H - the escalated user can read all data in the MISP instance that their full role permits. VI:H - the escalated user can create, modify, and delete threat intelligence data. VA:H - the escalated user can delete data, modify configurations, or disrupt the MISP service. SC/SI/SA:N - the impact is confined to the MISP instance itself; no cascading impact on other systems is evidenced.","fixSummary":"The fix removes the call to User::getAuthUser() and Auth::login() from the updateLoginTime() method, which was re-authenticating the user with their full role permissions. It replaces this with a call to _refreshAuth(), which refreshes the authentication state while preserving the current (restricted) permission level associated with the API key, preventing privilege escalation.","generatedAt":"2026-09-21T12:37:21.609779Z","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":"d4143841f5f0d52a14d8538760872a7d91f78ba110384eafa3eedcad8e6480d3","patchSummary":"In app/Controller/UsersController.php, the updateLoginTime() method is modified: the lines that fetched the user record via User::find(), called User::getAuthUser() to retrieve the full auth user, and called Auth::login() to re-establish the session are removed. These are replaced with a single call to $this->_refreshAuth(), which updates the authentication context without upgrading the permission scope. Net change: 1 insertion, 6 deletions.","patchTruncated":false,"patches":[{"commit":"fd27e592a617f21934f4a2c424e0578287affb36","patchSha256":"d4143841f5f0d52a14d8538760872a7d91f78ba110384eafa3eedcad8e6480d3","source":"https://github.com/MISP/MISP/commit/fd27e592a.patch","sourceUrl":"https://github.com/MISP/MISP/commit/fd27e592a.patch","subject":"fix: [security] read only api keys can regain full role"}],"source":"https://github.com/MISP/MISP/commit/fd27e592a.patch","subject":"fix: [security] read only api keys can regain full role","tagVersionBoundary":{"commits_after_fix":141,"repository":"https://github.com/MISP/MISP","tag":"v2.5.47","version":"2.5.47","version_type":"semver"},"weaknessRationale":[{"cweId":"CWE-269","rationale":"The system fails to maintain the restricted privilege level (read-only) associated with the API key authentication. The updateLoginTime endpoint re-establishes the session with the user's full role permissions, effectively granting higher privileges than the authentication credential intended. This is a failure to properly manage and enforce the privilege boundary during session refresh."}]}}},"recordType":"advisory","vulnId":"GCVE-1-2026-20048"}]}},"cveMetadata":{"assignerOrgId":"5a6e4751-2f3f-4070-9419-94fb35b644e8","assignerShortName":"CIRCL","cveId":"CVE-2026-94381","datePublished":"2026-09-21T12:42:53.242Z","dateReserved":"2026-09-21T12:42:51.237Z","dateUpdated":"2026-09-21T14:48:17.524Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-21 13:17:13","lastModifiedDate":"2026-09-21 15:17:39","problem_types":["CWE-269","CWE-269 CWE-269 Improper Privilege Management"],"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:L/UI:N/VC:H/VI:H/VA:H/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":8.7,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","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":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-09-21T14:37:33.435781Z","id":"CVE-2026-94381","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"94381","Ordinal":"1","Title":"MISP Privilege Escalation: Read-Only API Key User Can Regain Ful","CVE":"CVE-2026-94381","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"94381","Ordinal":"1","NoteData":"MISP has a security issue that can let a user gain more access than their API key is supposed to allow.\n\nA read-only API key should only let someone view information. However, after logging in with such a key, a specific MISP function could accidentally restore the user’s normal account permissions. This means someone with a read-only API key could potentially gain write, delete, or even administrator access if their underlying account has those permissions.\n\nExploiting the issue requires a valid read-only API key and a single request to the affected function.\n\nThe main impact is that MISP’s API key restrictions can be bypassed, allowing actions that the API key was specifically meant to prevent.\n\n\n\n\nVersion affected: <2.5.47","Type":"Description","Title":"MISP Privilege Escalation: Read-Only API Key User Can Regain Ful"}]}}}