CVE-2026-95674 in MISP
Summary
by MITRE • 09/22/2026
In MISP, the queryEnrichment method in EventsController.php accepted a module name parameter and iterated over the list of enabled modules to find a match. If the specified module was not present in the enabled modules list, the code silently continued processing using default parameters (format set to 'simplified' and no module-specific configuration applied) rather than rejecting the request. This allowed an authenticated user to trigger enrichment or analysis processing through a module that was not explicitly enabled or available on the instance, bypassing the intended module availability controls. The lack of validation meant that module names outside the enabled set were not rejected, potentially exposing functionality or data processing paths that the administrator had not authorized for use.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability in MISP involves a critical logic flaw within the queryEnrichment method located in EventsController.php, which governs how external enrichment modules are invoked during event analysis. The core technical issue stems from insufficient input validation regarding module availability controls. When an authenticated user submits a request to enrich or analyze data using a specific module name, the system iterates through its list of enabled modules to locate a match. However, if no matching module is found in this whitelist, instead of rejecting the request with an appropriate error code indicating that the requested functionality is unavailable, the application silently defaults to processing parameters set to 'simplified' format without applying any specific module configuration. This behavior effectively bypasses the administrative intent to restrict access to certain enrichment or analysis tools by allowing execution paths for modules that are not explicitly enabled on the instance.
From a security architecture perspective, this flaw represents a failure in enforcing authorization controls at the application logic level rather than through traditional authentication mechanisms. The system assumes that if a module is not found in the active list, it should fall back to a generic processing mode, but this assumption creates an unintended side channel for functionality exposure. An authenticated attacker can exploit this by specifying arbitrary or non-existent module names to trigger internal code paths that were never intended to be accessible via the API interface. This lack of strict validation allows users to potentially access data processing logic or expose internal states that administrators have deliberately disabled, thereby undermining the principle of least privilege and reducing the effectiveness of security configurations managed through the MISP dashboard.
The operational impact of this vulnerability is significant for organizations relying on MISP for threat intelligence sharing and analysis. By bypassing module availability controls, an attacker could potentially trigger enrichment processes that consume system resources without providing useful output, leading to denial-of-service conditions or performance degradation. Furthermore, if these default processing paths interact with sensitive internal data structures or expose error messages containing stack traces or configuration details, it aids in further reconnaissance and potential exploitation of other vulnerabilities. The silent failure mode is particularly dangerous because it does not alert administrators that an unauthorized access attempt has occurred, allowing malicious activity to persist undetected for extended periods while potentially leaking information about the system's internal capabilities.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-94 Improper Control of Generation of Code (Code Injection) in contexts where dynamic module loading is involved without proper validation. In terms of MITRE ATT&CK, this behavior facilitates lateral movement or privilege escalation within the application context by allowing users to execute functions outside their authorized scope, which can be categorized under Tactic Execution and potentially Tactic Discovery if it leads to information leakage about system capabilities. To mitigate this risk, developers must implement strict validation checks that verify whether a requested module exists in the enabled list before proceeding with any processing logic. If a match is not found, the application should immediately return an HTTP 403 Forbidden or 404 Not Found response rather than falling back to default parameters. Additionally, implementing comprehensive logging for such invalid access attempts will aid in monitoring and detecting exploitation activities. Administrators should also ensure that their MISP instances are updated to versions where this logic flaw has been corrected by the vendor.