CVE-2026-54398
Description
An authorization bypass in MISP object editing allows authenticated users to assign objects to unauthorized sharing groups, potentially leaking group existence and altering distribution metadata.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An authorization bypass in MISP object editing allows authenticated users to assign objects to unauthorized sharing groups, potentially leaking group existence and altering distribution metadata.
Vulnerability
A flaw in MISP's object add/edit handling permits authenticated users with object editing permissions to assign a MISP object or its attributes to a sharing group they are not authorized to use. The vulnerability exists because after object fields are merged to the top level of the request data, the sharing group validation (check for distribution == 4 and sharing_group_id) was performed against the wrong data structure—the old data['Object']—effectively bypassing the check. Additionally, attributes embedded in objects were not individually validated for authorized sharing group use. This affects MISP versions prior to the commit [1].
Exploitation
An attacker must have an authenticated user account with object editing permissions. The attacker crafts a request to add or edit an object (or its attributes) with distribution set to 4 and an arbitrary sharing_group_id value. Due to the missing validation, the request is processed, and the object or attributes are assigned to a sharing group the attacker should not have access to.
Impact
Successful exploitation results in unauthorized modification of distribution metadata for objects and contained attributes. The attacker may be able to discover the existence or name of otherwise non-visible sharing groups. This can lead to information disclosure of sensitive sharing group membership and potentially expose indicators or intelligence to unintended groups.
Mitigation
The fix is implemented in commit [1] (MISP/MISP@4fe48c5). Users should update to a version that includes this commit. The commit corrects the validation logic by checking the merged top-level distribution field and adds validation for attribute sharing groups in both add() and edit() methods. No workaround is currently available; upgrading is recommended.
AI Insight generated on Jun 12, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
14fe48c523e66fix: [security] object edit - allows for setting distribution levels that are not visible to the user
1 file changed · +38 −2
app/Controller/ObjectsController.php+38 −2 modified@@ -255,6 +255,9 @@ public function add($eventId, $templateId = false, $version = false) throw new MethodNotAllowedException($canSGBeUsed); } } + if (!empty($object['Attribute'])) { + $this->__validateAttributeSharingGroups($object['Attribute']); + } $result = $this->MispObject->saveObject($object, $eventId, $template, $this->Auth->user(), 'halt', $breakOnDuplicate); if (is_numeric($result)) { $this->MispObject->Event->unpublishEvent($event); @@ -413,13 +416,20 @@ public function edit($id, $update_template_available=false, $onlyAddNewAttribute $this->request->data = array_merge($this->request->data, $this->request->data['Object']); unset($this->request->data['Object']); } - if (isset($this->request->data['Object']['distribution']) && $this->request->data['Object']['distribution'] == 4) { - $canSGBeUsed = $this->MispObject->Event->SharingGroup->checkIfCanBeUsed($this->Auth->user(), $this->_isRest(), $this->request->data, 'Object'); + // The Object fields were merged up to the top level (and data['Object'] unset) just above, + // so the distribution/sharing_group_id now live directly on data - the old data['Object'] + // check could never fire, leaving the SG unvalidated and letting an editor assign an + // arbitrary (unauthorised) sharing group. + if (isset($this->request->data['distribution']) && $this->request->data['distribution'] == 4) { + $canSGBeUsed = $this->MispObject->Event->SharingGroup->checkIfCanBeUsed($this->Auth->user(), $this->_isRest(), $this->request->data); if ($canSGBeUsed !== true) { throw new MethodNotAllowedException($canSGBeUsed); } } $objectToSave = $this->MispObject->attributeCleanup($this->request->data); + if (!empty($objectToSave['Attribute'])) { + $this->__validateAttributeSharingGroups($objectToSave['Attribute']); + } $objectToSave = $this->MispObject->deltaMerge($object, $objectToSave, $onlyAddNewAttribute, $user); $error_message = __('Object could not be saved.'); $savedObject = array(); @@ -505,6 +515,32 @@ public function edit($id, $update_template_available=false, $onlyAddNewAttribute $this->render('add'); } + /** + * Ensure that every attribute saved with a sharing-group distribution (4) references a sharing + * group the acting user is actually allowed to use. The per-object distribution check only covers + * the object's own sharing group; without this an editor could assign an arbitrary (unauthorised) + * sharing group to a contained attribute, leaking its name. Mirrors the unconditional check that + * AttributesController::add()/edit() already apply for standalone attributes. + * + * @param array $attributes List of attribute arrays (each potentially carrying distribution/sharing_group_id) + * @throws MethodNotAllowedException when an attribute targets a sharing group the user cannot use + */ + private function __validateAttributeSharingGroups(array $attributes) + { + foreach ($attributes as $attribute) { + if (isset($attribute['distribution']) && $attribute['distribution'] == 4) { + $canSGBeUsed = $this->MispObject->Event->SharingGroup->checkIfCanBeUsed( + $this->Auth->user(), + $this->_isRest(), + ['sharing_group_id' => $attribute['sharing_group_id'] ?? 0] + ); + if ($canSGBeUsed !== true) { + throw new MethodNotAllowedException($canSGBeUsed); + } + } + } + } + // ajax edit - post a single edited field and this method will attempt to save it and return a json with the validation errors if they occur. public function editField($id) {
Vulnerability mechanics
Root cause
"The sharing group authorization check in ObjectsController::edit() examined the wrong data structure after array_merge moved the distribution field, and attributes embedded in objects were never individually validated for sharing group permissions."
Attack vector
An authenticated user who already has permission to edit a MISP object sends a crafted HTTP request with `distribution` set to `4` (sharing group) and an arbitrary `sharing_group_id`. Because the `edit()` method merges `request->data['Object']` to the top level and then checks `data['Object']['distribution']` — which no longer exists — the sharing group authorization check is completely skipped. Neither does the code validate the sharing group of any attributes nested inside the object payload. The attacker can thus assign any sharing group, potentially learning the existence or name of otherwise non-visible sharing groups [CWE-200] and modifying distribution metadata.
Affected code
The vulnerability resides in `ObjectsController::edit()` (`app/Controller/ObjectsController.php`). After the `Object` fields are merged to the top level and the `data['Object']` key is unset, the original sharing group validation still referenced `$this->request->data['Object']['distribution']`, which could never be true, bypassing the check. Additionally, `ObjectsController::add()` and `edit()` performed no per-attribute sharing group validation for attributes embedded within objects.
What the fix does
The patch corrects the distribution check in `edit()` to reference `$this->request->data['distribution']` instead of the stale `$this->request->data['Object']['distribution']`, ensuring the sharing group authorization is actually evaluated after the field merge. It also introduces `__validateAttributeSharingGroups()`, a private method that loops over each attribute in the object payload and verifies that any attribute with `distribution == 4` references a sharing group the current user is authorized to use. Both `add()` and `edit()` now call this new validation, closing the gap where embedded attributes could be assigned to arbitrary sharing groups.
Preconditions
- authThe attacker must have a valid MISP user account with permission to edit objects.
- networkThe attacker must be able to send HTTP requests to the MISP application, either via the REST API or the web UI.
- inputThe attacker must craft a request payload containing distribution=4 and an arbitrary sharing_group_id in the object and/or its attributes.
Generated on Jun 12, 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.