Christian Studer

A flaw in the STIX import logic allows a crafted STIX document to influence security-sensitive MISP attribute metadata. The system automatically selects between an internal MISP parser and an external STIX parser based on metadata within the document, such as tool labels for STIX2 or the document title for STIX1. Since these indicators are controlled by the producer, an attacker can spoof them to force the use of the internal parser. When STIX2 content is processed as an internal MISP export, the `x misp attributes` dictionary is passed directly to the `misp object.add attribute()` function without restriction. This allows an attacker to inject unauthorized fields such as `distribution`, `sharing group id`, and `tags`. Such manipulation can lead to information being shared against organizational policy or the disruption of downstream automation. This issue involves mass assignment, where externally influenced fields are accepted without an allow-list, and the use of untrusted values for security-relevant classification decisions.

A parser state isolation issue exists where data from a previously processed STIX document may be retained and incorporated into a MISP event generated from a subsequent document if the same parser instance is reused. This occurs because several STIX 1 and STIX 2 parser components maintain per-document state that is not fully cleared between conversions. In the STIX 2 parser, galaxy and galaxy-cluster information can survive a parser reset. For STIX 1 parsers, retained data may include galaxies, references, passive DNS bookkeeping, package titles, dates, and timestamps. This issue primarily affects applications that use the misp-stix API directly and reuse parser instances across independent STIX documents. An attacker could potentially contaminate subsequent MISP events, compromising the integrity of threat intelligence through incorrect associations or misleading contextual information. In environments with different access controls for consecutive documents, this could lead to limited information disclosure. Exploitation requires the consuming application to reuse the same parser instance and depends on the order of processed documents.

A denial-of-service issue exists when processing attacker-controlled STIX 1 or STIX 2 documents. The import code utilizes `sys.exit()` to handle parsing and loading failures; since `SystemExit` inherits from `BaseException` rather than `Exception`, these failures bypass standard exception handlers, allowing a malformed document to terminate the importer process. Furthermore, the lack of input-size limits allows documents to be materialized in memory before validation, potentially consuming two to seven times the input size in memory. This can lead to excessive CPU and memory consumption, resulting in service degradation, abnormal process termination, or the interruption of automated ingestion workflows.

A path traversal issue exists in the handling of MISP object template names during STIX 2 import and MISP-to-STIX 2 export. The system constructs a filesystem path by joining the configured MISP object-template directory, the object name, and definition.json. Because object names from untrusted STIX or MISP content are not sufficiently restricted, an attacker can provide a crafted name containing path separators or traversal sequences like `../` to escape the intended directory and load a definition.json file from another accessible location. During STIX 2 import, the `x misp name` variable from a custom STIX object can trigger this mechanism. This issue can be persistent, as a malicious name stored in a MISP event may be processed during STIX 2 export by a process with higher privileges. If a suitable file is found outside the template directory, its contents may be interpreted as a template, leading to the disclosure of local data and the modification of the object's metadata or semantics.

The software renders data from a remote MISP instance into the event-browser interface using HTML interpolation. A malicious or compromised remote server can control fields such as event IDs, event information, organization names, tags, tag colors, TLP labels, distribution labels, and error/flash text to inject HTML or script-capable content into the interface. This occurs because remote-derived values are passed to `innerHTML` and tag colors are not strictly validated, potentially allowing malicious CSS values.

Authenticated users can add or remove emoji reactions on comments without authorization checks to verify if they are permitted to view the target comment. The `react()` handler passes a user-controlled `comment id` directly to `comments repo.toggle reaction()` after only validating the syntax of the ID and the permitted emoji. This lack of comment-level visibility enforcement allows a user to modify the reaction state of private or inaccessible comments if the ID is known.

The software fails to HTML-escape attacker-controlled values used in ECharts Sunburst and Treemap tooltip formatters. Slice names, which may originate from STIX or MISP data—including STIX types, `relationship type`, pattern prefixes, and MISP category or type values—are processed without proper sanitization. Because ECharts interprets the formatter return value as HTML, an attacker can inject markup or script-capable content. This allows for the execution of malicious content when a user hovers over the affected slice in the visualization.

Insufficient validation of saved graph configuration data allows a malicious user to store a crafted `svgIcon` value. Since these configurations can be viewed by other users or administrators, the `svgIcon` property is interpreted as HTML by Pivotick, leading to script execution in the viewer's browser.

An issue exists where a tag's icon value can be stored and subsequently interpolated into HTML using Vue's `v-html` directive. The `mapIcon()` function previously constructed an HTML string directly from the user-supplied icon value, allowing a crafted value to break the intended markup and inject attacker-controlled HTML. This can lead to the execution of malicious payloads in the viewer's browser, including within the administrative triage interface.

An SSRF (Server-Side Request Forgery) issue exists where the server can be coerced into making requests to internal network addresses. The URL validation routine failed to resolve domain names before checking for private, loopback, link-local, or reserved IP addresses, allowing attackers to use hostnames that resolve to internal targets. This allows anonymous callers to trigger requests to internal systems and read the responses via the '/fetch misp event' and '/misp search events' endpoints.

The software improperly handles conversion-table values within the search highlighting feature. The `highlight()` function either returns underlying text directly when no search query is provided or performs a regex replacement to insert `<mark>` tags without escaping the original content. Since the output is processed by an HTML-rendering sink, malicious markup in conversion data can be interpreted as HTML. This occurs because the application fails to convert special characters into HTML entities before inserting highlighting elements.

Several state-changing account operations are exposed as GET requests, making them susceptible to cross-site request forgery (CSRF). CSRF is a flaw where a third-party site induces a victim's browser to send authenticated requests automatically to a target server. The affected API endpoints are '/account/follow', '/account/delete notification', '/account/mark notification read', and '/account/mark all read'.

The software fails to apply comment-level access-control rules during the generation of evaluation report exports. While standard comment retrieval correctly filters based on conversion visibility, privacy, ownership, authorship, and administrative privileges, the `build evaluation report()` function includes all evaluation comments regardless of these rules. This allows a user authorized to view a conversion to export reports in Markdown or PDF formats and access private comments and author names intended only for the conversion owner, the comment author, or an administrator.

An incomplete authorization check exists in the 'conversion-history details' endpoint. When a history record references a deleted conversion, the system returns a null value during the conversion lookup. Because the original logic only denied access if the conversion object existed and failed the visibility check, deleted conversions bypassed this security measure. This allows a user who can request a specific history entry to access the retained input and output data of deleted conversions.

An issue exists where the account following-list endpoint discloses the email addresses of users. When an authenticated user follows another account, the `get following()` function includes the `user.email` field in the API response, along with the name, user ID, and follow date. An authenticated attacker could systematically follow users to collect these email addresses, as this information is not required for the functionality.

A stored cross-site scripting (XSS) issue exists in the conversion graph used to visualize MISP and STIX content. Attacker-controlled values from converted CTI data are passed to HTML-parsing sinks in the graph user interface without sufficient neutralization. Specifically, node labels, node sublabels, edge labels, node properties, edge properties, and node types can contain crafted HTML or JavaScript. The Pivotick graph library renders these values through HTML-parsing operations, allowing malicious elements with event handlers to be interpreted as markup. Additionally, the Open raw JSON functionality uses `document.write()` with an interpolated HTML string, enabling crafted JSON to inject executable markup. Further vectors exist in the graph properties panel where the `tryResolveHTMLElement` function processes string values using `template.innerHTML`, leading to execution when a graph node is hovered over or selected.

Stored cross-site scripting occurs due to insufficient neutralization of Vue template expression delimiters in server-rendered user-controlled data. An unauthenticated attacker can inject malicious Vue expressions using `[[ ... ]]` delimiters within a public conversion's name, description, or user profile names. While Jinja HTML escaping is used, the data is placed in a DOM region compiled by Vue, which interprets the input as a template expression instead of plain text. By utilizing the JavaScript Function constructor via `[].constructor.constructor(...)`, an attacker can execute arbitrary JavaScript in the security context of the CTI-Transmute origin. This bypasses the nonce-based Content Security Policy because the Vue runtime compiler requires the `unsafe-eval` policy exception. The payload is stored and executes when a user or administrator views the affected page, potentially allowing the attacker to access sensitive data, extract API keys or tokens, perform authenticated actions, or modify application data.

A cross-site request forgery issue exists in the administrative user deletion functionality. The '/account/delete/<id>' endpoint accepted HTTP GET requests for operations that modified application state. An unauthenticated remote attacker could induce an authenticated administrator with an active session to visit a malicious link, causing the browser to automatically include session credentials and delete a selected user account without confirmation. This could lead to the unauthorized deletion of arbitrary user accounts, resulting in denial of access for users or disruption of the instance administration. The exploitation relies on the `id` variable to specify the target account.

A server-side request forgery issue exists in the evaluation report PDF-generation functionality. User-controlled CTI content, such as conversion names, descriptions, and comments, is converted from Markdown to HTML and rendered as a PDF using WeasyPrint. The renderer used default URL-fetching behavior without restricting protocols or destinations. An attacker can inject crafted resource references using schemes like `http://`, `https://`, or `file://`, allowing the application server to fetch resources using its network connectivity and filesystem privileges. This could lead to accessing internal services, probing internal hosts, retrieving local files readable by the application process, or exposing fetched content within the generated PDF.

An uncontrolled resource-consumption issue exists in the unauthenticated '/activity timeline' endpoint. The endpoint accepts a user-controlled `days` query parameter that lacks a reasonable range restriction. A remote, unauthenticated attacker can provide an excessively large value for this parameter, forcing the application to retrieve and process activity data over an arbitrarily large period. This action can exhaust database, CPU, or memory resources, delay concurrent request processing, or cause internal server errors, potentially degrading the availability of the website.