An authorization flaw in MISP allowed an authenticated user to submit a sharinggroupid without verifying that the user was authorized to use the referenced Sharing Group.

In several attribute and Galaxy Cluster creation and editing workflows, validation of the submitted Sharing Group was performed only when the request explicitly set the distribution field to 4 ("Sharing Group"). An attacker could therefore craft a request containing a sharinggroupid while omitting the distribution parameter, or otherwise avoiding the distribution == 4 condition, causing the Sharing Group authorization check to be skipped.

This could allow a user with permission to create or modify the affected MISP objects to associate data with a Sharing Group that they are not authorized to use. Depending on the affected object's existing distribution settings and subsequent processing, this could bypass intended information-sharing boundaries and result in unauthorized placement or distribution of data to members of another Sharing Group.

The issue affected attribute attachment and editing operations as well as Galaxy Cluster creation and editing. The fix ensures that authorization is performed whenever a non-empty sharinggroupid is submitted, independently of the distribution parameter. It also centralizes the authorization decision in SharingGroup::canUse() and explicitly rejects empty Sharing Group identifiers rather than allowing them to be interpreted as an unrestricted query.

MISP contains a reflected Cross-Site Scripting (XSS) vulnerability in the event attribute filtering query builder. The taggedAttributes and galaxyAttachedAttributes URL parameters were inserted into the query-builder rules without HTML escaping before being serialized as JSON and embedded inside a <script> element.

Because JsonTool::encode() uses JSONUNESCAPEDSLASHES, an attacker-controlled value containing a closing </script> sequence could terminate the surrounding script element and inject arbitrary HTML or JavaScript. For example, a specially crafted viewEventAttributes URL could contain malicious content in one of the affected filter parameters.

An attacker could exploit the vulnerability by convincing an authenticated MISP user to follow a crafted URL. Successful exploitation would execute attacker-controlled JavaScript in the security context of the MISP instance and with the privileges of the victim's authenticated browser session. This could allow access to information available to the victim, modification of data through authenticated requests, or other actions permitted by the victim's MISP permissions.

The vulnerability is addressed by applying HTML escaping with h() to both scalar and array values before they are inserted into the DOM.

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’s OIDC authentication plugin allowed automatic linking of an OIDC identity to an existing local user account based on the email claim when the local account had no stored sub value. Under insecure or untrusted IdP configurations where email ownership is not enforced, an attacker with a valid OIDC token could assert a victim’s email address and authenticate as that user, leading to account takeover.

A URL validation flaw in the MISP dashboard button widget allowed a crafted relative-looking URL to be accepted as a local path while being interpreted by browsers as an external URL. The validation rejected URLs containing an explicit scheme, host, or user component, but did not reject paths beginning with a slash followed by a backslash, such as /\example.com. Some browsers normalize backslashes in URLs as forward slashes, which can turn this into a scheme-relative external navigation target. In addition, the generated href concatenated the reconstructed URL with the original URL, increasing the possibility of unsafe or malformed link generation.

An attacker able to configure or influence a dashboard button URL could craft a button that appears to point inside the application but redirects users to an attacker-controlled site when clicked. This could be used for phishing, credential theft, or social engineering. The patch fixes the issue by rejecting empty paths and paths starting with /\, and by emitting only the reconstructed validated URL in the anchor href.

A visibility control issue in the event template creation workflow allowed non-site-admin users to access private galaxies belonging to other organisations. The event template builder loaded all enabled galaxies without applying organisation or distribution-based access restrictions, potentially exposing private galaxy metadata such as galaxy type and description to users who should not have visibility.

The issue has been fixed by restricting galaxy queries for non-site-admin users to galaxies owned by the user’s organisation or galaxies with a non-private distribution setting. Site administrators retain visibility of all enabled galaxies.

An authorization flaw existed in the MISP Event Template Importer overwrite workflow. When importing an event template in overwrite mode, the application checked whether a matching template already existed but did not verify that the importing user belonged to the organization that owned the existing template. As a result, an authenticated user with access to the template import functionality could forcibly overwrite an event template owned by another organization.

Successful exploitation could allow unauthorized modification of another organization’s event template, potentially altering template structure, attributes, or metadata used for subsequent event creation or sharing workflows. Site administrators are not affected by this restriction, as they are explicitly allowed to overwrite templates across organizations.

The issue was fixed by enforcing an ownership check before overwrite: non-site-admin users may only overwrite templates owned by their own organization.

A mass assignment vulnerability exists in the MISP user edit functionality due to insufficient filtering of user-supplied fields in UsersController::edit(). When processing edit requests, the application accepted a user-controlled User.id value from request data. An authenticated attacker could craft a modified request containing another user identifier, potentially causing updates to be applied to an unintended user account. Depending on the editable fields and the attacker’s privileges, this could allow unauthorized modification of user account attributes and impact account integrity.

The issue was addressed by explicitly removing the User.id field from request data before processing the user edit operation.

An authentication bypass vulnerability exists in MISP when LDAP mixed authentication is enabled with OTP enforcement. In deployments configured with LdapAuth.mixedAuth=true and Security.requireotp=true, users authenticated through an authentication plugin, such as LDAP, may have their authenticated session established during the application beforeFilter phase before the normal login flow enforces the OTP challenge.

As a result, an attacker with valid primary authentication credentials could bypass the required OTP step by authenticating through the plugin-backed login flow and then directly accessing another application URL instead of completing the OTP verification page. This allows access to the application as the affected user without providing a valid TOTP, HOTP, or email OTP code.

The issue affects configurations where plugin-based authentication is enabled and OTP is expected to be mandatory. The fix ensures that OTP requirements are checked immediately after plugin authentication and before the user session is established, redirecting users to the appropriate OTP challenge when required.

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 (sessionid()) 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 hashequals().

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 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 permadd 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 permsharinggroup 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 allowed an authenticated site administrator to set the Kafkardkafkaconfig 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.

Multiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (id) and ownership/scope foreign keys (eventid, orgid, userid, sharinggroupid, galaxyclusteruuid, organisationuuid, and related nested object identifiers) without consistently stripping, pinning, or revalidating them against the server-authorized object.

In affected paths, an authenticated user with access to one authorized object could submit crafted REST or form payloads that caused MISP to save data against a different object than the one checked by the authorization logic. Depending on the endpoint, this could allow object overwrite, object re-parenting, ownership transfer, unauthorized sharing-group scoping, event/object injection, proposal retargeting, or stored attacker-controlled content appearing in another user’s context.

The fixes harden affected create/edit/import flows by stripping client-supplied primary keys on create-only saves, re-pinning route- or database-authorized identifiers before save operations, validating effective sharing-group scope, and adding field whitelists where ownership fields must never be editable. The initial broad fix also added a central CRUDComponent::edit() primary-key re-pin so payload-supplied IDs cannot redirect saves away from the already-authorized row. GitHub’s patch for 7acf8220c describes this central issue as CRUDComponent::edit() copying supplied fields, including a payload primary key, onto the loaded record, allowing CakePHP save() to update an arbitrary row unless the loaded ID is re-pinned.

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 REMOTEUSER (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.

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, 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.

A vulnerability in MISP’s non-REST event editing path allowed an authenticated user with event edit permissions to manipulate the submitted form data and set an event’s sharinggroupid to a sharing group they were not authorized to use. When distribution was set to sharing group distribution, the non-REST save path accepted the submitted sharinggroupid without performing the same sharing group authorization check enforced by the REST edit path.

An attacker could exploit this by tampering with the event edit request and assigning an event to an undisclosed or unauthorized sharing group. This could result in unauthorized use of restricted sharing groups, disclosure of the sharing group name in event listings, and unintended modification of the event’s distribution metadata.

The issue is fixed by validating that the selected sharing group can be used by the current user when the sharing group is changed, and by clearing sharinggroupid when the event distribution is not set to sharing group distribution.

MISP contained multiple mass assignment vulnerabilities in the handling of collections, tag collections, event delegations, and shadow attributes. Several controller actions accepted user-supplied fields that should have remained server-controlled, including record identifiers and ownership-related fields such as id, orgid, orgcid, and userid.

An authenticated attacker with access to the affected endpoints could craft requests containing protected fields in order to alter object ownership, redirect an update to another record, overwrite existing event delegation requests, or modify shadow attribute proposals belonging to another organization. This could result in unauthorized modification of MISP objects and, depending on object visibility and sharing configuration, unauthorized access to or transfer of sensitive threat intelligence data.

The issue was fixed by explicitly pinning ownership and identity fields to their stored values during edit operations and by removing user-supplied primary keys from create-only save paths.

Affected components:

CollectionsController::edit() EventDelegationsController::delegateEvent() ShadowAttributesController::edit() TagCollectionsController::edit()915 TagCollectionsController::editWithTags()

Attack requirements: The attacker must be authenticated and able to reach the affected MISP endpoints. No user interaction is required.

MISP contains an insecure default configuration in which the Security.checksecfetchsiteheader control is disabled. When this setting is disabled, state-changing requests such as POST, PUT, or AJAX requests are not restricted based on the browser-provided Sec-Fetch-Site header. A remote unauthenticated attacker could craft a malicious web page that causes an authenticated MISP user’s browser to issue cross-site requests to MISP automation endpoints. If successful, the forged requests may be processed with the privileges of the victim user, potentially allowing unauthorized modification of MISP data or configuration. Enabling Security.checksecfetchsiteheader mitigates this issue, although operators of multi-homed MISP deployments should validate the setting before enforcing it.

An incorrect authorization vulnerability in MISP allows an organization administrator to target site administrator accounts belonging to the same organization through the administrative email functionality. The affected code restricted organization administrators to users within their own organization, but did not exclude accounts assigned a site administrator role from recipient queries. As a result, an organization administrator could perform privileged account-management actions, such as initiating a password reset workflow, against a higher-privileged site administrator account in the same organization.

Successful exploitation may allow an authenticated organization administrator to interfere with or potentially take over a site administrator account, resulting in privilege escalation and full compromise of the MISP instance’s confidentiality, integrity, and availability.

Attack prerequisites: The attacker must be authenticated as an organization administrator in the same organization as a site administrator account.

An information disclosure vulnerability exists in the MISP AuthKey edit functionality. When a validation error occurs during an AuthKey edit request, the user dropdown was populated using the attacker-controlled AuthKey.userid value from the submitted request data. An authenticated user with permission to edit an AuthKey could submit arbitrary user IDs and observe the returned dropdown data, allowing enumeration of user email addresses. The issue is fixed by deriving the dropdown user from the persisted AuthKey owner instead of the request body.

An incorrect visibility condition in the MISP event template builder allowed authenticated non-site-admin users to view galaxies that should not have been visible to their organisation. The custom access-control condition intended to restrict galaxies to those owned by the user’s organisation or distributed beyond it used a PHP comparison expression instead of a query condition. As a result, enabled galaxies, including organisation-only custom galaxies belonging to other organisations, could be exposed in the template builder galaxy list. This could disclose metadata about private galaxy definitions to unauthorised users.

An improper authorization vulnerability in MISP allowed an authenticated organization administrator to access or modify user settings belonging to site administrator accounts within the same organization. The affected access-control checks scoped administrative actions by organization membership but did not exclude higher-privileged site administrator users. As a result, an organization administrator could potentially view or alter site administrator user settings and related login profile information, crossing the intended privilege boundary between organization administration and site-wide administration.

The patch hardens the ACL logic by excluding site administrator accounts from organization administrator–managed user sets, adding explicit authorization failure when a target user is not administrable, and ensuring user setting and login profile operations fail closed.

Cross site scripting in some view elements in the index filter tool in app/webroot/js/misp2.4.68.js and the organisation landing page in app/View/Organisations/ajax/landingpage.ctp of MISP before 2.4.69 allows remote attackers to inject arbitrary web script or HTML.