MISP EUVD-2026-94400

Three concrete preconditions must all hold: (1) two or more MISP instances are configured to synchronize objects (multi-instance sync topology, not a standalone deployment); (2) a user holding object-creation privileges creates a MISP Object while leaving the description field empty; and (3) that object is pushed/pulled to a peer instance via the sync mechanism, where the receiving instance's validation rejects it. Limiting factors that reduce real-world risk: the action requires an authenticated user with object-creation rights (PR:L), it only manifests in federated/sync configurations rather than default single-instance setups, there is no external or unauthenticated attack surface, and it can be triggered accidentally rather than requiring adversary control. Affected versions are below 2.5.48.

This is a genuine but low-urgency data-integrity defect rather than an attacker-driven security breach. The CVSS 4.0 base score is 5.3 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:N and the only non-zero impact being VI:L - partial integrity loss on a subsequent/peer system - with confidentiality (VC:N) and availability of the system itself (VA:N) unaffected. No EPSS probability, CISA KEV listing, or public POC was provided in the intelligence set; exploitation status is therefore 'no public exploit identified at time of analysis.' Critically, the vendor's own description states the flaw 'is not externally exploitable in a traditional sense' - it is triggered by any legitimately authorized user (PR:L) creating an object without a description, not by a remote adversary, so the AV:N metric reflects the sync-over-network propagation path rather than an attacker-reachable entry point. The signals are internally consistent (medium CVSS, no exploitation indicators, config/privilege-dependent), pointing to a reliability/data-loss bug that matters for threat-intelligence completeness but is not a priority for exploit-driven patching queues. Note: no EPSS score was supplied, so widespread-scanning likelihood cannot be quantified from the input.

In a federated MISP deployment, an analyst with normal object-creation rights saves a MISP Object (e.g. a file or network-connection object) without filling in the optional description field; it saves fine locally. When the originating instance pushes that event to a synchronized peer, the peer's stricter validation rejects the empty-description object and silently discards it together with every attribute it contained, so downstream consumers never receive that indicator. No public exploit code is required or known - the condition arises from normal authorized use.