MISP installation scripts generated an Apache HTTP virtual-host configuration containing an incorrectly formatted HTTP-to-HTTPS redirect: Redirect permanent / https://misp.example Apache’s Redirect directive appends any portion of the requested path that follows the matched prefix to the configured destination URL. Because the destination did not end with /, attacker-controlled path content was appended directly to the hostname rather than to its URL path. For example, a request resembling: http://misp.example/@attacker.example/ could result in a redirect resembling: https://misp.example@attacker.example/ Under standard URL parsing, misp.example is interpreted as user information and attacker.example as the destination host. An unauthenticated remote attacker could therefore construct a URL hosted under the legitimate MISP domain that redirects users to an attacker-controlled website. The vulnerability could be used for phishing, credential collection, or potentially disclosing sensitive query-string information preserved during the redirect. Exploitation requires a user to follow the crafted HTTP URL. The fix adds the missing trailing slash to the redirect destination, ensuring that appended request data remains part of the path on the configured MISP host. Existing installationsExisting MISP installations should review their Apache HTTP virtual-host configuration and ensure that the HTTPS redirect destination ends with a trailing slash: Redirect permanent / https://misp.example/ After updating the configuration, validate it with apachectl configtest and reload or restart Apache for the change to take effect

Pivotick contains a DOM-based cross-site scripting vulnerability in its generic UI element resolution and icon-rendering utilities. The tryResolveHTMLElement function treated any resolved string as HTML markup by assigning it to a <template> element through innerHTML. Strings derived from untrusted graph properties or custom rendering callbacks could therefore introduce arbitrary HTML or SVG elements into the live document. The vulnerable function was used by multiple UI components, including headers, property panels, extra panels, and tooltips. Additionally, createIcon inserted caller-supplied svgIcon markup into a template without sanitization. An application integrating Pivotick and deriving icon markup from untrusted data could therefore expose a second script-execution path. An unauthenticated attacker able to provide a crafted graph, property value, rendering result, or SVG icon could execute JavaScript in another user's browser when the affected content is displayed or interacted with. Successful exploitation could allow the attacker to access information available to the victim, manipulate graph data or application state, and perform actions with the victim's privileges. The patch changes string rendering to use textContent, requiring callers to explicitly return an Element when HTML rendering is intended. It also sanitizes SVG icon markup before inserting it into the DOM.

Pivotick did not validate the URL scheme of node imagePath values derived from graph data before assigning them to SVG image resources. An attacker able to supply crafted graph data could set an image path to a malicious URI. When a victim rendered the affected graph, the browser could resolve the attacker-controlled URI and initiate an unintended request or invoke scheme-specific handling in the victim’s context. Depending on the URI, browser behaviour, and installed protocol handlers, exploitation could disclose limited client or network metadata, facilitate rendering-based tracking, or attempt to access local or internal resources. Exploitation requires a victim to load or render graph data containing the malicious imagePath. The patch normalizes ASCII whitespace and control characters in URI schemes and restricts image paths to relative URLs or the http, https, data, and blob schemes.

Pivotick used plain JavaScript objects as lookup tables indexed by caller-controlled graph node identifiers in its tree-layout and cycle-detection components. Node identifiers matching properties inherited from Object.prototype, such as constructor, toString, or __proto__, were not handled as ordinary identifiers. These values could be interpreted as existing inherited properties, resolve to values of an unexpected type, or—in the case of __proto__ assignments—modify the prototype of an internal lookup object. An attacker who can supply graph data containing crafted node identifiers could consequently cause nodes or edges to be silently omitted, produce incorrect hierarchy levels, bypass or corrupt cycle-detection results, or trigger an exception that interrupts graph processing and rendering. This affects the integrity of graph visualisations and analytics and may cause a client-side denial-of-service condition. The affected code also failed to safely handle edges whose source node was absent from the supplied node set. Furthermore, calculating the maximum tree depth by spreading all level values into Math.max() could exceed the JavaScript function-argument limit when processing a sufficiently large graph, resulting in an exception and denial of service. The patch replaces identifier-keyed plain objects with Map instances, ignores invalid edges during tree construction, and calculates the maximum depth iteratively.

Pivotick’s Markdown node-reference renderer failed to HTML-escape the attacker-controlled nodeName value before interpolating it into both the data-node-name attribute and the body of a generated <span> element. Because the node-reference tokenizer rejected only square brackets, a crafted node name could still contain quotation marks, angle brackets, or other HTML metacharacters. An attacker could therefore terminate the quoted attribute or inject additional HTML elements and event-handler attributes. When malicious node-reference content is rendered by a consumer that does not apply DOMPurify or equivalent sanitization, arbitrary JavaScript may execute in the victim’s browser in the security context of the application. Successful exploitation requires a victim to open or render a crafted graph or note and could allow the attacker to access same-origin information, modify displayed content, or perform actions using the victim’s session. The patch resolves the issue by applying context-appropriate HTML escaping to node names before inserting them into either HTML text or quoted attribute values. The shared escaping function now encodes ampersands, angle brackets, and both types of quotation marks.

Pivotick contains an uncontrolled-recursion vulnerability when processing caller-supplied graph and node data. The affected graph algorithms recursively traversed graph edges, while the JSON viewer recursively processed each level of a node’s data structure. A specially crafted graph containing an excessively long path, deeply nested properties, or circular object references could therefore exhaust the JavaScript call stack when Pivotick calculates a layout or displays a node in the inspection modal. Successful exploitation may cause an uncaught exception, freeze the affected page, or crash the browser tab, resulting in a client-side denial of service. No confidentiality or integrity impact has been identified. The patch replaces the recursive graph traversals with iterative stack-based implementations and limits the reachability calculation to 1,000,000 edge traversals. It also limits JSON rendering to 64 levels and detects circular references before descending further into an object.

Pivotick contains a cross-site scripting vulnerability in the inspect and edit node modals. Node labels and descriptions originating from graph data were interpolated directly into HTML used to construct the modal headers. An attacker able to supply or modify graph data could insert a malicious HTML or JavaScript payload into a node’s label or description. The payload would be parsed and executed in the application’s origin when a user opened the affected node’s inspect or edit modal. Successful exploitation could allow the attacker to access information available to the victim, modify application data, or perform actions using the victim’s active session. The vulnerability has been addressed by creating the modal elements without embedding graph data in HTML and assigning node labels and descriptions through textContent.

Pivotick fails to sanitize attacker-controlled SVG markup supplied through the per-node style.svgIcon property before inserting it into the document. When rendering a graph node, the vulnerable code assigns the SVG icon markup directly to the innerHTML property of a live SVG element. An attacker able to influence graph data can provide crafted markup containing executable event handlers, such as an <image> element with an onerror attribute. When a victim loads or renders the malicious graph, the payload may execute arbitrary JavaScript in the security context of the application embedding Pivotick. Successful exploitation could allow the attacker to access application data available to the victim, modify displayed content, or perform actions using the victim’s authenticated session. Exploitation requires an application using Pivotick to render graph data that is controlled or modified by an attacker.

Lookyloo did not enforce limits on the decompressed size of uploaded capture archives and compressed HAR files. An attacker could submit a specially crafted ZIP, gzip, or zlib-compressed capture containing data that expands to a very large size during processing. Because the application decompressed this content directly in memory without first limiting the output size, processing the malicious capture could exhaust available memory, terminate a web or worker process, or make the Lookyloo instance unavailable. The vulnerability affects both full Lookyloo capture archive imports and API submissions containing gzip-compressed HAR data. Repeated exploitation could cause a persistent denial-of-service condition until the affected processes or instance are restarted. The patch introduces: * A 1 GB cumulative uncompressed-size limit for imported capture archives. * Size-limited gzip and zlib decompression for compressed HAR files. * Explicit detection and handling of suspected zip bombs. * An HTTP 400 response when an oversized compressed HAR file is submitted through the API.

Pivotick contains a cross-site scripting vulnerability in the sidebar property-list component. Values associated with link-like properties, such as url, uri, href, link, website, or homepage, were rendered as hyperlinks without validating their URL scheme. An attacker able to supply or influence node or edge property data could provide a malicious value using the javascript: scheme, including variants obfuscated with whitespace or control characters. If a user clicked the generated property link, attacker-controlled JavaScript could execute in the context of the Pivotick application. Successful exploitation could allow the attacker to access information available to the victim’s browser session or perform actions with the victim’s privileges. The vulnerability was addressed by normalizing property values and preventing URLs with non-allowlisted schemes from being rendered as clickable links.

A stored cross-site scripting vulnerability existed in the capture tree visualization page. The application embedded the serialized capture tree directly into an inline JavaScript block using the Jinja safe filter. Because the tree data can contain values derived from captured and potentially attacker-controlled web content, a specially crafted value could prematurely terminate the surrounding <script> element and inject arbitrary HTML or JavaScript. The malicious code would execute in the browser of a user viewing the affected capture tree. Successful exploitation could allow an attacker to perform actions using the victim’s authenticated session, access information available to the victim, or modify application data within the permissions of the affected user. The patch removes the JSON data from the HTML document and retrieves it through a dedicated API endpoint. The client then processes the response using response.json(), preventing capture data from being interpreted as executable content within the original page’s HTML or JavaScript context.

PlaywrightCapture stored capture-specific configuration and runtime data as mutable class-level variables rather than instance-level variables. Consequently, multiple Capture objects running within the same Python process could share state, including HTTP headers, cookies, browser storage, HTTP credentials, proxy configuration, user-agent settings, geolocation information, and captured request data. In a multi-user or concurrent deployment, information supplied during one capture could therefore persist and be reused by a subsequent or parallel capture. This could result in the disclosure of authentication cookies, credentials, browser storage, or captured request data belonging to another user. It could also cause requests to be performed with another capture's authentication context, headers, or proxy configuration, potentially enabling unauthorized access to remote resources or interference with other capture operations. The vulnerability is resolved by initializing all capture-specific settings and request data as instance variables in the Capture constructor, ensuring that state is isolated between capture operations.

A Server-Side Request Forgery (SSRF) protection bypass existed in the html_to_markdown expansion module of misp-modules. The module attempts to prevent requests to loopback, private, link-local, and other restricted IP address ranges. However, IP addresses were compared against the blocked ranges without first normalising IPv4-mapped IPv6 addresses. An authenticated attacker able to invoke the module could supply an IPv4-mapped IPv6 address, such as: http://[::ffff:127.0.0.1]/ http://[::ffff:169.254.169.254]/ Alternatively, the attacker could use a hostname that resolves to an IPv4-mapped IPv6 address. These addresses were treated as IPv6 addresses and therefore did not match the corresponding blocked IPv4 ranges. Successful exploitation could cause the misp-modules server to connect to services available through its loopback interface, internal network, or link-local network. This could expose internal web services, administrative interfaces, or cloud instance metadata, with retrieved content potentially returned to the attacker as converted Markdown. The vulnerability has been addressed by normalising IPv4-mapped IPv6 addresses to their underlying IPv4 representation before applying the blocked-range checks. URLs without a valid hostname are now also rejected.

An improper authorization check in MISP’s attribute creation endpoint allowed an authenticated user with permission to add attributes to submit a sharing_group_id without triggering the corresponding sharing group authorization check, as long as the attribute distribution value was not explicitly set to 4 — “sharing group”. As a result, a user could reference or associate an attribute with a sharing group they were not authorized to use. This could lead to an access-control bypass affecting the integrity of attribute sharing metadata and potentially expose or misuse restricted sharing group relationships. The patch changes the authorization logic so that the sharing group permission check is performed whenever a non-empty sharing_group_id is provided, regardless of the selected distribution value.

MISP’s importModule() path used getEnabledModule() to resolve a single import module by name, but this lookup did not enforce the per-organisation module restriction checked by getEnabledModules(). As a result, an authenticated user from an organisation that was not allowed to use a module restricted via Plugin.Import_<module>_restrict could still invoke that import module directly if they knew its name. This could allow unauthorised access to restricted import-module functionality and, depending on the module and the user’s event permissions, may allow unauthorised import or modification of event data through a module that should have been unavailable to the user’s organisation.

An authorization bypass in MISP’s EventsController::importModule() allowed authenticated users or read-only API keys with event view access to persist data to events they were not allowed to modify. When an import module returned results in the misp_standard format, the write path did not verify event modification rights before saving the module output. This could allow a view-only user to inject or alter event data, impacting the integrity of MISP event content. The issue was fixed by enforcing the same modification-rights check used by related module result handling paths before processing misp_standard imports.

AIL Framework contains a path traversal vulnerability in its PDF object handling. Prior to commit 14c618fce4d1df02358717c48ea903706abecdf2, the PDF.get_filepath() function constructed a file path by joining the configured PDF storage directory with a path derived from a PDF object identifier, without verifying that the resolved path remained within the intended PDF_FOLDER directory. An authenticated attacker able to invoke PDF object operations with a crafted identifier could use relative traversal sequences or absolute path components to cause AIL Framework to open files located outside the PDF storage directory. This could allow disclosure of files readable by the AIL process, including application configuration, credentials, or other sensitive local data. This vulnerability is potential due to additional errors before being able to be executed. The fix canonicalises the resulting path with os.path.realpath() and rejects paths whose common directory is outside the configured PDF directory.

An unauthenticated improper input validation vulnerability in the POST /fetch_cve_data endpoint in cve-search. A remote attacker can manipulate request parameters controlling the MongoDB collection, projected fields, and regular-expression filters to read arbitrary application MongoDB collections. This can expose administrative usernames and password hashes from the mgmt_users collection, enabling offline password cracking and potential administrative account compromise.

AIL did not restrict repeated failed attempts to verify a two-factor authentication (OTP) code. An attacker who had reached the 2FA verification step, such as after successfully completing the password-authentication stage, could submit an unlimited number of OTP guesses. This could enable brute-force guessing of a valid code and bypass the intended second authentication factor, resulting in unauthorized account access. The patch introduces per-user failed-OTP tracking, blocks verification after 30 failed attempts for one hour, clears the counter after a successful OTP verification, and provides administrator recovery actions to purge affected lockouts.

A path traversal vulnerability exists in AIL Framework before the release containing commit 0041456af25da0cdea1c1c4624e46baff2731d8f. An authenticated AIL user can supply crafted object identifiers through the investigation workflow to cause file paths to resolve outside the intended image, favicon, or screenshot storage directories. This may allow the attacker to download and read arbitrary files that are accessible to the AIL process. The issue occurs because user-controlled path components were joined with application storage paths without verifying that the resolved path remained within the expected directory. The affected download functionality could then include the contents of such files in a generated archive.

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.

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.

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

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.

Multiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (id) and ownership/scope foreign keys (event_id, org_id, user_id, sharing_group_id, galaxy_cluster_uuid, organisation_uuid, 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.

AIL framework contains a path traversal vulnerability in the /objects/item/diff endpoint. The endpoint accepts item identifiers through the s1 and s2 query parameters and, prior to the fix, attempted to retrieve and compare item contents without first verifying that both referenced items existed as valid AIL objects. An authenticated AIL user could craft malicious item identifiers containing path traversal sequences to cause the application to read gzip-compressed files accessible to the AIL process. This could result in unauthorized disclosure of local file contents, limited to files readable by the application and compatible with the expected gzip-compressed item format. The issue was fixed by validating that both requested items exist before their contents are accessed.

An authorization flaw in MISP’s object add/edit handling allowed an authenticated user with object editing permissions to assign a MISP object, or attributes contained within an object, to a sharing group that the user was not authorized to use or view. When editing objects, the sharing group validation was performed against the wrong request data structure after object fields had been merged to the top level, causing the check to be bypassed. In addition, attributes embedded in objects were not individually validated for authorized sharing group use. An attacker could craft a request with distribution set to 4 and an arbitrary sharing_group_id, potentially disclosing the existence or name of otherwise non-visible sharing groups and improperly modifying the distribution metadata of objects or contained attributes.

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 sharing_group_id 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 sharing_group_id 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 sharing_group_id when the event distribution is not set to sharing group distribution.

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

MISP contains a reflected cross-site scripting vulnerability in the UiBeta event index view. The urlparams value is inserted into an inline JavaScript handler using HTML escaping inside a single-quoted JavaScript string. Because browsers HTML-decode attribute values before JavaScript parsing, a crafted searcheventinfo value can restore encoded quote characters and break out of the JavaScript string. An attacker could craft a malicious URL that, when opened by a victim using the UiBeta event index, executes arbitrary JavaScript in the victim’s browser in the context of the MISP instance. The issue is fixed by encoding the value as a JavaScript string literal with json_encode() before applying HTML escaping at the attribute layer.

MISP contains a path traversal vulnerability in OrganisationsController::getOrgLogo. The vulnerable code builds organisation logo file paths using organisation-controlled fields such as id, name, and uuid without ensuring that the resolved file remains inside the intended APP/files/img/orgs/ directory. An attacker able to influence an organisation field, for example the organisation name, could use path traversal sequences to cause MISP to return arbitrary readable .png or .svg files from outside the organisation logo directory. The issue is fixed by resolving candidate paths with realpath() and verifying that they remain under the expected base directory before serving the file.

A stored cross-site scripting vulnerability exists in MISP when the Overmind theme is used. The setHomePage endpoint previously saved the user-controlled path value through setSettingInternal(), bypassing the normal setSetting() validation logic, including validate_homepage, which requires homepage paths to start with /. As a result, an authenticated user could store an arbitrary homepage value, including an XSS payload. The stored value was later rendered in app/View/News/index.ctp as the href attribute of the “Continue to homepage” link without HTML escaping. This could allow execution of attacker-controlled JavaScript in the browser context of the affected MISP instance when the crafted homepage link is rendered and interacted with. The issue is fixed by always persisting the homepage setting through setSetting(), ensuring validation and access checks are applied, and by HTML-escaping the homepage value before rendering it in the news view.

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.

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, org_id, orgc_id, and user_id. 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.

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

MISP contains an insecure default configuration in which the Security.check_sec_fetch_site_header 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.check_sec_fetch_site_header 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 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.

Cerebrate before version 1.37 exposed credential material from self-registration requests. The self-registration workflow stored the registrant’s hashed password in the inbox message data payload. This payload was returned unredacted through inbox index and view responses, including HTML, JSON, and CSV outputs, and could also be written unredacted into audit log entries for the inbox message. An authenticated user with sufficient privileges to access inbox entries or related audit logs could retrieve password hashes associated with pending self-registration requests. Although the exposed value is a password hash rather than a plaintext password, disclosure of password hashes may enable offline password-cracking attempts and could increase risk where users reuse passwords across systems. Cerebrate 1.37 fixes the issue by redacting sensitive password and authkey fields from inbox display/API output and recursively redacting those fields from JSON values written to audit logs, while leaving the stored registration payload intact for account creation processing. Affected component: Inbox self-registration request handling and audit logging Fixed version: Cerebrate 1.37

Cerebrate before version 1.37 allowed the id primary key field to be supplied through request input during CRUD edit operations and certain custom entity patching flows. In affected entities that did not explicitly mark id as inaccessible, an authenticated attacker could submit a crafted edit request containing the id of another record, causing the save operation to update that unrelated record instead of the record identified by the route parameter. The issue affected several entity types inheriting permissive mass-assignment defaults, including User, Role, UserSetting, LocalTool, PermissionLimitation, and EnumerationCollection. Since UserSettings edit functionality was reachable by any authenticated user, exploitation could allow unauthorized modification of records within the same entity type, with impact depending on the affected endpoint and writable fields. Cerebrate 1.37 fixes this by stripping id from request input after marshalling callbacks and by globally marking id as inaccessible in the base AppModel entity. The discovery of those potential vulnerabilities are inherited from initial finding from Jeroen Pinoy additional support from AI-Assisted Optus 4.8 (the commit wrongly assign Claude Fable 5 as the model switched) and coordinated by Andras Iklody.

Cerebrate before version 1.37 contains a mass-assignment vulnerability in the generic CRUD add path. The add() handler attempted to remove an attacker-supplied id from $params before normalizing the request through __massageInput(). Because the normalized $input could still contain an id field, a user able to reach an affected add endpoint could supply an identifier that should have been server-controlled. Successful exploitation could allow creation of objects with attacker-chosen identifiers, potentially causing unauthorized data manipulation, object spoofing, inconsistent references, or disruption through identifier collisions, depending on the affected model and endpoint permissions. The issue was fixed in v1.37 by removing id from the normalized input before entity patching.

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Nomachine allows Argument Injection.This issue affects Nomachine: before 9.5.7, before 8.23.2.

A stored cross-site scripting vulnerability existed in MISP BSimVis tag rendering code. Several client-side rendering paths interpolated tag names, collection names, entity identifiers, cluster names, and tag metadata directly into HTML, HTML attributes, inline JavaScript event handlers, and CSS style values without context-appropriate escaping. The patch adds shared escaping helpers for HTML, attributes, JavaScript strings, and CSS color validation, then applies them across tag badges, tooltips, context menus, cluster cards, autocomplete suggestions, and dynamically inserted tag cards. An attacker able to create or influence stored tag or metadata values could inject a crafted payload that is later rendered in another user’s browser. Successful exploitation could execute arbitrary JavaScript in the victim’s session when they view affected BSimVis pages, potentially allowing the attacker to perform actions as the victim, read data available to the victim, or alter displayed application content. This issue affects MISP bsimvis: through v0.2.0.

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.

A vulnerability in the MISP dashboard widgets allowed an authenticated user to manipulate the fields option and influence which fields were returned by the New Users and New Organisations widgets. In some cases, requesting a field set that became empty after validation or redaction could cause the underlying query to fall back to returning unintended model fields. For the New Users widget, this could allow a non-site-admin user to obtain user e-mail addresses even when user e-mail disclosure was disabled by configuration. For the New Organisations widget, crafted field selection could similarly result in unintended organisation fields being included in the dashboard response. The issue was caused by applying field filtering and redaction in a way that could leave the selected field list empty. The patch ensures that the allowed field list is built safely, that restricted fields such as user e-mail addresses are removed before user-supplied field selection is processed, and that an empty field selection falls back only to the permitted default fields. Impact: An authenticated low-privileged user with access to the affected dashboard widgets may be able to disclose restricted user or organisation metadata, including user e-mail addresses depending on configuration.

A security issue was fixed in the correlations over-correlation endpoint where the order query parameter was accepted from user-controlled named request parameters. This allowed an authenticated user to override the server-defined ordering of over-correlating values. Depending on how the value was processed by the underlying data access layer, this could allow manipulation of database query ordering and potentially expose the application to unsafe query construction. The patch removes order from the set of request-controlled parameters and instead sets the ordering server-side to occurrence desc after processing allowed user parameters. Affected component: app/Controller/CorrelationsController.php, overCorrelations() Security impact: An authenticated attacker could influence the ordering clause used by the over-correlations query. The direct impact appears limited to query manipulation unless further evidence confirms SQL injection or unauthorized data exposure through the manipulated ordering expression.

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 open redirect vulnerability existed in MISP UsersController::routeafterlogin() because the value stored in the pre_login_requested_url session key was used as the post-login redirect destination without sufficiently enforcing that it was a local application path. An unauthenticated remote attacker could craft a link that causes a victim to visit a trusted MISP instance and, after successful authentication, be redirected to an attacker-controlled external URL. This could be abused to increase the credibility of phishing attacks, redirect users to counterfeit login pages, or deliver attacker-controlled content from an untrusted domain. CWE-601 describes this weakness as accepting user-controlled input that specifies an external link and using it in a redirect, with phishing as a common consequence. The patch mitigates the issue by decoding and parsing the URL, rejecting URLs with a scheme, host, user component, missing or non-local path, and protocol-relative forms such as //example.com and /\example.com.

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.