Apache NiFi CVE-2026-62354

Exploitation requires a valid NiFi account with at least read-level access to Parameter Contexts (PR:L per CVSS 4.0) - unauthenticated exploitation is not possible. The critical limiting condition is deployment architecture: the vulnerability only affects NiFi instances that implement differentiated authorization for Parameter Context configuration, meaning distinct read and write permission tiers exist and some users hold read access without write access. NiFi installations where all users have uniform access to Parameter Contexts (no split permissions) are explicitly excluded by the vendor. The attack is network-accessible (AV:N) and requires no user interaction (UI:N). Exploitation is additionally bounded by the AT:P condition - the specific role and permission configuration must be in place. Organizations should audit their NiFi authorization model to determine whether split Parameter Context permissions are in use before assessing risk.

The CVSS 4.0 score of 7.7 with VC:H/VI:H/VA:H indicates high potential impact across all three CIA dimensions on the vulnerable system, though SC:N/SI:N/SA:N confirms no lateral impact to subsequent systems. PR:L rules out unauthenticated exploitation - an authenticated foothold is a prerequisite. AT:P introduces a meaningful deployment-condition gate: only NiFi instances with a split read/write authorization model for Parameter Contexts are in scope, which substantially reduces the real-world attack surface below what raw CVSS numbers suggest. The supplemental metric AU:Y (Automatable: Yes) is a notable risk amplifier, indicating exploitation can be scripted once conditions are met. V:C (Value Density: Concentrated) suggests high-value targets. No EPSS score was provided in the intelligence data, preventing probabilistic comparison. No CISA KEV listing and no POC were identified, indicating no confirmed active exploitation at time of analysis. The practical priority for most organizations hinges entirely on whether their NiFi deployment uses differentiated authorization - those that do should treat this as urgent; those that do not are not affected.

An authenticated NiFi user holding only read access to Parameter Contexts crafts an HTTP request to the NiFi REST API Parameter Context validation endpoint, embedding modified parameter values as proposed overrides. The server accepts the request without checking for write authorization, processes the attacker-supplied values, and invokes component validation methods using those alternative settings - potentially returning sensitive configuration details or triggering disruption to active data flows. No public POC has been identified, but the AU:Y metric indicates this process is straightforward to automate once an attacker understands the API structure.