CVE-2026-9136
Description
A vulnerability was identified in the ShadowAttribute proposal creation workflow. The add action accepted user-controlled ShadowAttribute request data without removing the id field before saving the record. Because the underlying framework treats a supplied primary key as an instruction to update an existing record, an authenticated user able to submit shadow attribute proposals could provide the identifier of an existing ShadowAttribute and cause that record to be updated instead of creating a new proposal.
This can result in unauthorized modification of existing shadow attributes, potentially affecting proposals associated with events the user should not be able to alter. Depending on deployment configuration and accessible API responses, the issue may also expose or move proposal data across event contexts.
The vulnerability is caused by trusting a client-supplied primary key during object creation. The fix removes the id field from incoming ShadowAttribute data before processing, ensuring that the endpoint always creates a new proposal rather than updating an existing one. This has been fixed in MISP 2.5.38.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
MISP ShadowAttribute proposal creation endpoint allows authenticated users to overwrite existing proposals by supplying a client-controlled primary key (id).
Vulnerability
A vulnerability exists in the ShadowAttribute proposal creation workflow in MISP versions prior to 2.5.38. The add action in the ShadowAttributesController accepts user-controlled request data without removing the id field before saving the record. If an attacker supplies an id value matching an existing ShadowAttribute, the underlying CakePHP framework treats the request as an update to that existing record rather than creating a new proposal. The affected code is in app/Controller/ShadowAttributesController.php at the add method, as shown in the commit fix [1].
Exploitation
An authenticated user with the ability to submit shadow attribute proposals can exploit this by including the id field of an existing ShadowAttribute in the POST data to the add endpoint. No special network position or elevated privileges beyond standard proposal submission are required. The attacker simply provides the target id along with intended modifications; the endpoint then updates the existing shadow attribute instead of creating a new proposal [1].
Impact
Successful exploitation results in unauthorized modification of existing shadow attributes. This can lead to altering proposals associated with events the user should not have permission to modify, potentially moving or exposing proposal data across event contexts. The impact depends on deployment configuration and accessible API responses; in some cases, it may lead to information disclosure or privilege escalation [1].
Mitigation
The fix removes the id field from incoming ShadowAttribute request data before processing, ensuring the endpoint always creates a new proposal rather than updating an existing one. This fix was implemented in commit [1] and is included in MISP version 2.5.38 [1]. Users should upgrade to MISP 2.5.38 or later. No workarounds are documented for earlier versions.
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
149911b1d4b6eUnset 'id' from ShadowAttribute request data
1 file changed · +1 −0
app/Controller/ShadowAttributesController.php+1 −0 modified@@ -229,6 +229,7 @@ public function add($eventId) $this->Flash->error(__('Attribute has not been added: attachments are added by "Add attachment" button', true), 'default', array(), 'error'); $this->redirect(array('controller' => 'events', 'action' => 'view', $event['Event']['id'])); } + unset($this->request->data['ShadowAttribute']['id']); $this->request->data['ShadowAttribute']['event_id'] = $event['Event']['id']; // // multiple attributes in batch import
Vulnerability mechanics
Root cause
"The add action in ShadowAttributesController accepts user-controlled request data and does not strip the id field before saving, allowing a client-supplied primary key to trigger an update of an existing record instead of creating a new proposal."
Attack vector
An authenticated user who can submit shadow attribute proposals sends a POST request to the add endpoint with ShadowAttribute data that includes an id field set to the identifier of an existing ShadowAttribute record. Because the underlying framework interprets a supplied primary key as an instruction to update that record, the server modifies the existing proposal rather than creating a new one. This can let the attacker alter proposals tied to events they should not be able to modify, and depending on API responses and deployment configuration, may expose or move proposal data across event contexts [CWE-639].
Affected code
The vulnerability is in `app/Controller/ShadowAttributesController.php`, specifically in the `add($eventId)` function. The code path accepts `$this->request->data['ShadowAttribute']` without removing the id field before saving the record, allowing a client-supplied primary key to be honored by the framework.
What the fix does
The patch adds a single line — `unset($this->request->data['ShadowAttribute']['id']);` — before the record is saved in the add action [patch_id=876958]. By unconditionally removing the id field from the incoming request data, the framework can no longer interpret a client-supplied identifier as an instruction to update an existing ShadowAttribute. This forces the endpoint to always create a new proposal, closing the unauthorized-update vector.
Preconditions
- authThe attacker must be an authenticated user with the ability to submit shadow attribute proposals.
- inputThe attacker must include an id field in the ShadowAttribute request data, set to the identifier of an existing ShadowAttribute record.
Generated on May 20, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1News mentions
0No linked articles in our index yet.