MISP CVE-2026-86419: SSRF and Credential Leak in the Threat Intel Platform (≤ 2.5.45)

CVE-2026-86419 affects MISP, the open-source threat intelligence sharing platform used by a large share of CERTs, CSIRTs, SOCs and sector sharing communities. Rated CVSS 9.1, it affects all versions through 2.5.45.

What makes this CVE interesting beyond its severity is the quality of its write-up: the MISP team documented not only the flaw but every bypass its old defence let through. For anyone writing code that makes outbound requests to user-supplied URLs, it's a rare checklist.

The Vulnerability

The PR:L means an account able to configure feeds or TAXII discovery is required. The S:C (scope changed) reflects impact on systems beyond MISP: the internal network reached by SSRF, and the partners whose credentials leak.

Two Distinct Defects

1. Feed retrieval: redirects followed blindly

In feed processing, redirects were followed without validating the redirect scheme or destination. The original request headers were reused across redirect hops, meaning authentication headers or API credentials configured for a feed could be forwarded to a different host. Redirects could also target internal network resources, resulting in SSRF.

Two problems in one sentence.

The credential leak. A MISP feed is often authenticated: a partner's API key, a commercial intelligence platform token. If the feed server answered with a redirect to another host, MISP followed it resending the same headers, credentials included. So controlling — or compromising — a feed URL is enough to collect the credentials the instance presents there.

The SSRF. A redirect to http://169.254.169.254/ or to an internal service made MISP issue the request from inside the network.

2. TAXII discovery: an incomplete denylist defence

The TAXII discovery endpoint had a related incomplete SSRF defense. It used gethostbyname() and compared the result against only a few literal addresses. This missed cases including IPv6 loopback (::1), numeric host encodings such as 0x7f000001, and potentially multiple DNS records.

This is the most instructive part. There was a protection — it didn't hold, and the description lists exactly why:

All three share one root: comparing against a list of forbidden addresses written as literals instead of classifying the resolved address by network range.

What the Fix Says — and Why It's Worth Reading

The description details the changes:

The fix adds redirect validation, blocks internal destinations for cross-host redirects, strips configured feed credentials before following redirects to another host, and pins validated DNS results to prevent re-resolution after validation. [...] The fix moves TAXII discovery to the shared URL egress validator.

Each point maps to a general rule:

1. Validate every redirect hop, not only the initial URL
2. Strip credentials as soon as a redirect changes host — that's the default behaviour of browsers, not of every HTTP library
3. Pin the validated DNS result: otherwise an attacker controlling their DNS answers a public address at check time and an internal one at connect time (DNS rebinding)
4. One shared validator for all outbound requests, instead of a protection reimplemented differently in each place

That last point is the one that prevents the next flaw. The TAXII defect existed precisely because a second outbound-request path had its own, weaker defence.

Why the Target Is Sensitive

A MISP instance isn't just another server:

• It holds feed credentials for partners and commercial providers
• It connects to other MISP instances in the sharing community, with sync keys
• It often sits inside the SOC network, with access to detection tooling
• It contains non-public intelligence: indicators from ongoing incidents, information shared under conditions (TLP)

A feed credential leak therefore doesn't only expose your organisation: it exposes your partners, who entrusted you with access.

Versions and Checks

NVD exposes no fixed version number: move to a release later than 2.5.45 following the MISP project's release notes.

# Instance version
cat /var/www/MISP/VERSION.json

Interface: Administration → Server Settings & Maintenance

Detection

• Feed access logs: redirect responses (301, 302, 307, 308) from feed servers that don't normally send them
• Outbound requests from the MISP server to internal addresses, 169.254.169.254, or hosts not declared as feed sources
• Feeds or TAXII servers added recently by accounts with no reason to do so
• Abnormal use of your feed keys on the partner side — ask them if you suspect a leak

Mitigation

1. Update past 2.5.45

That's the only complete fix.

2. Restrict who can configure feeds

The PR:L prerequisite is your lever: limit creating and editing feeds and TAXII connections to a small number of administrators.

3. Filter egress

The MISP server should only be able to reach declared feed sources and sync instances. Egress filtering — firewall or proxy — neutralises the SSRF independently of the code.

4. If you suspect a credential leak

Rotate every feed and sync key, and notify the affected partners. It's a trust obligation toward the sharing community as much as a technical measure.

Why Continuous Monitoring of Security Tooling Matters

Security platforms — MISP, SIEM, SOAR, vulnerability management tools — are rarely treated as attack surface by the teams operating them. Yet they hold the organisation's most sensitive credentials and, in MISP's case, those of its partners.

With cveo.tech, inventory your security tools with exact versions, and get automatic alerts whenever a critical CVE affects them — including those targeting the tools meant to protect you.