MISP contains an insecure direct object reference vulnerability in the processModuleResultsData method of the Event model. When processing module results, the code iterates over EventReport entries supplied in the resolved data and saves each one. Unlike the adjacent attribute and object processing loops, the report loop did not unset the client-supplied 'id' field before calling save(). Because the MISP EventReport model's create() method does not strip the id field, an authenticated user with permission to submit module results could include an 'id' value referencing an existing report belonging to a different event. Upon save(), the ORM would update that existing row rather than insert a new one, allowing the attacker to
- read the content of another event's report by reparenting it into their own eventThis constitutes an authorization bypass through a user-controlled key, enabling cross-event data disclosure and integrity compromise. The vulnerability requires an authenticated session with the ability to invoke module result processing on an event.
Version affected: <2.5.47
"}],"value":"MISP contains an insecure direct object reference vulnerability in the processModuleResultsData method of the Event model. When processing module results, the code iterates over EventReport entries supplied in the resolved data and saves each one. Unlike the adjacent attribute and object processing loops, the report loop did not unset the client-supplied 'id' field before calling save(). Because the MISP EventReport model's create() method does not strip the id field, an authenticated user with permission to submit module results could include an 'id' value referencing an existing report belonging to a different event. Upon save(), the ORM would update that existing row rather than insert a new one, allowing the attacker to \n\n - read the content of another event's report by reparenting it into their own event\n - overwrite the report's fields with attacker-controlled data\n - change the report's event_id to redirect ownership. \n\n\n\n\nThis constitutes an authorization bypass through a user-controlled key, enabling cross-event data disclosure and integrity compromise. The vulnerability requires an authenticated session with the ability to invoke module result processing on an event.\n\nVersion affected: <2.5.47"}],"impacts":[{"capecId":"CAPEC-126","descriptions":[{"lang":"en","value":"CAPEC-126 Parameter Tampering"}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":8.3,"baseSeverity":"HIGH","privilegesRequired":"LOW","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"HIGH","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:H/SA:N","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"HIGH","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-639","description":"CWE-639 Authorization Bypass Through User-Controlled Key","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-472","description":"CWE-472 External Control of Assumed-Immutable Web Parameter","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-21T12:25:02.628Z","orgId":"5a6e4751-2f3f-4070-9419-94fb35b644e8","shortName":"CIRCL"},"references":[{"name":"Security patch","tags":["patch"],"url":"https://github.com/MISP/MISP/commit/4c1a03b20"}],"solutions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"The fix adds an unset($report['id']) call in the EventReport processing loop within processModuleResultsData, immediately before the event_id assignment and save() call. This ensures that any client-supplied id field is stripped from the report data, forcing the ORM to perform an insert (new report) rather than an update (existing report), consistent with the existing behavior of the attribute and object loops in the same method.
"}],"value":"The fix adds an unset($report['id']) call in the EventReport processing loop within processModuleResultsData, immediately before the event_id assignment and save() call. This ensures that any client-supplied id field is stripped from the report data, forcing the ORM to perform an insert (new report) rather than an update (existing report), consistent with the existing behavior of the attribute and object loops in the same method."}],"title":"MISP: IDOR via Client-Supplied Report ID in Module Results Processing Allows Reparenting and Overwriting of Other Events' Reports","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 exact affected and fixed MISP version numbers are not stated in the patch metadata; the tag boundary (v2.5.47, 53 commits after fix) suggests the fix landed after v2.5.47 but the precise fixed release is unspecified.","PR:L assumes that submitting module results is available to any authenticated user with write access to an event; if MISP requires a more restrictive role (e.g., admin or org admin), PR should be raised to H.","VC:L assumes the attacker can read only the specific report they target by id; if the reparenting exposes additional data (e.g., related attributes), the confidentiality impact could be higher.","CAPEC-126 (Parameter Tampering) is the closest available CAPEC; the actual technique is more precisely a mass-assignment / IDOR via unsanitized primary key, for which no dedicated CAPEC entry exists.","The Co-Authored-By line references an AI assistant (Claude Opus 4.8); it is credited as a tool rather than a human remediation developer."],"capecRationale":[{"capecId":"CAPEC-126","rationale":"The attacker tampers with the module-results payload by injecting an 'id' parameter that the application does not expect or sanitize, redirecting the save operation to an arbitrary existing report row. This is the closest CAPEC to the observed attack: manipulating a request parameter to alter application behavior and access an unauthorized object. The mapping is approximate because CAPEC-126 typically describes in-transit tampering, whereas here the parameter is included in the initial request body; however, no more specific CAPEC for mass-assignment IDOR exists in the CAPEC catalog."}],"commit":"4c1a03b200fc75854879897c9cfc33a86b965d11","confidence":"medium","credits":[{"lang":"en","type":"reporter","value":"Jeroen Pinoy"},{"lang":"en","type":"remediation developer","value":"iglocska"},{"lang":"en","type":"remediation developer","value":"Claude Opus 4.8"}],"cvssRationale":"AV:N – MISP is a network-accessible web application. AC:L – the attack requires only including an 'id' field in a normal module-results submission; no race condition or complex bypass is needed. AT:N – no prior user interaction or attack preparation beyond crafting the payload. PR:L – requires an authenticated user with permission to submit module results on an event (a common MISP role). UI:N – no victim interaction required. VC:L – the attacker can read the content of one specific report they target by id. VI:H – the attacker can overwrite all fields of the targeted report and change its event_id, fully compromising its integrity. VA:N – no availability impact. SC/SI/SA – no impact on adjacent systems; SI:H reflects the integrity compromise of the shared report data store.","fixSummary":"The fix adds an unset($report['id']) call in the EventReport processing loop within processModuleResultsData, immediately before the event_id assignment and save() call. This ensures that any client-supplied id field is stripped from the report data, forcing the ORM to perform an insert (new report) rather than an update (existing report), consistent with the existing behavior of the attribute and object loops in the same method.","generatedAt":"2026-09-21T12:19:38.677403Z","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":"1079aff9d4e4710ba6c4ea950bcbbe2597411bfe7065efbc1bc9a5587f87a6c9","patchSummary":"In app/Model/Event.php, within the foreach loop over $resolved_data['EventReport'] in processModuleResultsData, a single line unset($report['id']); is inserted after $this->EventReport->create() and before $report['event_id'] = $id. A four-line comment is added explaining that module-result import only creates reports and that stripping the client id prevents redirecting save() onto another event's report row. No other files or logic are modified.","patchTruncated":false,"patches":[{"commit":"4c1a03b200fc75854879897c9cfc33a86b965d11","patchSha256":"1079aff9d4e4710ba6c4ea950bcbbe2597411bfe7065efbc1bc9a5587f87a6c9","source":"https://github.com/MISP/MISP/commit/4c1a03b20.patch","sourceUrl":"https://github.com/MISP/MISP/commit/4c1a03b20.patch","subject":"fix: [security] Strip the client id from module-result event"}],"source":"https://github.com/MISP/MISP/commit/4c1a03b20.patch","subject":"fix: [security] Strip the client id from module-result event","tagVersionBoundary":{"commits_after_fix":53,"repository":"https://github.com/MISP/MISP","tag":"v2.5.47","version":"2.5.47","version_type":"semver"},"weaknessRationale":[{"cweId":"CWE-639","rationale":"The attacker supplies an 'id' value in the module-results payload that the application uses as the primary key for the save() operation, redirecting the write to an object (report row) belonging to a different event. The user-controlled key bypasses the intended create-only semantics and grants unauthorized read/write access to another event's report."},{"cweId":"CWE-472","rationale":"The 'id' field is assumed to be server-generated and immutable for new records, but the application accepts a client-supplied value and passes it directly to the ORM save() call, allowing the attacker to control which database row is affected."}]}}},"recordType":"advisory","vulnId":"GCVE-1-2026-20022"}]}},"cveMetadata":{"assignerOrgId":"5a6e4751-2f3f-4070-9419-94fb35b644e8","assignerShortName":"CIRCL","cveId":"CVE-2026-94374","datePublished":"2026-09-21T12:25:02.628Z","dateReserved":"2026-09-21T12:25:00.527Z","dateUpdated":"2026-09-21T15:21:57.870Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-21 13:17:12","lastModifiedDate":"2026-09-21 16:17:30","problem_types":["CWE-472","CWE-639","CWE-639 CWE-639 Authorization Bypass Through User-Controlled Key","CWE-472 CWE-472 External Control of Assumed-Immutable Web Parameter"],"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:L/VI:H/VA:N/SC:N/SI:H/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.3,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"HIGH","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-21T15:21:38.785106Z","id":"CVE-2026-94374","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"94374","Ordinal":"1","Title":"MISP: IDOR via Client-Supplied Report ID in Module Results Proce","CVE":"CVE-2026-94374","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"94374","Ordinal":"1","NoteData":"MISP contains an insecure direct object reference vulnerability in the processModuleResultsData method of the Event model. When processing module results, the code iterates over EventReport entries supplied in the resolved data and saves each one. Unlike the adjacent attribute and object processing loops, the report loop did not unset the client-supplied 'id' field before calling save(). Because the MISP EventReport model's create() method does not strip the id field, an authenticated user with permission to submit module results could include an 'id' value referencing an existing report belonging to a different event. Upon save(), the ORM would update that existing row rather than insert a new one, allowing the attacker to \n\n - read the content of another event's report by reparenting it into their own event\n - overwrite the report's fields with attacker-controlled data\n - change the report's event_id to redirect ownership. \n\n\n\n\nThis constitutes an authorization bypass through a user-controlled key, enabling cross-event data disclosure and integrity compromise. The vulnerability requires an authenticated session with the ability to invoke module result processing on an event.\n\nVersion affected: <2.5.47","Type":"Description","Title":"MISP: IDOR via Client-Supplied Report ID in Module Results Proce"}]}}}