In MISP before 2.4.187, uploadLogo in app/Controller/OrganisationsController.php does not properly check for a valid logo upload.

In MISP before 2.4.187, addmispexport in app/Controller/EventsController.php does not properly check for a valid file upload.

In MISP before 2.4.148, app/Lib/Export/OpendataExport.php mishandles parameter data that is used in a shellexec call.

app/Controller/Component/IndexFilterComponent.php in MISP before 2.4.167 mishandles orderedurlparams and additionaldelimiters.

An issue was discovered in MISP before 2.4.158. PHAR deserialization can occur.

MISP before 2.4.135 lacks an ACL check, related to app/Controller/GalaxyElementsController.php and app/Model/GalaxyElement.php.

MISP 2.4.148, in certain configurations, allows SQL injection via the app/Model/Log.php $conditions['org'] value.

app/View/Elements/genericElements/IndexTable/Fields/genericfield.ctp in MISP 2.4.144 does not sanitize certain data related to generic-template:index.

An issue was discovered in MISP 2.4.128. app/Controller/AttributesController.php has insufficient ACL checks in the attachment downloader.

MISP MISP-maltego 1.4.4 incorrectly shares a MISP connection across users in a remote-transform use case.

An issue was discovered in app/Controller/UsersController.php in MISP 2.4.92. An adversary can bypass the brute-force protection by using a PUT HTTP method instead of a POST HTTP method in the login part, because this protection was only covering POST requests.

MISP before 2.4.166 unsafely allows users to use the order parameter, related to app/Model/Attribute.php, app/Model/GalaxyCluster.php, app/Model/Workflow.php, and app/Plugin/Assets/models/behaviors/LogableBehavior.php.

MISP contains an authentication bypass vulnerability in its LDAP and LinOTP authentication components due to insufficient validation of user-supplied credentials.

The custom LdapAuthenticate and LinOTPAuthenticate components replace CakePHP's FormAuthenticate implementation but did not replicate its credential validation checks. As a result, empty or non-string values could reach the underlying authentication mechanisms.

In the LDAP authentication path, an attacker able to identify a valid directory user's email address could submit an empty password. The empty credential could be passed to ldapbind(), where an LDAP server accepting unauthenticated binds may return a successful result for a valid distinguished name combined with an empty password. MISP could consequently treat the attacker as the corresponding authenticated directory user without verification of the user's password.

The issue also affected the LinOTP authentication component. Invalid credential types were not rejected before being processed, and when mixed authentication was enabled, an empty password could be checked against a locally stored MISP password hash. LDAP-provisioned MISP accounts could additionally be created with an empty local password because account creation skipped normal validation, resulting in a hash corresponding to an empty password. This could permit authentication through the local fallback mechanism when such an account was no longer resolved through LDAP.

Successful exploitation could allow a remote unauthenticated attacker to impersonate an existing MISP user. If the targeted account has administrative or other privileged permissions, the attacker could gain corresponding access to sensitive threat-intelligence data, modify or delete information, alter configuration, or perform other privileged operations.

The patch resolves the vulnerability by requiring authentication identifiers and passwords to be valid strings, rejecting empty passwords where they are not explicitly permitted, and assigning a randomly generated local password to LDAP-provisioned accounts instead of storing a hash derived from an empty password.

The default setting of MISP 2.4.136 did not enable the requirements (aka requirepasswordconfirmation) to provide the previous password when changing a password.

In MISP before 2.5.28, app/View/Elements/Workflows/executionPath.ctp allows XSS in the workflow execution path.

A cross-site request forgery (CSRF) vulnerability existed in the cullEmptyEvents action of MISP. The endpoint performed a state-changing and irreversible operation while accepting HTTP GET requests.

Because bodyless GET requests are not subject to CakePHP's CSRF validation, an attacker could cause an authenticated MISP user with sufficient privileges to invoke the endpoint simply by causing their browser to load a crafted URL, for example through an embedded image or other automatically requested resource.

Successful exploitation triggers the deletion of published empty events. The deletion is particularly significant because the operation uses skipBlocklist, meaning the removed events do not leave blocklist entries that could prevent or track their subsequent synchronization. This can result in unintended and potentially irreversible deletion of MISP event records without explicit user interaction.

The vulnerability was addressed by restricting cullEmptyEvents to HTTP POST requests, ensuring that CakePHP's normal CSRF protections are applied to the operation.

In MISP before 2.4.129, setting a favourite homepage was not CSRF protected.

An issue was discovered in MISP 2.4.9x before 2.4.99. In app/Model/Event.php (the STIX 1 import code), an unescaped filename string is used to construct a shell command. This vulnerability can be abused by a malicious authenticated user to execute arbitrary commands by tweaking the original filename of the STIX import.

An issue was discovered in MISP before 2.4.156. app/Model/Server.php does not restrict generateServerSettings to the CLI. This could lead to SSRF.

RansomLook fails to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic checks whether an individual post is marked private but does not verify whether the group or market to which the post belongs is configured as private.

As a result, newly parsed victim information associated with a private group or market may be automatically published through enabled Rocket.Chat, Mastodon, Bluesky, and e-mail notification channels despite the entity being explicitly configured to prevent public disclosure.

A similar issue affects the public MISP feed. The feed previously determined privacy using groupinfo(), which only queries the group database. Consequently, victim information associated with private markets could be added to the public MISP feed because the corresponding market privacy flag was not evaluated.

An attacker or other unauthorized party able to access these public notification channels or the MISP feed may obtain victim information that was intended to remain private. Depending on the collected data, this may disclose victim names, ransomware activity, incident information, or other information associated with privately monitored groups and markets.

The fix introduces a common isprivateentity() check covering both groups and markets and prevents private entity posts from being distributed through external notification channels or the public MISP feed. Internal storage and dashboard alerting remain unaffected.

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.

A mass assignment vulnerability exists in MISP’s sharing group creation endpoint. When creating a new sharing group, the controller did not remove a user-supplied id field before saving the submitted data. In CakePHP, supplying a primary key in the save data can cause a create() followed by save() operation to update an existing record instead of creating a new one.

An authenticated user with permission to add sharing groups could therefore submit the identifier of an existing sharing group and modify that sharing group without passing the normal edit access-control checks. This may allow the attacker to take over or alter sharing groups they do not otherwise have access to, potentially affecting the confidentiality and integrity of information shared through those groups.

Affected component: app/Controller/SharingGroupsController.php, add() action

An incorrect authorization vulnerability in MISP allowed authenticated users to delete attributes from events despite lacking the required permmodify or permmodifyorg permissions.

The affected attribute deletion paths relied on organization membership checks performed by MispAttribute::deleteAttribute() but did not consistently enforce MISP's event modification authorization rules. Consequently, a user belonging to the organization associated with an event could potentially delete individual attributes or perform bulk attribute deletion even when their assigned role was not authorized to modify the event.

This created an inconsistency between attribute editing and deletion: editing an attribute correctly used MISP's ACL::canModifyEvent() authorization logic, whereas the affected deletion operations could bypass these permission checks.

An authenticated attacker with access to an affected MISP instance and membership in the organization owning an event could exploit this flaw to remove attributes from that event, potentially causing unauthorized modification or loss of threat intelligence data.

The patch introduces a common authorization check for all affected deletion paths. Before deletion, MISP now resolves the associated events and verifies that the current user is authorized to modify each event using the same authorization mechanism used by normal event and attribute modification operations.

app/Controller/EventsController.php in MISP before 2.5.24 has invalid logic in checking for uploaded file validity, related to tmpname.

An issue was discovered in MISP before 2.4.121. It did not consider the HTTP PUT method when trying to block a brute-force series of invalid requests.

A logic error in the MISP CRUD component delete handler allowed validation failures to be bypassed when requests used the HTTP DELETE method. Due to missing parentheses in the delete condition, the expression was evaluated as ($validationError === null && POST) || DELETE, meaning a DELETE request could proceed even when the delete validation callback had rejected the operation. An authenticated attacker with access to an affected delete endpoint could abuse this flaw to delete records that should have been protected by application-level validation or authorization checks.

An issue was discovered in MISP before 2.4.156. app/View/Users/terms.ctp allows Local File Inclusion via the custom terms file setting.

MISP contains an improper TLS certificate validation vulnerability in CurlClient. The CurlClient::$verifyPeer property was not explicitly initialized and therefore defaulted to null. When passed to cURL, this value effectively disabled TLS peer verification unless the calling code explicitly enabled it.

As a result, HTTPS connections made through affected CurlClient instances could accept certificates that were not issued by a trusted certificate authority. An attacker capable of intercepting or manipulating network traffic between a MISP instance and a remote HTTPS service could impersonate the remote endpoint and perform a man-in-the-middle attack.

Successful exploitation could allow an attacker to observe sensitive information transmitted by MISP, including authentication material or exchanged threat intelligence, and to modify responses returned to the MISP instance. The impact depends on the functionality using CurlClient and the data exchanged with the remote service.

The patch enables TLS peer verification by default while preserving explicit support for configured self-signed certificates. It also corrects the self-signed certificate handling in SyncTool so that peer verification is disabled only when no pinned CA certificate is configured.

An issue was discovered in MISP before 2.4.121. The Galaxy view contained an incorrectly sanitized search string in app/View/Galaxies/view.ctp.

An issue was discovered in MISP before 2.4.158. In UsersController.php, password confirmation can be bypassed via vectors involving an "Accept: application/json" header.