Apache NiFi EUVD-2026-38216

The vulnerability is exploitable on any Apache NiFi 0.0.1-2.9.0 instance reachable over the network where an upstream reverse proxy does not strip or validate the X-ProxyHost or X-Forwarded-Host headers before forwarding requests to NiFi. No special NiFi configuration is required to be vulnerable - the absence of proxy header validation is the default behavior across all affected versions. No authentication is required to supply HTTP request headers; the attack can be performed at the pre-authentication stage (e.g., during login redirect construction). Factors that limit exploitation: (1) a reverse proxy that filters proxy host headers eliminates the attack surface; (2) NiFi instances not directly reachable by untrusted clients (e.g., internal-only deployments with network controls) face reduced exposure; (3) nifi.web.proxy.host must be populated in NiFi 2.10.0 for the fix to enforce allowlisting - leaving this property unconfigured post-upgrade may not fully mitigate the issue; (4) exploitation requires the application to process a URL-construction code path that reads the malicious header, meaning deeply buried API calls not involving redirect or link generation may not be affected.

No official CVSS score, EPSS probability, or SSVC decision data has been published for CVE-2026-54665 at time of analysis, so risk must be assessed from first principles. The attack is network-reachable with low complexity - crafting an HTTP header requires no special tooling - and no prior authentication is necessary to influence URL construction (pre-auth redirect flows are a common exploitation path for host header injection). CVE-2026-54665 is not listed in CISA KEV and no public POC has been identified, indicating no confirmed active exploitation. The practical impact is constrained: the vulnerability enables open-redirect manipulation and malformed data references rather than arbitrary code execution, data exfiltration, or denial of service. Organizations that already place a hardened reverse proxy (nginx, HAProxy, AWS ALB) in front of NiFi - as is standard for production deployments - and configure that proxy to strip or allowlist proxy host headers are effectively protected without any NiFi-side change. Direct internet exposure of NiFi's web port without a reverse proxy would represent the highest-risk deployment posture. Overall, this is a moderate-severity issue that warrants patching on a normal cycle rather than emergency response, unless the NiFi instance is directly internet-exposed.

An attacker with network access to NiFi's web interface sends a crafted HTTP request containing a malicious value in the X-Forwarded-Host header (e.g., X-Forwarded-Host: attacker.example.com). NiFi accepts the unvalidated value and constructs a qualified redirect URL pointing to the attacker's domain, which is then returned in an HTTP Location header during a login or OAuth callback flow. A user following the poisoned redirect is sent to the attacker-controlled host, enabling credential harvesting or session token theft. No public POC code has been identified; the attack requires only standard HTTP client tooling.