Iglocska

An access control flaw exists in the proposal visibility logic for shadow attributes. The authorization check fails to verify the distribution level, allowing any user belonging to a sharing group to view proposals on attributes or objects associated with that group, even when distribution levels 1-3 should restrict such visibility. Additionally, the owning organization is denied access to proposals on its own organization-only attributes. This leads to the unauthorized disclosure of proposed attribute changes.

A logic error exists in the event synchronization process during the preparation of event reports for remote push. The system applies the filtering of non-exportable tags only once after iterating through all reports instead of applying it to each individual report. This leads to the disclosure of restricted tag information to the receiving instance for all reports except the last one. Additionally, if the last report is withheld, a null report is pushed, which prevents the remote instance from saving the event.

A reflected cross-site scripting (XSS) issue exists in the workflow module interface. The application renders parameter names returned by the misp-modules service as raw HTML form labels without output encoding. An attacker capable of influencing these parameter names can inject arbitrary HTML or JavaScript. This script executes within the browser session of an authenticated user, potentially leading to session token theft, interface manipulation, or unauthorized actions.

The remote event preview feature allows CSS injection when a user previews an event from a linked server. The issue occurs because the color value of remote tags is written into an inline CSS style attribute without sufficient validation. While HTML entity encoding is used, the value is still interpreted as CSS, enabling a compromised or malicious linked server to inject arbitrary CSS declarations. An attacker who can modify tags on a linked instance can use this to perform UI manipulation, visual spoofing, or limited information disclosure when a victim views the remote event preview page.

A flaw in the server settings lookup mechanism allows authenticated users to retrieve sensitive configuration data that should be redacted. The settings lookup function resolves dotted setting names to nodes in a configuration tree; however, providing a branch name (such as Security, MISP, or Plugin) instead of a specific leaf setting causes the function to return the entire sub-tree. Since branch nodes lack a redaction flag, the redaction check in the settings retrieval endpoint is bypassed. This exposes sensitive information, including the security salt, Redis connection passwords, and plugin API keys. Additionally, an endpoint used to edit server settings similarly returns the entire configuration store when a branch name is resolved.

A data integrity flaw exists in the event deletion logic. When an authenticated user with sufficient privileges deletes an event, certain associated records are not removed from the database, resulting in orphaned entries. Affected record types include event report tags, event graph entries, proposal (shadow attribute) correlations, fuzzy ssdeep correlation chunks, and attachment scan results. These orphaned records may contain sensitive threat intelligence data, such as correlation mappings, scan results, and report metadata. This persistence creates a risk of unintended data retention and potential information exposure if the records are accessed through other application queries or administrative interfaces. Additionally, the accumulation of these records may lead to storage bloat.

An issue exists in the handling of module plugin settings where the server drops the `redacted` and `cli only` flags declared in a module's configuration metadata during the rebuild for API consumption. This allows an authenticated user with access to server settings to view sensitive credentials, such as API keys, via the 'servers/getSetting' and 'servers/serverSettingsEdit' endpoints. Additionally, settings intended to be modified only via the command-line interface can be altered through the web API, bypassing intended access restrictions.

A race condition exists in the email-based one-time password (OTP) login flow. This occurs because the OTP value is read from the shared store, validated, and deleted in separate non-atomic steps. Consequently, if two HTTP requests using the same valid OTP are submitted concurrently, both may successfully authenticate and establish sessions before the deletion takes effect. This violates the one-time-use guarantee of the OTP and may facilitate unauthorized access if a code is intercepted or shared.

Instances configured to require TOTP enrolment via `Security.otp required` only enforced mandatory two-factor authentication for standard browser requests. Authenticated users who had not enrolled in TOTP could bypass this requirement by using non-browser request types, such as AJAX/XHR calls, REST API requests, `.json` format URLs, `restSearch` queries, or automation actions. This occurs because machine-readable requests cannot follow the redirect to the TOTP enrolment page, allowing the user to maintain full access to the instance without completing the second-factor setup.

A defect in the event save workflow prevents the correlation engine from recalculating correlations when an event's distribution level or sharing group is modified. This occurs because the internal before-save hook stores new data instead of previously persisted values, causing the after-save comparison to fail in detecting changes. Consequently, stale correlations persist, which may lead to unintended information disclosure if an event is moved to a more restrictive group, or a lack of relevant correlations if distribution is widened. This issue requires an authenticated user with write access to modify the `distribution` or `sharing group id` fields.

A validation flaw exists in the object synchronization logic. When a MISP Object is created without a description, it is stored correctly on the originating instance, but the receiving instance's validation rule rejects it during replication because the description field is empty. This causes the receiving instance to silently drop the object and its associated attributes, resulting in the loss of threat-intelligence data and data-integrity loss across the sync topology. This can be triggered by any authorized user with object-creation privileges.

Critical infrastructure settings, specifically the Redis host addresses used by the core application, the ZeroMQ plugin, and the SimpleBackgroundJobs plugin, are exposed through the web UI and API to site-admin users. Because background job workers trust raw Redis job payloads without additional validation, an attacker with a hijacked site-admin session can redirect these settings to an attacker-controlled Redis server and restart the workers. This allows the injection of malicious job payloads, leading to arbitrary command execution as the worker account and potential data exfiltration. Furthermore, the `download attachments on load` setting, which manages inline attachment rendering, is modifiable via the same interface, potentially facilitating client-side attacks.

The `CakeResponse::download()` function in `lib/Cake/Network/CakeResponse.php` fails to sanitize caller-supplied filenames when constructing the Content-Disposition header. This leads to two injection vectors: the use of C0 control characters (CR or LF) can cause PHP to drop the Content-Disposition header, resulting in the response body rendering inline in the browser, and the use of double-quote characters can terminate the quoted-string value early to inject additional header parameters. An authenticated user can upload an attachment with a crafted filename that, when viewed by another authenticated user, allows for header manipulation and the execution of arbitrary HTML or JavaScript. This condition enables stored cross-site scripting, which can lead to session hijacking, data exfiltration, and unauthorized actions.

A cross-site scripting (XSS) issue exists in the TAXII object viewer. The application renders the JSON content of string properties directly into an HTML pre block without proper HTML-encoding when displaying a remote TAXII object. An attacker capable of influencing the content of a TAXII object, such as by publishing a malicious object to a TAXII server that the victim's instance subscribes to, can inject arbitrary HTML or JavaScript. This script executes within the context of the authenticated user's session, potentially leading to the theft of session tokens, API keys, or other sensitive data, and allowing actions to be performed on behalf of the user.

The ID Translator feature contains a cross-site scripting (XSS) flaw. When a user accesses the ID Translator page, the application retrieves event identifiers from linked remote servers. Because the application fails to properly encode the event ID returned by the remote server before rendering it in the HTML output, a compromised or malicious linked server can provide a crafted event ID containing arbitrary HTML or JavaScript. This allows the execution of scripts in the browser of an authenticated user, potentially leading to session hijacking or credential theft.

A stored cross-site scripting (XSS) issue exists in the index table rendering of the remote event preview. The count field template fails to apply HTML encoding to the field value, although it escapes the associated link URL. An attacker with permissions to create or modify events on a linked remote MISP server can craft an event identifier containing HTML or JavaScript markup. When a user on the local instance views the remote event preview index, the unescaped value is rendered in the browser, enabling arbitrary script execution. This can lead to session hijacking, data exfiltration, or unauthorized actions performed as the authenticated user.

Improper access control exists in the attribute search and paginated attribute view endpoints. When an authenticated user with read access to an event owned by another organization queries for soft-deleted attributes, the application discloses those attributes. While the event detail view correctly restricts visibility of soft-deleted attributes to the owning organization and users with sync permissions, the search and paginated view code paths lack this restriction. This can lead to the unauthorized disclosure of sensitive threat intelligence attributes, such as indicators of compromise (IOCs) and context, which the owning organization intended to remove from general visibility.

An authorization flaw exists in the correlation handling during attribute searches. The system grants access to correlated attributes and events using a stale distribution snapshot stored on the correlation row instead of the live event access control list. Since the distribution columns in the correlation row are point-in-time copies lacking a published flag, authorization checks fail when an event is restricted, such as when it is unpublished or its sharing group is modified. This allows an authenticated user with read access to some events to retrieve attributes and event metadata from events they are no longer authorized to view.

An authorization bypass exists in the related events listing functionality. When a user requests a list of events correlated to a specific event, the system retrieves metadata directly from the correlation table without re-validating the caller's access rights for each related event. Because the correlation table uses a snapshot of the distribution level and sharing group from the time of creation and lacks a published flag, metadata such as titles, dates, and correlating value counts may be disclosed for events that are unpublished or have updated access restrictions. This allows an authenticated user with access to at least one event to perform reconnaissance on threat-intelligence event names and timelines across different sharing groups.

Improper input validation exists in the decaying model import functionality. The import endpoint was designed to create a new decaying model restricted to the importing user's organization with the default flag disabled. However, the application only stripped top-level `id` and `uuid` fields and pinned `org id` and `default` on the outer array. An authenticated user with `perm decaying` permissions could provide a nested model key containing its own primary key, organization identifier, and default flag to bypass these restrictions during the save operation. This could allow a user to overwrite existing decaying models from other organizations, modify models flagged as organization defaults to affect scoring behavior, or reassign a model's organization to an arbitrary value.