CVE-2026-95671 in MISP
Summary
by MITRE • 09/22/2026
In MISP, the CollectionsController add() method enforced the sharing-group usability authorization check and element capture only when the HTTP request method was POST. However, the underlying CRUDComponent::add() method persists data on both POST and PUT requests. As a result, an authenticated user could issue a PUT request to the collections/add endpoint, bypassing the sharing-group authorization check entirely. This allowed the creation of a collection with distribution=4 (shared with a specific sharing group) targeting a sharing group that the user was not authorized to use. The bypassed check would normally verify that the current user has access to the specified sharing group before allowing the collection to be associated with it.
The security impact is that an authenticated user can place collection data into a sharing group context they do not have legitimate access to, potentially exposing that data to all members of the unauthorized sharing group and violating the intended access-control boundaries of the MISP instance.
The vulnerability requires an authenticated session and knowledge of a valid sharing group identifier; no user interaction or special tooling is needed beyond sending a PUT request instead of a POST request to the same endpoint.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The identified vulnerability in the Misp (Malware Information Sharing Platform) application represents a critical authorization bypass rooted in inconsistent HTTP method handling within its controller logic. Specifically, the CollectionsController add() method was designed to enforce sharing-group usability checks and element capture exclusively when processing POST requests. This design decision created a security gap because the underlying CRUDComponent::add() method responsible for persisting data operates on both POST and PUT request methods without applying the same restrictive authorization filters. Consequently, an authenticated user could exploit this discrepancy by issuing a PUT request to the collections/add endpoint rather than the standard POST request. By doing so, the attacker effectively bypassed the sharing-group authorization check that was intended to verify whether the current user has legitimate access rights to the specified sharing group before allowing the collection to be associated with it.
This technical flaw allows an authenticated user to create a new collection and assign it a distribution level of four, which signifies sharing with a specific sharing group. Since the authorization logic is skipped during PUT requests, the system fails to validate if the requesting user possesses the necessary permissions for that particular sharing group. As a result, data intended for restricted access can be placed into a sharing group context where the creator has no legitimate authority. This violation of access-control boundaries means that sensitive threat intelligence or malware samples could inadvertently become visible to all members of the unauthorized sharing group, leading to significant information disclosure and potential compromise of operational security within the MISP instance.
The impact of this vulnerability is severe as it undermines the fundamental trust model of collaborative threat intelligence platforms like MISP. Sharing groups are designed to ensure that sensitive data is only shared with trusted partners who have undergone proper vetting processes. By allowing users to bypass these checks, an attacker can leak confidential information to entities outside their authorized circle. This not only violates privacy and confidentiality requirements but also risks contaminating the broader intelligence community with unverified or maliciously sourced data if the unauthorized sharing group members act on the leaked information. The vulnerability requires no special tooling beyond standard HTTP capabilities, making it easily exploitable by any authenticated user who understands basic web request structures.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if static identifiers were involved, though primarily it is an authorization bypass due to inconsistent enforcement logic. In the context of the MITRE ATT&CK framework, this vulnerability facilitates lateral movement within trusted networks or data exfiltration by allowing unauthorized access to restricted datasets. To mitigate this risk, developers must ensure that all HTTP methods interacting with sensitive endpoints undergo consistent and identical security checks regardless of whether they are POST, PUT, PATCH, or DELETE requests. Implementing a centralized authorization middleware that applies uniformly across all controller actions would prevent such method-based bypasses. Additionally, rigorous code reviews focusing on CRUD component behaviors can help identify similar inconsistencies in other parts of the application where different HTTP verbs might be handled with varying levels of security scrutiny.