| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| MISP allowed a site administrator to configure an arbitrary filesystem path for the NDJSON error log used by JsonLogTool. Because log entries can include attacker-controlled content, an authenticated attacker with site administrator privileges could direct log output to a PHP file in a web-accessible directory and inject PHP code through logged data. Accessing the resulting file could lead to remote code execution with the privileges of the web server process.
The fix restricts log destinations to existing directories beneath APP/tmp/logs or /var/log, requires absolute paths, rejects stream wrappers and traversal-related input, and limits filenames to .log or .ndjson extensions while disallowing executable extension segments. |
| MISP Core contained broken access-control checks in the bulk deletion flows for Event Reports and Sharing Groups. The affected deleteSelection handlers authorized deletion using broad role-level permissions instead of validating authorization for each selected object.
For Event Reports, EventReportsController::deleteSelection relied on the global perm_add capability rather than a per-report ownership/authorization check. As a result, a contributor-level user could submit report IDs or UUIDs for reports belonging to other organisations and hard-delete them instance-wide. The fix changed the callback to call EventReport::fetchIfAuthorized($user, $itemId, 'delete') for each selected report before deletion.
For Sharing Groups, SharingGroupsController::deleteSelection relied on the global perm_sharing_group capability rather than verifying ownership of each selected sharing group. This allowed a sharing-group-capable user to hard-delete sharing groups owned by other organisations, bypassing the per-object ownership gate used by the single-object delete action. The fix changed the callback to call SharingGroup::checkIfOwner($user, $itemId) for each selected sharing group.
An authenticated attacker with the relevant broad role permission could abuse the affected bulk deletion endpoints to delete objects outside their organisation’s authorization scope, causing loss of event-report content or sharing-group configuration across the instance. |
| MISP core contained multiple broken access-control flaws where authorization checks were performed against the wrong entity, or where ownership/editability checks were missing on write paths. In affected subsystems, a lower-privileged authenticated user with the relevant feature permission could cause the application to authorize one object but mutate another, or could modify objects that were merely visible rather than editable by the user’s organization.
The affected paths included:
* Event Reports tag removal: the route-authorized report could differ from the report ID used for tag detachment, enabling cross-organization tag removal from another event report
* Collection Elements bulk deletion: bulk deletion authorized against a collection whose ID matched the collection-element row ID, rather than the element’s actual parent collection, enabling deletion of elements from collections the user did not own.
* Analyst Data capture/update: nested analyst data updates could overwrite an existing record without applying the normal canEditAnalystData ownership check, enabling cross-organization overwrite of analyst data records.
* Template Elements editing: editing authorized against a template whose ID matched the template-element ID, rather than the element’s actual parent template, enabling unauthorized edits to another organization’s template elements.
* Decaying Model editing and mappings: write paths loaded models using view-scope access but did not verify edit ownership, enabling users to edit or remap visible models owned by another organization.
Successful exploitation could allow an authenticated user with subsystem-specific permissions to perform unauthorized cross-organization modifications or deletions of MISP data, resulting in integrity loss, unauthorized tampering with shared intelligence, and disruption of analyst workflows. |
| The Azure Active Directory (AAD) authentication implementation contained multiple weaknesses in its OAuth 2.0 authorization flow that could allow attackers to bypass important security guarantees provided by the protocol.
The application used the PHP session identifier (session_id()) as the OAuth state parameter. Because session identifiers are long-lived authentication credentials, exposing them in OAuth redirect URLs could leak valid session tokens through browser history, HTTP Referer headers, reverse proxies, access logs, or third-party infrastructure involved in the authentication flow. If obtained by an attacker, the leaked session identifier could potentially be used for session hijacking.
Additionally, the implementation did not regenerate the session identifier after successful authentication, leaving authenticated sessions susceptible to session fixation attacks where an attacker forces a victim to use a known session identifier before login and later reuses that identifier after authentication.
The OAuth state value was also not implemented as a dedicated, single-use nonce. This weakened CSRF protections and increased the risk of replay attacks against the OAuth callback process.
The authentication flow further failed to enforce HTTPS for the configured OAuth redirect URI. If a non-HTTPS redirect URI was used, OAuth authorization codes and access tokens could traverse the network in plaintext, exposing sensitive credentials to network attackers.
Finally, OAuth error responses containing attacker-controlled GET parameters were logged verbatim. An attacker could inject control characters or crafted log content, leading to log forging, log injection, or corruption of audit records.
The fix introduces:
*
A dedicated cryptographically random OAuth state value.
*
Single-use state validation and invalidation.
*
Constant-time state comparison using hash_equals().
*
Session identifier rotation after successful authentication.
*
Enforcement of HTTPS-only redirect URIs.
*
Sanitized and length-limited logging of OAuth error parameters.
AAD Authentication Plugin (OAuth 2.0 / Azure Active Directory integration) |
| MISP allowed an authenticated site administrator to set the Kafka_rdkafka_config setting to an arbitrary filesystem path. MISP subsequently parsed the referenced INI file and passed its options to rdkafka. A crafted attacker-controlled configuration file could use rdkafka options such as plugin.library.paths to load an external library, resulting in arbitrary code execution with the privileges of the MISP process. An attacker could leverage a MISP-writable location, such as an uploaded file or administrative image, to host the malicious configuration file.
The issue is fixed by restricting the setting to absolute .ini files located only in approved configuration directories outside the webroot and MISP upload targets. |
| A vulnerability was identified in the ShadowAttribute proposal creation workflow. The add action accepted user-controlled ShadowAttribute request data without removing the id field before saving the record. Because the underlying framework treats a supplied primary key as an instruction to update an existing record, an authenticated user able to submit shadow attribute proposals could provide the identifier of an existing ShadowAttribute and cause that record to be updated instead of creating a new proposal.
This can result in unauthorized modification of existing shadow attributes, potentially affecting proposals associated with events the user should not be able to alter. Depending on deployment configuration and accessible API responses, the issue may also expose or move proposal data across event contexts.
The vulnerability is caused by trusting a client-supplied primary key during object creation. The fix removes the id field from incoming ShadowAttribute data before processing, ensuring that the endpoint always creates a new proposal rather than updating an existing one. This has been fixed in MISP 2.5.38. |
| The CSP report endpoint in MISP intended to limit logged CSP reports to 1 KB but incorrectly allowed reports up to 1 MB before truncation. On deployments where the endpoint is reachable by untrusted clients, this could allow attackers to generate excessive log volume and contribute to resource exhaustion or log flooding. |
| MISP is an open source threat intelligence and sharing platform. Prior to 2.5.37, MISP Collections did not enforce RFC 4122 UUID validation on the uuid field. As a result, a user able to create or modify Collection records could submit malformed UUID values, potentially causing integrity issues or unexpected behaviour in code paths that assume Collection UUIDs are valid identifiers. This vulnerability is fixed in 2.5.37. |
| MISP is an open source threat intelligence and sharing platform. Prior to 2.5.37, an improper access control vulnerability in the authentication key reset functionality allowed an authenticated organization administrator to reset authentication keys belonging to site administrator accounts within the same organization. Because non-site administrators were not explicitly prevented from accessing or resetting site administrator auth keys, an attacker with organization administrator privileges could potentially obtain a newly generated auth key for a higher-privileged account and use it to escalate privileges. This vulnerability is fixed in 2.5.37. |
| MISP is an open source threat intelligence and sharing platform. Prior to 2.5.37, a SQL injection vulnerability existed in the handling of user-controlled ordering parameters in the event and shadow attribute listing endpoints. The affected code accepted order or sort values from request parameters and incorporated them into database query ordering clauses without sufficient validation of the requested field name. An attacker with access to the affected endpoints could craft a malicious ordering parameter to manipulate the generated SQL query. Depending on database permissions and query context, this could potentially allow unauthorized access to data, modification of query behavior, or other database-level impact. This vulnerability is fixed in 2.5.37. |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in misp allows Stored XSS.
This issue affects MISP before 2.5.37.
A stored cross-site scripting vulnerability exists in the template element attribute handling logic. The application accepted arbitrary values for the TemplateElementAttribute type and category fields without validating them against the known MISP attribute type and category definitions. An attacker with permission to create or modify template element attributes could store a crafted type value.
This affects the old templating (not more accessible in 2.5.37) engine from MISP which will be removed in 2.5.38 |
| MISP is an open source threat intelligence and sharing platform. Prior to 2.5.36, improper neutralization of special elements in an LDAP query in ApacheAuthenticate.php allows LDAP injection via an unsanitized username value when ApacheAuthenticate.apacheEnv is configured to use a user-controlled server variable instead of REMOTE_USER (such as in certain proxy setups). An attacker able to control that value can manipulate the LDAP search filter and potentially bypass authentication constraints or cause unauthorized LDAP queries. This vulnerability is fixed in 2.5.36. |
| In MISP before 2.5.28, app/View/Elements/Workflows/executionPath.ctp allows XSS in the workflow execution path. |
| In app/Controller/Component/RestResponseComponent.php in MISP before 2.4.193, REST endpoints have a lack of sanitization for non-JSON responses. |
| In MISP before 2.4.193, menu_custom_right_link parameters can be set via the UI (i.e., without using the CLI) and thus attackers with admin privileges can conduct XSS attacks via a global menu link. |
| In MISP before 2.4.193, menu_custom_right_link_html parameters can be set via the UI (i.e., without using the CLI) and thus attackers with admin privileges can conduct XSS attacks against every page. |
| app/View/Helper/CommandHelper.php in MISP before 2.4.79 has persistent XSS via comments. It only impacts the users of the same instance because the comment field is not part of the MISP synchronisation. |
| MISP before 2.4.81 has a potential reflected XSS in a quickDelete action that is used to delete a sighting, related to app/View/Sightings/ajax/quickDeleteConfirmationForm.ctp and app/webroot/js/misp.js. |
| In the sharingGroupPopulateOrganisations function in app/webroot/js/misp.js in MISP 2.4.82, there is XSS via a crafted organisation name that is manually added. |
| The admin_edit function in app/Controller/UsersController.php in MISP 2.4.82 mishandles the enable_password field, which allows admins to discover a hashed password by reading the audit log. |
