CVE-2026-94404: MISP CSRF Vulnerability

CVE-2026-94404 Overview

CVE-2026-94404 is a Cross-Site Request Forgery (CSRF) vulnerability in MISP (Malware Information Sharing Platform) affecting versions prior to 2.5.47. The flaw resides in the inline attribute field edit functionality, where the editField action failed to enforce MISP's standard CSRF protection. An attacker can craft a malicious webpage that silently issues state-changing requests to a MISP instance when visited by an authenticated user. Successful exploitation permits modification of attribute values, types, categories, comments, distribution settings, and timestamps. The classification is [CWE-352] Cross-Site Request Forgery.

Critical Impact
Unauthorized modification of threat-intelligence attributes can corrupt indicators, alter sharing scope, and undermine analyst confidence in data integrity across sharing communities.

Affected Products

MISP (Malware Information Sharing Platform) versions prior to 2.5.47
AttributesController::editField endpoint in the MISP web application
Deployments exposing MISP to authenticated users who also browse the general web

Discovery Timeline

2026-09-21 - CVE-2026-94404 published to NVD
2026-09-21 - Last updated in NVD database

Technical Details for CVE-2026-94404

Vulnerability Analysis

MISP applies CSRF validation across its controllers using both a token check and a form field-hash check. The editField action in app/Controller/AttributesController.php was reached through two distinct paths: the Overmind index posted a form-encoded body from fetch() with the token in the X-CSRF-Token header, while legacy inline forms submitted a serialized CakePHP form whose field hash did not survive the AJAX submit.

Because neither path could satisfy the combined _validatePost() check, the endpoint was left without effective CSRF enforcement. An attacker-controlled page can then trigger cross-origin requests that alter attribute data using the victim's authenticated session cookies. The impact is limited to data integrity; the endpoint does not disclose confidential material or affect service availability.

Root Cause

The root cause is missing CSRF protection on the editField handler. The controller did not include editField in the header-only CSRF validation list, and the full _validatePost() path could not succeed for either the modern fetch-based submissions or the legacy serialized form submissions.

Attack Vector

Exploitation requires an authenticated MISP user to visit an attacker-controlled webpage while their browser holds a valid MISP session. The malicious page issues a cross-origin request to the vulnerable editField endpoint, mutating an attribute of the attacker's choice. No credentials, tokens, or user interaction with the MISP UI are required beyond the initial page visit.

php

         // document, which is exactly why _validatePost() can never pass:
         // Security starts up before the component that decodes it, so it sees
         // no _Token at all.
+        // editField is reached two ways, and neither can satisfy _validatePost():
+        // the Overmind index posts a form-encoded body from fetch() with the
+        // token in the X-CSRF-Token header, and the legacy inline forms post a
+        // serialised Cake form whose field hash does not survive the AJAX
+        // submit. Both carry a token - header and body respectively - so keep
+        // the CSRF check and drop only the field-hash check.
         $this->_csrfTokenHeaderOnly([
             'editAttributeTags', 'editAttributeGalaxies',
             'editAttributeTagRelationships', 'editAttributeGalaxyRelationships',
+            'editField',
         ]);
 
         // permit reuse of CSRF tokens on the search page.

Source: MISP GitHub Commit dfbae33f9. The patch adds editField to the _csrfTokenHeaderOnly list, restoring CSRF validation via the X-CSRF-Token header while dropping the field-hash check that could not succeed for AJAX submissions.

Detection Methods for CVE-2026-94404

Indicators of Compromise

Unexpected POST requests to /attributes/editField/<id> from Referer headers pointing to third-party origins
Audit log entries showing attribute modifications (value, type, category, comment, distribution, timestamps) that do not correspond to analyst activity in the MISP UI
Requests to editField missing the X-CSRF-Token header while carrying a valid session cookie

Detection Strategies

Review MISP audit_logs and Log table entries for Attributeedit actions and correlate against expected user sessions and workstations
Inspect reverse-proxy or web-server access logs for cross-origin POST requests to AttributesController endpoints, prioritizing non-browser User-Agent values and off-hours activity
Alert on anomalous bursts of single-field attribute edits from a single user within short time windows

Monitoring Recommendations

Enable and centralize MISP audit logging, forwarding events to a SIEM for correlation with browser proxy and DNS logs
Monitor changes to attribute distribution and sharing_group_id fields, since silent modifications directly affect data-sharing scope
Track outbound sync operations that propagate attribute changes to partner MISP instances after suspicious edits

How to Mitigate CVE-2026-94404

Immediate Actions Required

Upgrade MISP to version 2.5.47 or later, which restores CSRF header validation on the editField action
Instruct analysts to log out of MISP when not actively using it and to use a dedicated browser profile for MISP administration
Review audit logs for any suspicious attribute modifications since the last patch cycle and revert unauthorized changes

Patch Information

The fix is delivered in commit dfbae33f9 on the MISP repository. The change adds editField to the _csrfTokenHeaderOnly() allowlist in app/Controller/AttributesController.php, ensuring the endpoint validates the X-CSRF-Token header on every request. Refer to the MISP GitHub Commit for the full diff and upgrade to a release that includes this commit.

Workarounds

Restrict MISP access to a management VLAN or VPN so authenticated sessions cannot be abused from arbitrary web origins
Deploy a reverse proxy rule that rejects POST requests to /attributes/editField/* lacking a same-origin Referer or Origin header
Configure the MISP session cookie with SameSite=Strict where the deployment topology allows it

bash

# Example nginx rule to block cross-origin POSTs to the vulnerable endpoint
location ~ ^/attributes/editField/ {
    if ($request_method = POST) {
        set $bad_origin 1;
        if ($http_origin ~* ^https://misp\.example\.com$) { set $bad_origin 0; }
        if ($bad_origin = 1) { return 403; }
    }
    proxy_pass http://misp_backend;
}