CVE-2026-94374 (GCVE-0-2026-94374)

Vulnerability from cvelistv5 – Published: 2026-09-21 12:25 – Updated: 2026-09-21 15:21
VLAI
Title
MISP: IDOR via Client-Supplied Report ID in Module Results Processing Allows Reparenting and Overwriting of Other Events' Reports
Summary
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 event  - overwrite the report's fields with attacker-controlled data  - change the report's event_id to redirect ownership.  This 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
Severity
8.3 (High)
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
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-21 15:21 UTC
CWE
  • CWE-639 - Authorization Bypass Through User-Controlled Key
  • CWE-472 - External Control of Assumed-Immutable Web Parameter
Assigner
References
Impacted products
Vendor Product Version CPE status
MISP MISP Affected: 0 , < 2.5.47 (semver)
guessed Create a notification for this product.
Credits
Jeroen Pinoy iglocska Claude Opus 4.8
GCVE extensions
AI involvement GCVE-BCP-05-X-01
Whole record AI-generated Review: review 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-21 12:19
Model
qwen3.8:27b
Input
https://github.com/MISP/MISP/commit/4c1a03b20.patch 1079aff9d4e4…
Confidence
medium
Commit Subject Patch SHA-256
4c1a03b200fc fix: [security] Strip the client id from module-result event 1079aff9d4e4…
Fix summary

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.

Patch summary

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.

CVSS rationale

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.

Weakness rationale
  • CWE-639 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.
  • CWE-472 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.
Attack pattern rationale
  • CAPEC-126 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.
Assumptions to verify
  • 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.
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
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-94374",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-21T15:21:38.785106Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-21T15:21:57.870Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "modules": [
            "app/Model/Event.php (processModuleResultsData / handleModuleResults)"
          ],
          "product": "MISP",
          "programFiles": [
            "app/Model/Event.php"
          ],
          "repo": "https://github.com/MISP/MISP",
          "vendor": "MISP",
          "versions": [
            {
              "lessThan": "2.5.47",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "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"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eMISP 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 \u0027id\u0027 field before calling save(). Because the MISP EventReport model\u0027s create() method does not strip the id field, an authenticated user with permission to submit module results could include an \u0027id\u0027 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\u0026nbsp;\u003c/p\u003e\u2003-\u0026nbsp;read the content of another event\u0027s report by reparenting it into their own event\u003cbr\u003e\u2003-\u0026nbsp;overwrite the report\u0027s fields with attacker-controlled data\u003cbr\u003e\u003cdiv\u003e\u2003-\u0026nbsp;change the report\u0027s event_id to redirect ownership.\u0026nbsp;\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cp\u003eThis 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.\u003c/p\u003e\u003cp\u003eVersion affected: \u0026lt;2.5.47\u003c/p\u003e"
            }
          ],
          "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 \u0027id\u0027 field before calling save(). Because the MISP EventReport model\u0027s create() method does not strip the id field, an authenticated user with permission to submit module results could include an \u0027id\u0027 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\u00a0\n\n\u2003-\u00a0read the content of another event\u0027s report by reparenting it into their own event\n\u2003-\u00a0overwrite the report\u0027s fields with attacker-controlled data\n\u2003-\u00a0change the report\u0027s event_id to redirect ownership.\u00a0\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: \u003c2.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": "\u003cp\u003eThe fix adds an unset($report[\u0027id\u0027]) 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.\u003c/p\u003e"
            }
          ],
          "value": "The fix adds an unset($report[\u0027id\u0027]) 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\u0027 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 \u0027id\u0027 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 \u2013 MISP is a network-accessible web application. AC:L \u2013 the attack requires only including an \u0027id\u0027 field in a normal module-results submission; no race condition or complex bypass is needed. AT:N \u2013 no prior user interaction or attack preparation beyond crafting the payload. PR:L \u2013 requires an authenticated user with permission to submit module results on an event (a common MISP role). UI:N \u2013 no victim interaction required. VC:L \u2013 the attacker can read the content of one specific report they target by id. VI:H \u2013 the attacker can overwrite all fields of the targeted report and change its event_id, fully compromising its integrity. VA:N \u2013 no availability impact. SC/SI/SA \u2013 no impact on adjacent systems; SI:H reflects the integrity compromise of the shared report data store.",
                "fixSummary": "The fix adds an unset($report[\u0027id\u0027]) 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[\u0027EventReport\u0027] in processModuleResultsData, a single line unset($report[\u0027id\u0027]); is inserted after $this-\u003eEventReport-\u003ecreate() and before $report[\u0027event_id\u0027] = $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\u0027s 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 \u0027id\u0027 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\u0027s report."
                  },
                  {
                    "cweId": "CWE-472",
                    "rationale": "The \u0027id\u0027 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",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-94374",
      "date": "2026-09-22",
      "epss": "0.0024",
      "percentile": "0.15405"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "modules": [
                  "app/Model/Event.php (processModuleResultsData / handleModuleResults)"
                ],
                "product": "MISP",
                "programFiles": [
                  "app/Model/Event.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": "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 \u0027id\u0027 field before calling save(). Because the MISP EventReport model\u0027s create() method does not strip the id field, an authenticated user with permission to submit module results could include an \u0027id\u0027 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\u00a0\n\n\u2003-\u00a0read the content of another event\u0027s report by reparenting it into their own event\n\u2003-\u00a0overwrite the report\u0027s fields with attacker-controlled data\n\u2003-\u00a0change the report\u0027s event_id to redirect ownership.\u00a0\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: \u003c2.5.47"
          }
        ],
        "id": "CVE-2026-94374",
        "lastModified": "2026-09-21T16:17:30.193",
        "metrics": {
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 8.3,
                "baseSeverity": "HIGH",
                "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": "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/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": "HIGH",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-94374",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-21T15:21:38.785106Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-09-21T13:17:12.953",
        "references": [
          {
            "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
            "url": "https://github.com/MISP/MISP/commit/4c1a03b20"
          }
        ],
        "sourceIdentifier": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-472"
              },
              {
                "lang": "en",
                "value": "CWE-639"
              }
            ],
            "source": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-94374",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-09-21T15:21:38.785106Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-09-21T15:21:52.875Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "modules": [
                "app/Model/Event.php (processModuleResultsData / handleModuleResults)"
              ],
              "product": "MISP",
              "programFiles": [
                "app/Model/Event.php"
              ],
              "repo": "https://github.com/MISP/MISP",
              "vendor": "MISP",
              "versions": [
                {
                  "lessThan": "2.5.47",
                  "status": "affected",
                  "version": "0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "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"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cp\u003eMISP 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 \u0027id\u0027 field before calling save(). Because the MISP EventReport model\u0027s create() method does not strip the id field, an authenticated user with permission to submit module results could include an \u0027id\u0027 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\u0026nbsp;\u003c/p\u003e\u2003-\u0026nbsp;read the content of another event\u0027s report by reparenting it into their own event\u003cbr\u003e\u2003-\u0026nbsp;overwrite the report\u0027s fields with attacker-controlled data\u003cbr\u003e\u003cdiv\u003e\u2003-\u0026nbsp;change the report\u0027s event_id to redirect ownership.\u0026nbsp;\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cp\u003eThis 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.\u003c/p\u003e\u003cp\u003eVersion affected: \u0026lt;2.5.47\u003c/p\u003e"
                }
              ],
              "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 \u0027id\u0027 field before calling save(). Because the MISP EventReport model\u0027s create() method does not strip the id field, an authenticated user with permission to submit module results could include an \u0027id\u0027 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\u00a0\n\n\u2003-\u00a0read the content of another event\u0027s report by reparenting it into their own event\n\u2003-\u00a0overwrite the report\u0027s fields with attacker-controlled data\n\u2003-\u00a0change the report\u0027s event_id to redirect ownership.\u00a0\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: \u003c2.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": "\u003cp\u003eThe fix adds an unset($report[\u0027id\u0027]) 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.\u003c/p\u003e"
                }
              ],
              "value": "The fix adds an unset($report[\u0027id\u0027]) 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\u0027 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 \u0027id\u0027 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 \u2013 MISP is a network-accessible web application. AC:L \u2013 the attack requires only including an \u0027id\u0027 field in a normal module-results submission; no race condition or complex bypass is needed. AT:N \u2013 no prior user interaction or attack preparation beyond crafting the payload. PR:L \u2013 requires an authenticated user with permission to submit module results on an event (a common MISP role). UI:N \u2013 no victim interaction required. VC:L \u2013 the attacker can read the content of one specific report they target by id. VI:H \u2013 the attacker can overwrite all fields of the targeted report and change its event_id, fully compromising its integrity. VA:N \u2013 no availability impact. SC/SI/SA \u2013 no impact on adjacent systems; SI:H reflects the integrity compromise of the shared report data store.",
                    "fixSummary": "The fix adds an unset($report[\u0027id\u0027]) 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[\u0027EventReport\u0027] in processModuleResultsData, a single line unset($report[\u0027id\u0027]); is inserted after $this-\u003eEventReport-\u003ecreate() and before $report[\u0027event_id\u0027] = $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\u0027s 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 \u0027id\u0027 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\u0027s report."
                      },
                      {
                        "cweId": "CWE-472",
                        "rationale": "The \u0027id\u0027 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"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



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.