MISP ships with PHP's phar stream wrapper registered in both its web entry point and its console entry point.

The phar stream wrapper causes PHP to treat a phar archive as a directory, which has two security consequences:

- any filesystem operation on a caller-influenced path that resolves to a phar archive triggers an implicit unserialize() call, creating a deserialization sink;  - a relocated application root can reach executable code inside an uploaded phar file, enabling arbitrary code execution as the web user.

No component of MISP, the vendored CakePHP framework, or any runtime-loaded library reads or constructs phar archives. The wrapper therefore serves no legitimate purpose in the MISP runtime and exists solely as an available primitive for an attacker who can influence a filesystem path argument.

A typo in the MISP ACLComponent access control configuration caused the ACL rule for the previewEventAttributes action to reference the permission string 'themingenabled' (with a trailing asterisk) instead of the correct 'themingenabled'. In the MISP ACL system, the array values define which role or permission grants access to a given controller action. The adjacent entry previewEventObjects correctly uses ['themingenabled'], confirming the intended restriction. The malformed key 'themingenabled' does not match any valid permission identifier, causing the access control check for previewEventAttributes to malfunction. Depending on the ACL evaluation logic, this could result in either unauthorized users gaining access to the previewEventAttributes endpoint (authorization bypass) or legitimate users being denied access (availability impact).

The previewEventAttributes endpoint exposes event attribute data within MISP so an authorization bypass could expose sensitive indicator and attribute data to users who should not have access.

In MISP's UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotpcounter. When the TOTP branch subsequently accessed $unauthuser['User']['disabled'], the key was absent from the result set, producing a PHP 'Undefined array key' warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.

The commit message explicitly states this was 'harmless in practice' because the subsequent identify() call re-validates the user and would still reject a disabled account.

The practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs.

In MISP, the OrganisationsController::uploadLogo method processed a caller-supplied tmpname value with filesystem probes (fileexists, MIME type detection, EXIF reading) before verifying that the value corresponded to a genuine PHP file upload via isuploadedfile. An authenticated site-admin user could supply an arbitrary server file path as the tmpname parameter. The application would then probe that path and return distinct validation error messages depending on whether the file existed and what its image type was, effectively creating a file-existence and image-type oracle against the server filesystem.

The vulnerability requires site-admin privileges and does not allow arbitrary file read, code execution, or modification; the impact is limited to disclosure of whether a given path exists on the server and, for image files, their type.

In MISP, the statisticsOrgs method in UsersController.php used the organization name directly as a file-system path component when checking for the existence of an organization logo image. The original code called fileexists() with a path constructed as APP . 'webroot' . DS . 'img' . DS . 'orgs' . DS . $k . '.png', where $k is the organization name. Because the referenced directory (app/webroot/img/orgs) no longer exists in current MISP deployments (org logos were relocated to files/img/orgs), the check was functionally dead and never triggered. However, the underlying pattern—concatenating an attacker-influenced organization name into a file path without sanitization—constitutes a path traversal weakness. An organization name containing directory traversal sequences (e.g., '../../../../etc/passwd') would, if the target directory existed, allow an authenticated user with the ability to create or rename an organization to probe for the existence of arbitrary files on the server.

The findOrgImage method in MISP's OrgImgHelper constructs a filesystem path by concatenating a user-supplied organization identifier with a fixed image directory and a file extension, then calls fileexists() on the resulting path. The organization name field is attacker-controllable through event import, which sets Org.name. Because no validation was performed on the field value before path construction, an organization name containing directory traversal sequences (e.g., ../../etc/passwd) would cause the path to resolve outside the intended org-image directory.

This yields two security impacts:

- an arbitrary file existence oracle, since fileexists() returns a boolean for any path the process can access.  - an arbitrary file read limited to files with .png or .svg extensions, because the resolved filename is returned and subsequently rendered or served to the requesting user.

The vulnerability requires an authenticated user with the ability to create or import events that set the organization name.

MISP contains an authorization flaw in the Organisation model's captureOrg method. When the $force parameter is set to true, the method unconditionally overwrites organization metadata fields without verifying that the invoking user holds sufficient privileges. A user with a sharing group (SG) editor role can trigger this code path, allowing them to modify organization metadata that should be restricted to site administrators or users with sync permissions.

According to the commit message, this could lead to blueprint-based sharing group manipulation, meaning an attacker with SG editor access could alter organizational attributes in ways that influence how sharing groups and blueprints behave across the MISP instance.

The vulnerability requires an authenticated user with at least SG editor privileges and network access to the MISP web interface. The impact is primarily on the integrity of organization records and, potentially, on the integrity of sharing group configurations derived from those records.

In MISP, the EventReport::uploadPicture method in processed a caller-supplied tmpname field by invoking fileexists(), mimecontenttype(), and exifimagetype() on the supplied path before verifying that the value was a genuine PHP upload via isuploadedfile(). An authenticated user holding the permadd permission could supply an arbitrary filesystem path as the tmpname value. The application would then probe that path and return distinct validation error messages depending on whether the file existed, its MIME type, or its image format. By observing the differing error responses, an attacker could enumerate the existence of files at arbitrary paths on the MISP server and determine their type.

This constitutes an information disclosure vulnerability: the server's filesystem layout and file types are leaked to any user with the permadd role without requiring administrative access.

The vulnerability does not allow reading file contents, writing files, or executing code, but it can aid further attacks by revealing sensitive file locations (e.g., configuration files, private keys, or other artifacts) present on the host.

MISP contains an access control flaw in the EventReports functionality. The replaceSuggestionInReport action, which allows modification of suggestion content within an event report, was incorrectly mapped to the wildcard permission ('') in the ACLComponent, making it accessible to any authenticated user regardless of their assigned permissions. All analogous report-modification actions correctly required the permadd permission, while read-only actions such as downloadAsPDF appropriately used the wildcard.

An authenticated user without the permadd permission could invoke the replaceSuggestionInReport endpoint to alter report suggestion data, violating the intended authorization model.

This constitutes an improper authorization weakness that could lead to unauthorized modification of event report content, potentially corrupting shared threat intelligence data or injecting misleading information into reports relied upon by other analysts and automated consumers.

In MISP, the Overmind event view enriches an event with its most recent attached report for preview purposes. The enrichment logic fetched the report using only the event ID as the lookup condition, without applying the report's own distribution/ACL constraints. Because MISP reports carry an independent distribution setting that can be more restrictive than the parent event's distribution, an authenticated user who had read access to the event could retrieve and view a report whose distribution explicitly excluded that user. Additionally, the query did not filter out soft-deleted reports, allowing retrieval of reports that had been administratively removed.

The result is an unauthorized disclosure of threat-intelligence report content to users who should not have access under the report's own access-control policy.

The vulnerability requires an authenticated MISP user with at least read access to the affected event.

MISP contains a stored cross-site scripting (XSS) vulnerability in the admin email composition screen. The MISP.org organization name setting was interpolated directly into a JavaScript string literal using an unescaped PHP echo: var org = "<?php echo $org;?>";. Because the value was placed inside a double-quoted JavaScript string without any encoding, an organization name containing a double-quote character (or a backslash) could terminate the string literal and inject arbitrary JavaScript into the page. The injected script would execute in the context of any authenticated user who subsequently loads the admin email page, potentially allowing session hijacking, data exfiltration, or privileged actions performed on behalf of the victim.

Exploitation requires the ability to set or modify the MISP.org organization name and a second authenticated user visiting the affected admin email view.

The vulnerability is a classic instance of insufficient output encoding in a JavaScript context.

MISP's RequestHandlerComponent automatically decodes XML request bodies on all write requests. The underlying Xml::build() library contains a logic error in its readFile guard condition (readFile && http || https), where PHP operator precedence causes the https branch to bypass the readFile check entirely. As a result, a request body containing a bare HTTPS URL is treated as a locator and fetched by the server. Because the cspReport endpoint accepts XML content type and is unauthenticated by design, an unauthenticated remote attacker can send a POST request with a crafted XML body to cause the MISP server to issue an outbound HTTPS request to an arbitrary target reachable from the server.

The attacker does not receive the response body, but can use the vulnerability to probe internal services, trigger actions on internal HTTPS endpoints, or perform timing-based reconnaissance of the server's network environment.

The vulnerability affects any MISP deployment where the cspReport endpoint is reachable and the server has network access to internal or external HTTPS services.

In MISP, the queryEnrichment method in EventsController.php accepted a module name parameter and iterated over the list of enabled modules to find a match. If the specified module was not present in the enabled modules list, the code silently continued processing using default parameters (format set to 'simplified' and no module-specific configuration applied) rather than rejecting the request. This allowed an authenticated user to trigger enrichment or analysis processing through a module that was not explicitly enabled or available on the instance, bypassing the intended module availability controls. The lack of validation meant that module names outside the enabled set were not rejected, potentially exposing functionality or data processing paths that the administrator had not authorized for use.

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.

The MISP installer scripts (for Debian 12, Debian 13, Ubuntu 24.04, and RHEL 9.4) create a log file at /var/log/mispinstall.log and a named pipe (FIFO) at /var/log/mispinstall.log.pipe to capture all installer output. The log captures highly sensitive data including the generated admin password, database passwords, GPG passphrase, and supervisor password. However, the log file was created by the tee command under the system default umask, resulting in world-readable permissions (typically 0644). Similarly, the FIFO was created with mkfifo without an explicit mode, also inheriting the default umask and remaining world-readable during the window before it was unlinked.

Any local unprivileged user on the system could read the log file or the FIFO to obtain these credentials.

Additionally, the log file was not removed before creation, meaning a pre-existing symlink in /var/log could have been used to redirect the write to an arbitrary location.

Version affected: <2.5.47

MISP contains a reflected cross-site scripting (XSS) vulnerability in the attribute histogram view. The $selectedTypes variable, which is derived from the URL path segment , was interpolated directly into a JavaScript array literal inside an onClick HTML attribute without any encoding or escaping. An attacker who can cause an authenticated MISP user to visit a crafted URL containing a malicious type value can execute arbitrary JavaScript in the victim's browser within the MISP application origin.

Successful exploitation allows the attacker to read session cookies, perform actions on behalf of the victim, or exfiltrate sensitive data accessible from the MISP interface.

The vulnerability requires the victim to be authenticated and to actively navigate to the attacker-supplied URL.

MISP contains a reflected cross-site scripting (XSS) vulnerability in the AnalystDataController::viewForObject action. The method accepted a parent object type parameter from the URL without validation and passed it to the Overmind-themed AnalystData thread view element, where it was interpolated into two translated strings and rendered into the HTML response without output encoding. An authenticated attacker who can induce a victim to navigate to a crafted URL can inject arbitrary JavaScript that executes in the victim's browser within the MISP application context. This may allow the attacker to read session data, manipulate the page, or perform actions on behalf of the victim.

The vulnerability requires the victim to be authenticated to MISP and to actively visit the attacker-supplied URL. The affected component is the AnalystData controller and the Overmind theme's AnalystData thread element.

Version affected: <2.5.47

MISP's WorkflowsController exposed the moduleStatelessExecution action in the Security component's unlockedActions list. In CakePHP, listing an action in unlockedActions disables both the CSRF token check and the field hash validation for that action. Because moduleStatelessExecution executes a workflow module's exec() method with caller-supplied input and parameters, the absence of CSRF protection allowed an attacker to craft a cross-site form post (or equivalent cross-origin request) that, when submitted by an authenticated site administrator, would cause the administrator's browser to invoke the action on the MISP instance.

The attacker could select any workflow module to execute, including action modules that write blocklist and warninglist entries, and supply arbitrary input and parameters of their choosing. This constitutes a cross-site request forgery (CSRF) vulnerability with high integrity impact on the MISP instance's security-related data.

The vulnerability was identified during an internal security review and was not externally reported. The fix is included in MISP v2.5.47.

MISP has a security issue that could let an attacker change threat-intelligence data through a logged-in user’s browser without that user knowingly approving the change.

The affected function did not properly enforce MISP’s usual protection against forged requests. Because of this, an attacker could create a malicious webpage that silently sends a request to MISP when visited by an authenticated user.

If successful, the attacker could change details of an attribute, such as its value, type, category, comment, distribution settings, or related timestamps.

The attack requires the victim to already be logged in to MISP and to visit an attacker-controlled page.

The main impact is unauthorized modification of threat-intelligence data, which could lead to incorrect indicators, wrong classifications, or altered sharing settings and reduce confidence in the accuracy of the information stored in MISP.

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

When a regular user adds a reference between objects or attributes, MISP checks whether the user can access the overall event, but it does not always check whether the individual pieces of data are also allowed for that user.

Because of this, someone who can view an event could potentially access attributes or objects inside that event that were meant to be restricted to a specific sharing group or distribution level.

The vulnerability affects authenticated users who are not site administrators and who already have access to an event containing more restricted data.

The main impact is that users may be able to view sensitive attribute values, object details, or related object data that they should not normally be allowed to see.

When a user creates or edits a report inside an event, MISP can identify an existing report using its UUID without properly checking whether that report actually belongs to the same event.

As a result, a user who has editing rights on one event could potentially move a report from another event into their own event, as long as they know or can guess the report’s UUID. Once moved, they could view and change information that they were not originally allowed to access.

The vulnerability requires the attacker to have editor access to at least one event and to know or discover a valid report UUID.

The main impact is that private event reports could be exposed or modified across event boundaries, bypassing MISP’s normal access restrictions.

Version affected: <2.5.47

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 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 contains a DOM-based cross-site scripting (XSS) vulnerability in the contextual menu JavaScript component. The ContextualMenu class populates HTML <option> elements by assigning user-controllable values to the innerHTML property. Because innerHTML parses and renders HTML markup, any untrusted string supplied as the option text (value.text or value) is interpreted as live DOM content rather than plain text. An attacker who can influence the data rendered in the contextual menu can inject arbitrary HTML or JavaScript that executes in the victim's browser within the MISP application origin. This may allow session hijacking, data exfiltration, or unauthorized actions performed on behalf of the authenticated user.

Version affected: <2.5.47

MISP's galaxy matrix statistics view (app/View/Users/statisticsgalaxymatrix.ctp) renders the galaxy name directly into HTML output via sprintf() without any HTML encoding. An authenticated user holding the permgalaxyeditor permission can create or modify a galaxy whose name contains arbitrary HTML or JavaScript markup. Because the value is interpolated verbatim into the page, any user who subsequently opens the galaxy matrix statistics page will have the embedded script executed in their browser context. This enables session hijacking, credential theft, data exfiltration, or the performance of arbitrary actions on behalf of the victim within the MISP application.

Version affected: <2.5.47

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.

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.

Affected versions of MISP do not consistently apply the existing authentication-failure logging throttle.

Two API authentication failure branches wrote directly to the Log model:

- API requests with no authentication key;  - requests supplying an API key with an incorrect length

Unlike other authentication failures, these paths bypassed shouldLog(), so every request could create another durable authfail entry.

Version affected: ≤2.5.45

Affected versions of MISP expose several state-changing controller actions without restricting them to POST.

The affected actions are:

- EventReportsController::purgeUnusedPictures()

- NoticelistsController::enableNoticelist()

- ServersController::removeOrphanedCorrelations()

- WorkflowsController::rebuildRedis()

The patch adds allowMethod(['post']) to each action, preventing them from being triggered through ordinary GET requests.

For purgeUnusedPictures(), the corresponding UI previously used $.get(). The fix converts that request to POST and supplies X-CSRF-Token, while the controller enables header-only CSRF validation for that AJAX action.

Because GET requests can be induced cross-origin through links, images, redirects, or navigation, accepting GET for these state-changing operations can let an attacker trigger them using the authenticated victim's session.

Version affected: ≤2.5.45