CVE-2026-56422 (GCVE-0-2026-56422)
Vulnerability from cvelistv5 – Published: 2026-06-22 11:43 – Updated: 2026-06-22 11:43
VLAI
Title
MISP Core: Mass Assignment and Object Re-ownership via Unvalidated Request Fields
Summary
Multiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (id) and ownership/scope foreign keys (event_id, org_id, user_id, sharing_group_id, galaxy_cluster_uuid, organisation_uuid, and related nested object identifiers) without consistently stripping, pinning, or revalidating them against the server-authorized object.
In affected paths, an authenticated user with access to one authorized object could submit crafted REST or form payloads that caused MISP to save data against a different object than the one checked by the authorization logic. Depending on the endpoint, this could allow object overwrite, object re-parenting, ownership transfer, unauthorized sharing-group scoping, event/object injection, proposal retargeting, or stored attacker-controlled content appearing in another user’s context.
The fixes harden affected create/edit/import flows by stripping client-supplied primary keys on create-only saves, re-pinning route- or database-authorized identifiers before save operations, validating effective sharing-group scope, and adding field whitelists where ownership fields must never be editable. The initial broad fix also added a central CRUDComponent::edit() primary-key re-pin so payload-supplied IDs cannot redirect saves away from the already-authorized row. GitHub’s patch for 7acf8220c describes this central issue as CRUDComponent::edit() copying supplied fields, including a payload primary key, onto the loaded record, allowing CakePHP save() to update an arbitrary row unless the loaded ID is re-pinned.
Severity
CWE
- CWE-639 - Authorization Bypass Through User-Controlled Key
Assigner
References
16 references
Credits
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "misp",
"repo": "https://github.com/misp/misp",
"vendor": "misp",
"versions": [
{
"lessThanOrEqual": "2.5.41",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "remediation developer",
"value": "Andras Iklody"
},
{
"lang": "en",
"type": "analyst",
"value": "Jeroen Pinoy"
},
{
"lang": "en",
"type": "tool",
"value": "Claude (the international export version)"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eMultiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (\u003ccode\u003eid\u003c/code\u003e) and ownership/scope foreign keys (\u003ccode\u003eevent_id\u003c/code\u003e, \u003ccode\u003eorg_id\u003c/code\u003e, \u003ccode\u003euser_id\u003c/code\u003e, \u003ccode\u003esharing_group_id\u003c/code\u003e, \u003ccode\u003egalaxy_cluster_uuid\u003c/code\u003e, \u003ccode\u003eorganisation_uuid\u003c/code\u003e, and related nested object identifiers) without consistently stripping, pinning, or revalidating them against the server-authorized object.\u003c/p\u003e\u003cp\u003eIn affected paths, an authenticated user with access to one authorized object could submit crafted REST or form payloads that caused MISP to save data against a different object than the one checked by the authorization logic. Depending on the endpoint, this could allow object overwrite, object re-parenting, ownership transfer, unauthorized sharing-group scoping, event/object injection, proposal retargeting, or stored attacker-controlled content appearing in another user\u2019s context.\u003c/p\u003e\u003cp\u003eThe fixes harden affected create/edit/import flows by stripping client-supplied primary keys on create-only saves, re-pinning route- or database-authorized identifiers before save operations, validating effective sharing-group scope, and adding field whitelists where ownership fields must never be editable. The initial broad fix also added a central \u003ccode\u003eCRUDComponent::edit()\u003c/code\u003e\u0026nbsp;primary-key re-pin so payload-supplied IDs cannot redirect saves away from the already-authorized row. GitHub\u2019s patch for \u003ccode\u003e7acf8220c\u003c/code\u003e\u0026nbsp;describes this central issue as \u003ccode\u003eCRUDComponent::edit()\u003c/code\u003e\u0026nbsp;copying supplied fields, including a payload primary key, onto the loaded record, allowing CakePHP \u003ccode\u003esave()\u003c/code\u003e\u0026nbsp;to update an arbitrary row unless the loaded ID is re-pinned. \u003c/p\u003e\u003cbr\u003e"
}
],
"value": "Multiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (id) and ownership/scope foreign keys (event_id, org_id, user_id, sharing_group_id, galaxy_cluster_uuid, organisation_uuid, and related nested object identifiers) without consistently stripping, pinning, or revalidating them against the server-authorized object.\n\nIn affected paths, an authenticated user with access to one authorized object could submit crafted REST or form payloads that caused MISP to save data against a different object than the one checked by the authorization logic. Depending on the endpoint, this could allow object overwrite, object re-parenting, ownership transfer, unauthorized sharing-group scoping, event/object injection, proposal retargeting, or stored attacker-controlled content appearing in another user\u2019s context.\n\nThe fixes harden affected create/edit/import flows by stripping client-supplied primary keys on create-only saves, re-pinning route- or database-authorized identifiers before save operations, validating effective sharing-group scope, and adding field whitelists where ownership fields must never be editable. The initial broad fix also added a central CRUDComponent::edit()\u00a0primary-key re-pin so payload-supplied IDs cannot redirect saves away from the already-authorized row. GitHub\u2019s patch for 7acf8220c\u00a0describes this central issue as CRUDComponent::edit()\u00a0copying supplied fields, including a payload primary key, onto the loaded record, allowing CakePHP save()\u00a0to update an arbitrary row unless the loaded ID is re-pinned."
}
],
"impacts": [
{
"capecId": "CAPEC-115",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-115 Authentication Bypass"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"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:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"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"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-22T11:43:02.690Z",
"orgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"shortName": "CIRCL"
},
"references": [
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/7acf8220cafac58bcfb362da37aca512fe4bb396"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/bc182d55dde5686a36ca2eb88fe6c2adabb9fad9"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/58f637aaab4d133e72f1454ebb963191d96d3b78"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/05aad418c57bb78e6b58a843d70d45de8f50db45"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/63aebc27a878233b9475c742985aaef909bc755b"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/00b2e3dae56fa24ea750eb525cc4709b7e5bee85"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/634f1f87c295193486c08c2c7ba1fee8a7339baa"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/ab9619dfa6cb5210fd20fb3b0b57006e4fc93916"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/8311427c2edd72a8341f0a65e1f11073d7ad9191"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/c80a3533b3d787f45f5185a4621cc0f05b0cf2e5"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/025f711506850aadb69cde1b57e5e5d57628c87f"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/3ff6bd9cfdab5d41b4667ea7298d88ffd6f3fcb8"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/84bafe69f5d0ab7f811371c0801a613f271ebc0b"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/2cc26f38f3e85c594957899f09043d5193146607"
},
{
"tags": [
"patch"
],
"url": "https://github.com/MISP/MISP/commit/57433015815e59db5a1f11536f90920952cf3fcd"
},
{
"url": "https://github.com/MISP/MISP/commit/9341690e9b6dde7f0605edea5533e05ba7362e35"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "MISP Core: Mass Assignment and Object Re-ownership via Unvalidated Request Fields",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "5a6e4751-2f3f-4070-9419-94fb35b644e8",
"assignerShortName": "CIRCL",
"cveId": "CVE-2026-56422",
"datePublished": "2026-06-22T11:43:02.690Z",
"dateReserved": "2026-06-22T11:42:55.345Z",
"dateUpdated": "2026-06-22T11:43:02.690Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
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.
Loading…
Loading…