CVE-2026-91859 in MISP
Summary
by MITRE • 09/15/2026
Affected versions of MISP can record incorrect access-log data for requests that terminate in an exception.
Because CakeErrorController extends AppController, exception rendering runs the application startup path a second time. As a result, __accessMonitor() calls AccessLog::logRequest() twice for one HTTP request. The second deferred writer measures the error-controller execution instead of the original request and can overwrite the row created by the first pass. The corrupted fields include request duration, SQL query count, memory usage, and potentially the recorded query log.
The bug was masked because the same model instance retained the ID of the first saved row, causing the later save to issue an UPDATE rather than insert an obvious duplicate row.
Version affected: ≤2.5.45
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
MISP versions 2.5.45 and earlier contain a logic flaw in the access logging mechanism that results in corrupted or inaccurate audit trail data for requests that trigger application exceptions. This vulnerability stems from the architectural design of the underlying CakePHP framework, specifically how error handling interacts with the application lifecycle. When an exception occurs during request processing, control is transferred to the CakeErrorController, which extends AppController. Consequently, the application startup sequence executes a second time to render the error page rather than simply returning the response for the original failed request.
The core technical flaw lies in how the access monitoring component handles this dual execution path. The __accessMonitor method invokes AccessLog::logRequest() during both the initial request processing and the subsequent exception rendering phase. Because these two calls occur within the same HTTP transaction, they interact with the database logging table in a way that leads to data overwriting rather than distinct record creation. Specifically, the second invocation measures execution metrics such as duration, SQL query count, memory usage, and potentially captured query logs based on the error controller's performance rather than the original request's actual behavior.
This corruption is exacerbated by how the database model instance manages its state across these two phases. The same model object retains the primary key identifier from the first save operation performed during the initial request processing phase. When the second logging call attempts to persist data, it does not generate a new INSERT statement with a unique identifier as one might expect for separate events. Instead, because the ID is already set on the instance, the framework issues an UPDATE statement targeting the existing row created by the first pass. This effectively overwrites the accurate initial log entry with potentially misleading metrics derived from the error handling process itself.
The operational impact of this vulnerability centers on data integrity within security audit logs and performance monitoring systems that rely on MISP's access logs for forensic analysis or resource tracking. For organizations using these logs to detect anomalies, track user behavior, or troubleshoot system performance, the presence of corrupted entries can lead to false negatives in threat detection or inaccurate capacity planning decisions. The distortion of metrics such as request duration and memory usage makes it difficult to distinguish between normal operational latency and issues caused by application errors, thereby reducing the reliability of automated monitoring tools that parse these logs for alerts.
From a classification perspective, this issue aligns with CWE-697, which refers to Incorrect Comparison, although in this context, it is more accurately described as CWE-829, Inclusion of Functionality from Untrusted Control Sector, due to the unintended side effects of framework error handling logic interacting with application state. It also relates to CWE-354, Improper Validation of Integrity Check Value, if one considers the integrity of the log data itself being compromised by improper validation of when a new record versus an update is appropriate. In terms of MITRE ATT&CK, this does not represent a direct attack vector for exploitation but rather represents a weakness in Defense Mechanism 1405, Log Analysis, where the quality and accuracy of telemetry are degraded, potentially hindering incident response efforts that depend on precise log data to reconstruct events.
Mitigation strategies primarily involve upgrading MISP to version 2.5.46 or later, where this logic has been corrected to ensure distinct logging behavior for exception handling paths. For environments unable to upgrade immediately, administrators should consider implementing a workaround at the application level by ensuring that access logs are flushed and cleared before entering the error rendering phase, thereby preventing the second write operation from targeting the same database row. Additionally, reviewing log parsing rules in downstream SIEM or monitoring tools can help identify and filter out entries with anomalous duration values or unexpected patterns indicative of this specific bug, although upgrading remains the only definitive resolution to restore data integrity.