MISP Feed Redirects Before 2.5.45: When an Outbound Request Carries Credentials to Another Host

A platform whose job is to fetch from the internet

MISP collects indicators from feeds, synchronises with other instances and resolves remote TAXII services. Fetching is not an optional feature; it is the core function. That makes MISP's outbound request path a security boundary in its own right, separate from the web interface that analysts use.

What the advisory describes

CVE-2026-86419 affects MISP versions up to and including 2.5.45. Two related weaknesses sit in the same outbound path.

In feed processing, redirects were followed without validating the redirect scheme or the destination. The original request headers were reused across each hop. Any authentication header or API credential configured for a feed could therefore be forwarded to a host the operator never intended to reach. Redirects could also target internal network resources, which turns the feature into a server-side request forgery primitive. NVD records a CVSS 3.1 base score of 9.1.

The TAXII discovery endpoint had a related gap. It resolved the host with gethostbyname() and compared the result against a short list of literal addresses. That check missed IPv6 loopback (::1), numeric host encodings such as 0x7f000001, and situations where a name resolves to several records. The fix moves TAXII discovery onto the same URL egress validator used elsewhere.

A second MISP advisory in the same period, CVE-2026-86452, concerns the unauthenticated password-reset and API-access email endpoints. An unbounded, unvalidated email value was stored more than once per request with no throttling. The fix adds a 1024-byte input limit, email-format validation, a per-source pre-authentication request budget, HTTP 429 responses when that budget is exceeded, and a 15-minute cooldown for API-access request emails.

Both issues concern input validation on a path where the application is expected to perform work. Neither is a memory-safety problem.

Why fix validation belongs in one place

The MISP fixes share a design decision worth copying. Rather than patching each caller, the project moved the checks into a shared validator and pinned validated DNS results so a name cannot be re-resolved after validation. That closes the time-of-check to time-of-use gap that makes hostname blocklists unreliable in practice.

Blocklists of literal addresses fail against alternate representations. A validator that resolves a name once, records the result, restricts the connection to that result and refuses cross-host redirects is the structure that survives new encodings.

Defensive implications

Update to a MISP release after 2.5.45 in the relevant branch. Confirm the outbound path change is present, because the fix is behavioural rather than a configuration flag.

Then restrict what the MISP host can reach. Even a correct validator benefits from network enforcement: an egress policy that allows the feed hosts MISP actually uses and denies everything else turns a validation bypass into an unreachable destination. Where the deployment runs in a cloud environment, the instance metadata endpoint should be blocked by policy rather than by application code alone.

Rotate the credentials that were configured on any feed or TAXII service, on the assumption that a cross-host redirect may have carried them.

Finally, watch the outbound logs. A feed request that follows a redirect to an address the operator does not recognise is the event worth alerting on, and it is visible from a proxy log without any application instrumentation.

References

• MISP commit 08d6efe, stop feed redirects leaking credentials and reaching internal hosts.
• MISP commit 06f541d, put the TAXII discovery check on the shared validator.
• MISP commit d75d899, bound and throttle the unauthenticated mail endpoints.
• NVD records for CVE-2026-86419 and CVE-2026-86452.