CVE-2026-112180 in MISP
Summary
by MITRE • 10/19/2026
MISP contains a data integrity flaw in its event deletion logic. When a user deletes an event, several associated records are not removed from the database, leaving them as orphaned entries. The affected record types include event report tags, event graph entries, proposal (shadow attribute) correlations, fuzzy ssdeep correlation chunks, and attachment scan results.
These orphaned records may contain sensitive threat intelligence data such as correlation mappings, scan results, and report metadata that should have been removed along with the parent event. Their persistence beyond the intended deletion lifecycle creates a risk of unintended data retention and potential information exposure if the records are reachable through other application queries or administrative interfaces.
Preconditions:
- An authenticated user with sufficient privileges to delete events in MISP.
- The event must have associated reports, graphs, correlations, ssdeep chunks, or attachment scan results.
Impact:
- Residual sensitive data persists in the database after the parent event is deleted.
- Accumulation of orphaned records over time may contribute to storage bloat.
- Orphaned records may be inadvertently exposed through other data-access paths that do not validate the existence of the parent event.
Affected versions: <2.5.48
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in MISP prior to version 2.5.48 represents a critical failure in database transaction management and referential integrity enforcement during the event deletion process. This flaw is classified under CWE-613, which denotes insufficient session expiration or CWE-798 if viewed through the lens of data retention policies leading to unauthorized information exposure. The core technical issue lies within the application logic responsible for handling DELETE operations on threat intelligence events. When an administrator or authorized user initiates the deletion of a specific event, the system is designed to remove all associated metadata and linked objects from the underlying database schema. However, due to incomplete cascade delete rules or missing explicit cleanup routines in the codebase, several related record types remain persisted even after their parent entity has been removed. These orphaned records include event report tags, which provide contextual analysis of threats; event graph entries that map relationships between indicators; proposal correlations known as shadow attributes which represent potential but unconfirmed intelligence links; fuzzy ssdeep correlation chunks used for similarity matching of malware samples or file hashes; and attachment scan results detailing antivirus detections on uploaded files.
The persistence of these orphaned records creates a significant data integrity issue within the threat intelligence platform. From an operational perspective, this flaw leads to two primary negative outcomes: information exposure and resource exhaustion. The residual sensitive data retains its original metadata and content, meaning that if any part of the application or external interface allows querying by identifiers such as report IDs, graph node UUIDs, or correlation hashes without verifying the existence of the parent event, an attacker could potentially retrieve this intelligence. This scenario aligns with ATT&CK technique T1078, Valid Accounts, where authenticated users might access data they should no longer have permission to view because the logical link to the deleted container was broken but not physically severed in the database. Furthermore, the accumulation of these orphaned entries over time contributes directly to storage bloat and performance degradation. As more events are deleted without proper cleanup, the database size increases unnecessarily, leading to slower query execution times for legitimate operations and increased backup requirements.
The precondition for exploiting this vulnerability requires an authenticated user with privileges sufficient to delete events in MISP. While this limits direct exploitation by unauthenticated actors, it poses a risk from insider threats or compromised administrative accounts. An attacker with such access could deliberately trigger deletions on high-value intelligence objects while leaving behind sensitive correlation data that might reveal network topology, malware families, or attack campaigns associated with the deleted event. Even if the primary event is gone, the orphaned shadow attributes and graph entries can still be used to reconstruct parts of the threat landscape, violating the principle of least privilege and proper data lifecycle management. This situation also complicates forensic analysis and compliance audits, as records appear in database dumps or logs without a clear parent context, making it difficult to determine their original purpose or validity.
To mitigate this vulnerability, organizations running affected versions of MISP must upgrade immediately to version 2.5.48 or later where the deletion logic has been corrected to ensure all associated child records are properly removed in atomic transactions. For environments that cannot update immediately due to compatibility constraints, manual database cleanup scripts can be employed to identify and delete orphaned entries by checking for foreign key violations against the events table. Administrators should also review their access control policies to ensure that event deletion privileges are granted only to trusted personnel with a clear need for such actions. Implementing regular database integrity checks using tools like pg_dump or custom SQL queries can help detect any existing orphaned records before they accumulate further. Additionally, enabling detailed audit logging on delete operations allows security teams to monitor for unusual patterns of data removal that might indicate malicious intent rather than routine maintenance. By addressing this flaw, organizations restore the intended referential integrity of their threat intelligence database and prevent potential leakage of sensitive correlation mappings and scan results.