CVE-2026-86351 in MISP
Summary
by MITRE • 09/07/2026
Affected versions of MISP validate the user-configurable homepage by checking only whether the supplied path begins with /. That check is insufficient because protocol-relative URLs such as //attacker.example also begin with / but resolve to an external origin in browsers.
The vulnerable homepage value can be stored as a user setting and later used by the post-login routing logic. The commit explicitly identifies //attacker.example as a payload that passed validation and was emitted to the Location header after login.
The fix introduces a shared InternalRedirectValidator that rejects URLs containing a host, scheme, userinfo, unsafe leading // or /\, malformed URLs, and control characters. It also revalidates homepage settings on read so legacy or internally written unsafe values cannot bypass the new storage-time validation.
Version affected: ≤2.5.45
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability in versions of MISP up to 2.5.45 represents a critical Open Redirect flaw rooted in insufficient input validation within the user configuration module. The application previously validated the homepage setting by checking only if the supplied path began with a forward slash character. This logic is fundamentally flawed because it fails to distinguish between relative paths that remain within the same origin and absolute URLs or protocol-relative URLs that point to external domains. Specifically, an attacker can supply a value such as //attacker.example which technically begins with / but resolves in web browsers to https://attacker.example due to standard URL parsing rules where double slashes indicate a scheme-less host specification. This oversight allows the application to accept and store malicious redirect targets under the guise of legitimate configuration data.
The operational impact is significant because this vulnerable homepage value is not merely displayed statically but is actively used by the post-login routing logic. After a user authenticates, MISP utilizes the stored homepage setting to determine where to direct the user session. If an attacker can manipulate their own account settings or potentially influence shared configurations depending on deployment specifics, they can cause the application to emit a Location header pointing to an external domain upon successful login. This mechanism facilitates phishing attacks by redirecting authenticated users away from the legitimate MISP instance to a malicious site that may mimic the interface or request sensitive credentials and session tokens. The attack vector is particularly effective because it leverages the trust relationship established during authentication, making the redirection appear as a standard part of the user experience rather than an obvious error page.
From a technical standards perspective, this vulnerability aligns with CWE-601, which describes URL Redirection to Untrusted Site (Open Redirect). The flaw arises from relying on superficial string matching rather than robust parsing logic that validates the structural integrity and origin of the target URI. Furthermore, in the context of cyber attack frameworks such as MITRE ATT&CK, this behavior can be categorized under T1566.002, which covers Spearphishing Link attacks where a link is used to direct victims to malicious content. The ability to control the redirect destination post-authentication amplifies the risk by bypassing initial phishing filters that might otherwise flag suspicious links in emails or messages, as the redirection occurs within the trusted context of an already authenticated session.
The remediation strategy implemented in subsequent versions addresses these issues through a comprehensive overhaul of URL validation logic. The fix introduces a shared InternalRedirectValidator component designed to enforce strict security constraints on all redirect targets. This validator explicitly rejects URLs that contain a host, scheme, userinfo components, or unsafe leading sequences such as double slashes // or backslashes \/. It also guards against malformed URLs and control characters that could be used for obfuscation or injection attacks. By rejecting these patterns at the validation layer, the application ensures that only truly relative paths within the same origin are permitted for redirection purposes.
Additionally, the fix includes a critical defensive measure regarding data persistence and retrieval. The system now revalidates homepage settings upon read operations to ensure that legacy values stored in the database prior to the patch cannot bypass the new security controls. This approach prevents attackers from exploiting previously saved unsafe configurations by ensuring that every access point for redirect logic applies consistent validation rules regardless of when the data was originally entered. Organizations running affected versions must upgrade immediately and verify that no custom scripts or integrations are relying on the previous permissive behavior, as this change may break functionality if external redirects were intentionally configured in older deployments.