| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The MISP Modules website component contains an open redirect vulnerability in its login endpoint. The /login route accepted a user-supplied next query parameter and passed it directly to Flask's redirect() function without validating the destination. An attacker could craft a URL such as https://victim-host/login?next=https://attacker.example/phish and deliver it to a user (e.g., via email or a lookalike page). After the user successfully authenticated, the application issued a 302 redirect to the attacker-controlled external URL. This enables phishing attacks where a user, believing they are still on the legitimate MISP Modules site, may enter additional credentials or sensitive information on the attacker's page. It can also be used to obscure the true destination of a link, bypassing user trust in the legitimate domain. The vulnerability requires the victim to interact with the crafted URL and complete a login, but no prior authentication or special configuration is needed on the attacker's side. The affected component is the website sub-project of misp-modules, specifically the account blueprint in website/app/account/account.py. No version boundaries are specified in the patch metadata. |
| The MISP Modules website component contains an information disclosure vulnerability in the external tools management interface. The /external_tools/list endpoint returned stored API keys (the api_key field) in its JSON response via the ExternalTools model serializer. Additionally, the browser-based edit form pre-populated the API key input field with the stored credential value, exposing it in the DOM.
The /external_tools/list endpoint is accessible without authentication (the regression tests verify the response for both authenticated and unauthenticated clients), meaning any network-reachable client could retrieve the API keys for all configured external tools. These keys are used by the server to authenticate submissions to external analysis or enrichment services, so their disclosure allows an attacker to impersonate the MISP instance or directly access those external services.
The vulnerability also affected the edit workflow: the change_config endpoint previously required the API key to be present and non-empty on every save, forcing the key to round-trip through the client. The browser JavaScript stored the key in a reactive state object and updated the in-memory tool list with the credential value, further increasing the window of exposure in client-side memory and network traffic.
Affected component: the website sub-application of MISP Modules, specifically the external_tools module (serializer in models.py, list endpoint, and the external_tools_index.html template). The impact is limited to confidentiality of the stored API keys; no integrity or availability impact on the MISP Modules website itself is indicated by the patch. |
| The MISP Modules website component exposes external tool management endpoints (add, delete, change status, and change configuration) that did not enforce the optional administrator authentication policy. When ADMIN_PASSWORD was configured in the application environment, the module configuration endpoints correctly required an authenticated administrator session, but the external tools management handlers processed requests from anonymous users without any authorization check. An unauthenticated attacker with network access to the website could add arbitrary external tools, delete existing tools, toggle their active status, and modify their configurations including API keys and ingestion URLs. This inconsistency allowed bypass of the intended access control for the external tools management functionality. The vulnerability is conditional on ADMIN_PASSWORD being set; installations without an admin password intentionally permit open management access by design. The affected component is the external_tools Flask blueprint within the MISP Modules website application. |
| The Wikidata Lookup expansion module (wiki.py) in MISP misp-modules contained a SPARQL injection vulnerability. The handler function constructed a SPARQL query by directly concatenating the user-supplied text value into the query string without any escaping or parameterization: 'SELECT ?item WHERE { ?item rdfs:label"' + request.get("text") + '" @en }'. An authenticated MISP user with access to the module could supply a crafted text attribute value containing SPARQL syntax (quotes, closing braces, UNION, SERVICE, LIMIT, etc.) to alter the structure of the query sent to the Wikidata SPARQL endpoint. This could allow an attacker to modify the query logic, extract unintended data, or cause the query to fail in ways that expose internal error details. Additionally, the old error handling path formatted raw exception objects into the response string ('wikidata API not accessible {}'.format(e)), potentially leaking internal information such as proxy credentials, query contents, or response bodies. The module also used a spoofed browser user-agent string and the deprecated Wikidata endpoint. The vulnerability required authenticated access to the MISP instance and the ability to invoke the wiki expansion module with a text attribute. The impact is limited to manipulation of the enrichment query and potential disclosure of internal error details; it does not directly compromise the MISP server or its stored data. |
| The sourcecache expansion module in MISP Modules (misp-modules) contains a Server-Side Request Forgery (SSRF) vulnerability. When a user with permission to create or modify attributes of type 'link' or 'url' submits an attribute value, the module passes the URL directly to its internal archiving function without any validation of the target address. An attacker can therefore craft a URL pointing to loopback addresses (e.g., 127.0.0.1), private network ranges, link-local addresses, or cloud metadata endpoints (e.g., 169.254.169.254). The MISP server will issue an HTTP request to that target and store the response body in the event, effectively exfiltrating data from internal services to the attacker through the MISP interface. Non-HTTP schemes such as file:// are also accepted, potentially allowing local file disclosure. The vulnerability requires an authenticated MISP user with the ability to create or edit attributes of the affected types. The security impact is information disclosure from internal services reachable by the MISP server, including sensitive data such as cloud credentials, internal application data, or local files. |
| MISP Guard, a proxy that enforces security policies on MISP feed data, contained an incomplete validation check for required taxonomy tags. When a feed event or its attributes carried tags belonging to a required taxonomy (for example, TLP), the guard only verified that at least one tag of that taxonomy matched the configured allowed list. It did not verify that every tag of the required taxonomy present on the event or attribute was in the allowed list. As a result, an event or attribute could simultaneously carry an allowed tag (e.g., tlp:clear) and a non-allowed tag (e.g., tlp:red or tlp:amber) and still pass the guard's policy check. This allowed data marked with a higher classification or sensitivity level to be distributed through feeds configured to only distribute lower-classification data, effectively bypassing the intended data-handling restrictions. The vulnerability affected both event-level and attribute-level tag validation, including attributes nested within objects and shadow attributes. An attacker with the ability to author or modify MISP events in a feed source could include non-allowed taxonomy tags alongside allowed ones to exfiltrate more sensitive data to feed consumers than the guard policy intended to permit. |
| MISP mispguard is a security filtering proxy that inspects and blocks MISP feed responses based on configured rules. The process_feed_response method in src/mispguard.py was responsible for evaluating feed responses before they reached the MISP instance. The original logic only explicitly handled the case where the HTTP status code was not 200 by passing the response through without filtering, on the assumption that non-200 responses would not carry ingestible event data. However, HTTP 2xx status codes other than 200 (such as 201 Created, 203 Non-Authoritative Information, and 206 Partial Content) were also passed through unfiltered. Because MISP may still ingest content from these responses, a malicious or compromised feed host could return a 203 or 206 status code with arbitrary content, effectively bypassing all of mispguard's filtering rules. This allowed unfiltered or malicious feed data to be ingested into the MISP instance, undermining the security controls that mispguard is designed to enforce. The vulnerability requires the attacker to control or compromise a feed endpoint configured in the MISP instance. No authentication or user interaction is required beyond the feed polling mechanism already in place. |
| MISP contains a vulnerability in its server settings lookup mechanism that allows an authenticated user to retrieve sensitive configuration data that should have been redacted.
The settings lookup function resolves a dotted setting name to a node in the configuration tree. When a branch name (such as Security, MISP, or Plugin) is supplied instead of a specific leaf setting, the function returns the entire sub-tree. Because a branch node does not carry a redaction flag, the redaction check in the settings retrieval endpoint is bypassed, and the full branch contents are returned to the caller. This exposes sensitive values including the security salt, Redis connection passwords, and plugin API keys.
A second endpoint that edits server settings similarly reads the entire configuration store when a branch name is resolved, returning all settings to the caller.
The impact is disclosure of sensitive server configuration secrets to any user who can access the server settings endpoints.
Affected versions: <2.5.48. |
| MISP Guard, a proxy-based security filter for MISP feed distribution, contains a case-sensitivity flaw in multiple policy enforcement checks. The functions check_required_taxonomy_exists, check_required_taxonomy_tags_allowed, check_blocked_attribute_categories, and check_blocked_analyst_data_sharing_groups_uuids performed case-sensitive string comparisons when matching event tags, attribute categories, and sharing-group UUIDs against configured allow/block lists.
An attacker with the ability to create or modify events in a MISP instance (or a connected instance that pushes events through the guard) could craft events using different letter case in taxonomy tag names, attribute categories, or sharing-group UUIDs to bypass the configured security policies. For example, if the policy requires the 'tlp' taxonomy with only 'tlp:clear' allowed, an event tagged 'TLP:AMBER' would not be recognized as belonging to the 'tlp' taxonomy and would therefore not be checked against the allowed-tags list, resulting in the event being forwarded to feed consumers. Similarly, a blocked attribute category such as 'Person' would not match a configured block entry of 'person', allowing the attribute to pass through the filter.
The security impact is unauthorized disclosure of threat-intelligence data that the operator intended to restrict. Events carrying non-allowed TLP (Traffic Light Protocol) markings, blocked attribute categories, or blocked sharing-group associations are forwarded to downstream feed consumers in violation of the configured distribution policy. This undermines the confidentiality controls that MISP Guard is designed to enforce.
The vulnerability is trivially exploitable: the attacker only needs to alter the letter case of a tag, category, or UUID string. No authentication beyond normal MISP event-creation privileges is required, and no user interaction is needed. |
| The html_to_markdown expansion module in MISP Modules contains a server-side request forgery (SSRF) vulnerability in its is_safe_url() URL validation function. The BLOCKED_RANGES list used to reject unsafe destination addresses was incomplete, omitting several critical IP address ranges. Specifically, the following ranges were not blocked: 0.0.0.0/8 (unspecified, which routes to loopback on Linux), 100.64.0.0/10 (carrier-grade NAT per RFC 6598), ::/128 (IPv6 unspecified), fc00::/7 (IPv6 Unique Local Addresses), and fe80::/10 (IPv6 link-local). The existing list only covered IPv4 loopback (127.0.0.0/8), RFC 1918 private ranges, IPv4 link-local (169.254.0.0/16), and IPv6 loopback (::1/128).
An authenticated user with the ability to create or modify MISP attributes that trigger the html_to_markdown expansion module could supply URLs pointing to these unblocked internal address ranges. Because the module fetches the URL server-side to convert HTML content to Markdown, the request is made from the MISP server's network context. This allows an attacker to probe and read responses from internal services, carrier-grade NAT infrastructure, or link-local endpoints that would otherwise be unreachable from external networks. IPv4-mapped IPv6 forms (e.g., [::ffff:0.0.0.0]) also bypassed the existing checks.
The security impact is primarily confidentiality: an attacker can read data served by internal services reachable from the MISP server. The MISP instance itself is not compromised, but it is abused as a proxy to access otherwise restricted network resources. |
| In MISP, the event synchronization process contained a logic error in the preparation of event reports for remote push. The filtering of non-exportable tags was applied only once after the iteration over all reports, rather than to each individual report.
As a result:
- All reports except the last one in the set were pushed to the remote MISP instance with their non-exportable tags intact, effectively disclosing restricted tag information to the receiving instance.
- When the last report in the set was withheld (empty), a null report was pushed, causing the remote instance to fail saving the event.
This issue affects any MISP instance configured to push events with multiple reports to a remote server via synchronization.
Affected: <2.5.48. |
| MISP contains a vulnerability in the handling of module plugin settings. When the server rebuilds module-supplied settings for API consumption, it drops the redacted and cli_only flags that a module declares in its own configuration metadata.
As a result:
- A module that marks a setting (such as an API key) as redacted still has its value returned in full by the servers/getSetting and servers/serverSettingsEdit endpoints, exposing sensitive credentials to any authenticated user who can read server settings.
- A module that marks a setting as cli_only (intended to be editable only via the command-line interface) can still be modified through the web API, bypassing the intended access restriction.
An authenticated user with access to server settings can therefore read sensitive module credentials and modify settings that the module author intended to restrict to CLI-only access.
Affected: <2.5.48 |
| MISP contains a reflected cross-site scripting (XSS) vulnerability in the workflow module interface. Parameter names returned by the misp-modules service are rendered as raw HTML form labels on the workflow module page without output encoding. An attacker who can influence the parameter names reported by the misp-modules service can inject arbitrary HTML or JavaScript that executes in the context of an authenticated MISP user's browser.
Preconditions:
- The attacker must be able to control or influence parameter names reported by the misp-modules service.
- A victim must be authenticated and view the affected workflow module page.
Impact:
- Execution of arbitrary JavaScript in the victim's browser session.
- Potential theft of session tokens, manipulation of the MISP interface, or initiation of unauthorized actions on behalf of the victim.
Affected versions: <2.5.48. |
| MISP contains a CSS injection vulnerability in the remote event preview feature. When a user previews an event from a linked MISP server, the colour value associated with each remote tag is written directly into an inline CSS style attribute without sufficient validation. Although HTML entity encoding is applied, the value is interpreted as CSS within the style attribute, allowing a malicious or compromised linked server to inject arbitrary CSS declarations.
An attacker with the ability to create or modify tags on a linked MISP instance can craft a tag colour value containing CSS injection payloads. When a user on the local instance views the event preview, the injected CSS is rendered, potentially allowing UI manipulation, visual spoofing, or limited information disclosure through CSS-based techniques.
Preconditions:
- A linked MISP server relationship exists between the victim instance and the attacker-controlled instance.
- The attacker can create or modify tags on the linked server.
- A victim user views the remote event preview page.
Affected: <2.5.48. |
| MISP contains a data integrity flaw in its event deletion logic. When a user deletes an event, several associated records are not removed from the database, leaving them as orphaned entries. The 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 that should have been removed along with the parent event. Their persistence beyond the intended deletion lifecycle creates a risk of unintended data retention and potential information exposure if the records are reachable through other application queries or administrative interfaces.
Preconditions:
- An authenticated user with sufficient privileges to delete events in MISP.
- The event must have associated reports, graphs, correlations, ssdeep chunks, or attachment scan results.
Impact:
- Residual sensitive data persists in the database after the parent event is deleted.
- Accumulation of orphaned records over time may contribute to storage bloat.
- Orphaned records may be inadvertently exposed through other data-access paths that do not validate the existence of the parent event.
Affected versions: <2.5.48 |
| MISP contains an access control flaw in the proposal (shadow attribute) visibility logic. The authorization check accepted any attribute or object carrying one of the user's sharing groups without verifying the distribution level, and denied the owning organisation access to proposals on its own organisation-only attributes.
- A user belonging to a sharing group could view proposals on attributes or objects with that sharing group, regardless of the attribute's distribution level (levels 1-3 should restrict visibility)
- The owning organisation could not view proposals on its own org-only attributes
Security impact: Unauthorized disclosure of proposed attribute changes to users who should not have access based on distribution level restrictions.
Affected: <2.5.48 |
| MISP contains a validation flaw in its object synchronization logic. When a MISP Object is created without a description, it is stored correctly on the originating instance. However, when that object is replicated to another MISP instance via the sync mechanism, the receiving instance's validation rule rejects the object because the description field is empty. As a result, the receiving instance silently drops the object along with all of its associated attributes, leading to loss of threat-intelligence data.
Preconditions:
- Two or more MISP instances are configured to synchronize objects.
- A user with object-creation privileges creates an object without supplying a description.
- The object is subsequently synced to a peer instance.
Impact:
- Valid objects and their attributes are silently discarded on receiving instances, causing data-integrity loss in the threat-intelligence pipeline.
- The issue is not externally exploitable in a traditional sense but can be triggered by any authorized user who creates objects without descriptions, resulting in unintended data loss across the sync topology.
Affected: <2.5.48. |
| MISP contains a race condition in the email-based one-time password (OTP) login flow. When two HTTP requests carrying the same valid OTP are submitted concurrently, both can successfully authenticate and establish a session. The root cause is that the OTP value is read from the shared store, validated, and then deleted in separate non-atomic steps, allowing a second in-flight request to read the same value before the first request's deletion takes effect.
Preconditions:
- The target MISP instance has email OTP login enabled.
- The attacker possesses a valid, unexpired OTP (e.g., via email interception or social engineering).
- The attacker can issue two HTTP POST requests in close temporal proximity.
Impact:
- The one-time-use guarantee of the OTP is violated; a single code can yield two authenticated sessions.
- This weakens the authentication control and may facilitate unauthorized access if the OTP is shared or intercepted.
Affected versions: <2.5.48 |
| MISP exposes critical infrastructure settings—specifically the Redis host addresses used by the core application, the ZeroMQ plugin, and the SimpleBackgroundJobs plugin—through its web UI and API to site-admin users. The background job workers trust raw Redis job payloads without additional validation. An attacker who obtains a hijacked site-admin session (for example, through a stored cross-site scripting vulnerability) can modify the Redis host settings to point at an attacker-controlled Redis server and then restart the workers. Once the workers connect to the attacker's Redis instance, the attacker can inject malicious job payloads that the workers execute, achieving arbitrary command execution as the worker account. Additionally, the download_attachments_on_load setting, which controls inline attachment rendering, was modifiable through the same interface, allowing a hijacked session to re-enable a feature that could facilitate further client-side attacks. The vulnerability requires site-admin privileges and a prior session-compromise mechanism; it does not require unauthenticated access. The impact is remote code execution in the context of the MISP worker process and potential data exfiltration through the attacker-controlled Redis connection. |
| On MISP instances configured to require TOTP enrolment (Security.otp_required), the enforcement of the mandatory two-factor authentication setup applied only to standard browser requests. An authenticated user who had not yet enrolled in TOTP could bypass the forced setup by issuing any non-browser request type, including AJAX/XHR calls, REST API requests, .json format URLs, restSearch queries, or automation actions. Because these machine-readable request shapes cannot follow the redirect that the browser path uses to send the user to the TOTP enrolment page, the guard simply skipped the check and the user retained full access to the instance without completing the required second-factor setup.
The initial fix (commit 8deb0619e) added a guard specifically for AJAX requests. A follow-up fix (commit 6b527ba6e) broadened the guard to cover every non-browser request shape, while preserving the exemption for identities authenticated via API key (logged_by_authkey flag).
Impact: an authenticated user on an otp_required instance can operate with full access indefinitely without enrolling in TOTP, nullifying the instance-level two-factor authentication policy.
Affected version: <2.5.48 |
