CVE-2026-86419: MISP Platform SSRF Vulnerability

CVE-2026-86419 Overview

CVE-2026-86419 affects MISP (Malware Information Sharing Platform) versions ≤2.5.45. The vulnerability stems from insufficient validation of server-side outbound HTTP destinations in feed retrieval and TAXII discovery functionality. Attackers with high privileges can leverage unsafe redirect handling to trigger Server-Side Request Forgery (SSRF), reach internal network resources, and forward configured feed credentials to attacker-controlled hosts. The TAXII discovery endpoint contains a related incomplete SSRF defense that fails to block IPv6 loopback (::1), numeric host encodings such as 0x7f000001, and hosts resolving to multiple DNS records. The weakness is classified under [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor].

Critical Impact
Authenticated attackers can exfiltrate feed API credentials to arbitrary hosts and reach internal-only services via SSRF using DNS rebinding and alternate-address encodings.

Affected Products

MISP versions ≤2.5.45
MISP feed retrieval subsystem (app/Lib/Tools/CurlClient.php)
MISP TAXII discovery endpoint (app/Controller/TaxiiServersController.php)

Discovery Timeline

2026-09-07 - CVE-2026-86419 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86419

Vulnerability Analysis

The vulnerability spans two distinct MISP components with related SSRF and credential-leak weaknesses. In feed processing, the HTTP client followed redirects without validating the redirect scheme or destination. Original request headers, including authentication headers and API credentials, were reused across redirect hops. A malicious or compromised feed source could redirect MISP to an attacker-controlled host and receive the forwarded credentials. Redirects could also target internal network resources such as cloud metadata services, enabling SSRF.

The TAXII discovery endpoint applied a hand-rolled SSRF check that used gethostbyname() and compared the result against only three literal addresses (127.x, 169.254.169.254, 0.0.0.0). This approach missed IPv6 loopback ([::1]), numeric host encodings such as 0x7f000001 that curl resolves to 127.0.0.1, and DNS names returning multiple A records where only the first was checked.

Root Cause

The root cause is inconsistent and incomplete outbound URL validation. Redirect handling in CurlClient delegated to curl's built-in follower, which re-resolves each hop and bypasses any pin on the original host. The TAXII controller performed a naive string comparison against a small denylist rather than parsing the address into a canonical form and evaluating it against RFC1918, loopback, and link-local ranges.

Attack Vector

An authenticated site administrator adding a feed or performing TAXII discovery can be tricked into pointing MISP at a URL under attacker influence. The attacker returns an HTTP redirect (or configures DNS to answer with a private address on a second lookup) to steer MISP toward internal services or an external credential collector. Because credentials configured for the original feed are forwarded across hosts, the attacker recovers the API token in the resulting request.

php

// Patch: TAXII discovery moved to shared UrlEgressValidator
// Source: https://github.com/MISP/MISP/commit/06f541dcf
} else {
    $discovery_url = $this->request->data['discovery_url'];

    // Scheme, host and resolved address are checked by the shared
    // validator. POLICY_DENY_LOOPBACK keeps this action's existing
    // intent - loopback and cloud metadata refused, RFC1918 left
    // reachable, because a TAXII server on an internal host is an
    // ordinary site-admin deployment rather than an attack.
    //
    // The check it replaces resolved with gethostbyname and compared
    // against three literal values, so it refused 127.x, exactly
    // 169.254.169.254 and 0.0.0.0 and nothing else. It missed IPv6
    // entirely - [::1] walked straight through - took only the first
    // A record of a multi-record name, and let numeric host encodings
    // such as 0x7f000001 past, which curl resolves to 127.0.0.1.
    App::uses('UrlEgressValidator', 'Tools');
    try {
        UrlEgressValidator::validate($discovery_url, UrlEgressValidator::POLICY_DENY_LOOPBACK);
    } catch (InvalidArgumentException $e) {
        return $this->RestResponse->saveFailResponse(
            'TaxiiServers', 'getRoot', null, $e->getMessage(), $this->response->type()
        );
    }

php

// Patch: CurlClient redirect validator hook
// Source: https://github.com/MISP/MISP/commit/08d6efe24
/**
 * Called as ($fromUrl, $toUrl, $client) before each redirect is taken.
 * Returning false or throwing refuses the hop. When set, curl's own
 * following is turned off and redirects are driven here instead, because
 * curl resolves a redirect target fresh and a pin on the original host
 * does not constrain it.
 * @var callable|null
 */
private $redirectValidator;

Detection Methods for CVE-2026-86419

Indicators of Compromise

Outbound HTTP requests from MISP servers to internal RFC1918 ranges, 127.0.0.0/8, 169.254.169.254, or IPv6 ::1 that originate from the feed fetch or TAXII discovery workflows.
Feed configurations pointing to URLs that return 3xx redirects to hosts outside the originally configured domain.
MISP audit log entries showing feed creation or TAXII discovery calls followed by anomalous outbound connections.

Detection Strategies

Inspect web proxy and firewall logs for MISP-originated requests to cloud metadata endpoints or internal-only services.
Correlate MISP application logs with network telemetry to identify redirect chains that cross host boundaries.
Alert on any egress from MISP to hosts using numeric-encoded IP literals (hex, octal, decimal-dword) in the URL.

Monitoring Recommendations

Ingest MISP application, curl, and reverse-proxy logs into a centralized SIEM for cross-source correlation of feed and TAXII activity.
Baseline expected feed destinations and alert on new or redirected hosts contacted by the MISP fetch subsystem.
Monitor for repeated DNS resolutions of the same feed hostname that return differing answers, which may indicate DNS rebinding.

How to Mitigate CVE-2026-86419

Immediate Actions Required

Upgrade MISP to a release that includes commits 06f541dcf and 08d6efe24 from the MISP GitHub repository.
Audit configured feeds and TAXII servers for unexpected or attacker-controlled URLs and rotate any API credentials that may have been forwarded via redirects.
Restrict outbound network access from the MISP server to only the hosts and ports required for legitimate feed and TAXII sources.

Patch Information

The fixes are delivered in two upstream commits. Commit 06f541dcf moves the TAXII discovery check to the shared UrlEgressValidator with POLICY_DENY_LOOPBACK. Commit 08d6efe24 adds a redirect validator to CurlClient, disables curl's native redirect following, blocks internal destinations for cross-host redirects, strips feed credentials before following cross-host redirects, and pins validated DNS results to prevent re-resolution.

Workarounds

Place MISP behind an egress proxy that denies traffic to RFC1918, loopback, and link-local ranges including IPv6 ::1 and cloud metadata addresses.
Disable or tightly restrict feed and TAXII discovery functionality until the patched version is deployed.
Enforce DNS resolution through a controlled resolver that rejects responses containing private-range addresses for external feed hostnames.

bash

# Example: iptables rules to block MISP egress to internal ranges and cloud metadata
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.169.254 -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner www-data -d ::1 -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner www-data -d fe80::/10 -j REJECT