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.

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.

The LdapAuth and LinOTPAuth authentication plugins in MISP contain an authentication bypass vulnerability. Both LdapAuthenticate and LinOTPAuthenticate replace CakePHP's FormAuthenticate class but fail to replicate its checkFields() input validation guard. As a result, the email and password fields extracted from the login request are passed to downstream authentication logic without verifying that they are non-empty strings.

In the LDAP authenticator, an empty or null password is forwarded to ldapbind(). Per RFC 4513 section 5.1.2, a bind request with a valid DN and an empty password constitutes an unauthenticated bind, which many LDAP directory servers accept as successful. An attacker who knows any valid user email address in the directory can therefore authenticate as that user without possessing a password. Additionally, non-string values (null, false, arrays) are either coerced to empty strings by ldapbind(), raise TypeErrors, or are misinterpreted as find conditions in findUser(), all of which can lead to unintended authentication outcomes.

In the LinOTP authenticator, the same missing guard allows non-string credentials to be concatenated into the LinOTP verification request, and in the mixed-authentication branch an empty password is accepted against a stored hash of the empty string.

A secondary issue in the LDAP authenticator is that newly created user accounts (auto-provisioned on first LDAP login) were assigned an empty password. Because the save path skips validation, the empty string is hashed and stored. If the user later ceases to be found in LDAP and the mixed-authentication fallback is used, the stored hash of the empty string verifies against an empty password, again permitting unauthenticated access.

The vulnerability requires that the affected plugin (LdapAuth or LinOTPAuth) is enabled on the MISP instance and that the attacker knows at least one valid email address registered in the directory or MISP user store. No prior authentication is required. Successful exploitation grants the attacker the full privileges of the impersonated user, which may include administrative access to threat intelligence data.

Version affected: ≤2.5.45

MISP contains a vulnerability in its two-factor authentication (TOTP) verification process that permits a valid one-time code to be accepted more than once within its time-based validity window.

The issue exists in the user login flow where a TOTP code is verified as a second authentication factor. Because the system did not record whether a given TOTP period had already been consumed, the same code remained valid for its entire time window (typically 30 seconds). An attacker who captures a legitimate code during a user's login could replay it to authenticate a second session as that user.

Preconditions:

- The target user has TOTP-based two-factor authentication enabled.

- The attacker is in a position to observe or intercept the TOTP code during a legitimate login (e.g., network-level interception, shoulder surfing, or a compromised client).

- The replay must occur within the TOTP validity period.

Security impact:

- Unauthorized account access by replaying a captured one-time code.

- Potential compromise of threat-intelligence data and administrative functions accessible to the targeted user.

Affected versions: <v2.5.48.

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.

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.

MISP contains a vulnerability in its background job dispatch mechanism that allows remote code execution as the web user. Background job arguments are passed directly as the argv of the CakePHP console process. CakePHP's ShellDispatcher::parsePaths() scans the entire argv for path switches (-app, --app, -working, --working, -root, --root, -webroot, --webroot) and uses the following element as the application root. The events/contact endpoint passes user-controlled fields (message and person) into job arguments without validation. An attacker who can submit the contact form can set the person field to a reserved switch and the message field to a phar:// URI pointing to a malicious archive. The CakePHP bootstrap then includes Config/core.php from within that archive, executing attacker-controlled PHP code with the privileges of the web user.

The vulnerability requires the ability to submit the events/contact form (or any other endpoint that forwards user input into background job arguments). No special timing or race condition is required; the attack is deterministic once the crafted parameters are accepted. The impact is full remote code execution in the context of the MISP web server process, allowing data exfiltration, persistence, and lateral movement within the host.

MISP has a security issue that can let a user gain more access than their API key is supposed to allow.

A read-only API key should only let someone view information. However, after logging in with such a key, a specific MISP function could accidentally restore the user’s normal account permissions. This means someone with a read-only API key could potentially gain write, delete, or even administrator access if their underlying account has those permissions.

Exploiting the issue requires a valid read-only API key and a single request to the affected function.

The main impact is that MISP’s API key restrictions can be bypassed, allowing actions that the API key was specifically meant to prevent.

Version affected: <2.5.47

MISP contains a mass assignment vulnerability in the event delegation feature. When a user with delegation permission submits a delegation request, the application authorized the user against the event identified in the URL but then persisted the entire submitted record, including caller-supplied fields such as the primary key and eventid.

An authenticated attacker could inject a primary key or eventid into the delegation payload to retarget an existing delegation record to any event on the instance. Because a delegation row grants the requesting organisation read access to the event it references, this effectively granted read access to arbitrary events belonging to other organisations. If the target organisation subsequently accepted the delegation, ownership of the event was transferred and the original record was deleted.

Preconditions:

- An authenticated user with the delegation permission (permdelegate)

- The MISP.delegation server setting must be enabled

Impact:

- Confidentiality: read access to any event on the instance

- Integrity: overwriting existing delegation records and transferring event ownership

Affected versions: MISP < 2.5.48

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 contains a privilege escalation vulnerability in the tag collection creation and editing functionality. The affected actions accepted the full HTTP request payload and passed it to a bulk-association save operation, which writes not only the intended tag collection record but also any associated model data present in the payload.

A user holding the tag editor permission could craft a request that includes additional model data (such as User or Organisation records) alongside the tag collection fields. Because the save operation processed all associated models indiscriminately, the injected sibling records were written to the database, enabling the attacker to modify or create privileged accounts and escalate to site administrator.

Preconditions:

- An authenticated account with the tag editor permission (permtageditor)

- Network access to the MISP instance

Impact:

- Unauthorized creation or modification of User and Organisation records

- Privilege escalation from tag editor to site administrator

Affected versions: < 2.5.48

MISP contains a stored cross-site scripting (XSS) vulnerability in the Overmind theme's statistics views. The event General card and the server/feed preview card constructed donut chart legend labels by directly concatenating object name or category keys into an innerHTML string without HTML-encoding. Because MISP object names are user-controllable by any authenticated user with sufficient permissions to create or modify such objects, an attacker could craft a name containing malicious markup. When any other user viewed the affected Overmind dashboard, the injected markup would be interpreted as live HTML/JavaScript in the victim's browser, executing in the context of the MISP application origin. This could allow session hijacking, data exfiltration, or arbitrary actions performed on behalf of the victim.

The vulnerability requires the attacker to have low-level authenticated access to create or rename an object whose name is rendered in the legend, and the victim to view the Overmind event or server preview page. No special browser conditions or race conditions are required.

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.

MISP contains an insecure direct object reference vulnerability in the processModuleResultsData method of the Event model. When processing module results, the code iterates over EventReport entries supplied in the resolved data and saves each one. Unlike the adjacent attribute and object processing loops, the report loop did not unset the client-supplied 'id' field before calling save(). Because the MISP EventReport model's create() method does not strip the id field, an authenticated user with permission to submit module results could include an 'id' value referencing an existing report belonging to a different event. Upon save(), the ORM would update that existing row rather than insert a new one, allowing the attacker to

- read the content of another event's report by reparenting it into their own event  - overwrite the report's fields with attacker-controlled data  - change the report's eventid to redirect ownership.

This constitutes an authorization bypass through a user-controlled key, enabling cross-event data disclosure and integrity compromise. The vulnerability requires an authenticated session with the ability to invoke module result processing on an event.

Version affected: <2.5.47

MISP has a file-handling vulnerability that could let certain authenticated users make the server read files or access internal network services.

When importing an XML file, MISP did not properly verify that the uploaded content was actually XML. Because of this, a user with permission to modify data could upload a file containing a local file path or a web address instead.

If a local file path was supplied, MISP could read that file from the server. If a URL was supplied, MISP could make a request to that address, including systems that may only be reachable from inside the organization’s network.

The vulnerability could therefore expose sensitive local files and allow unauthorized requests to internal services.

Exploitation required a valid MISP account with modify permissions, but no additional user interaction was needed.

Version affected: <2.5.47

MISP contains an improper input validation vulnerability in its ORM save path. When a user submits data through various endpoints (attribute add/edit, event edit, free-text import, sighting capture, shadow attribute proposal, event report creation, object reference add, user admin edit), the application sanitizes the flat record by stripping the primary key and pinning the eventid or objectid to the caller's context. However, the underlying ORM's set() method gives priority to a nested key whose name matches the model alias and discards the outer scalar fields.

An authenticated user with basic write permissions can exploit this by embedding a nested block under the model alias key inside their request. The sanitization logic (id removal, eventid pinning) is applied to the outer record, but the ORM binds to the inner record instead, which carries an attacker-chosen id and eventid. This allows the attacker to overwrite, re-parent, or soft-delete rows belonging to other organizations or events they have no read access to.

Impact:

- Cross-tenant data integrity compromise (attribute values rewritten, objects re-parented to attacker events, rows soft-deleted)

- Affects multiple entity types: Attribute, Object, EventReport, Sighting, AttributeTag, ShadowAttribute

- Requires only a low-privilege authenticated account with permadd

Affected versions: <2.5.48

MISP contains a stored cross-site script (XSS) vulnerability in the event graph preview feature.

The event graph preview image field was accepted and stored without server-side validation. On the client side, the stored value was rendered into an HTML img element's src attribute via string concatenation, allowing a crafted value to break out of the attribute context and inject arbitrary script.

Preconditions:

- An authenticated MISP user with the ability to create or modify an event graph entry.

- A second user (the victim) who views the event graph and triggers the preview popover.

Impact:

- Execution of arbitrary JavaScript in the victim's browser within the MISP application context.

- Potential theft of session tokens, cookies, or sensitive data accessible to the victim's browser.

- Potential for performing actions on behalf of the victim within the MISP application.

Affected: MISP versions prior to the fix (commit applied after v2.5.48).