Apache NiFi CVE-2026-68979

Three conditions must all be present for exploitation: (1) The attacker must hold an authenticated NiFi user account with write privileges specifically on the target Parameter Context. (2) The NiFi deployment must have component-level authorization policies enabled - single-tenant or all-admin deployments without granular component policies are not exposed to the authorization bypass because the privilege boundary the vulnerability exploits does not exist in those configurations. (3) At least one stopped processor referencing the target Parameter Context must evaluate parameter values as executable scripting content (e.g., a Groovy or Python scripting processor). The impact is explicitly constrained to stopped components by NiFi's existing verification checks - running components are not affected. The net limiting factors are: authentication required, non-default multi-tenant authorization model required, scripting-capable processor required, and attacker's target components must be in a stopped state.

No vendor-provided CVSS vector or NVD score is available for this CVE; the vendor classified severity as Medium. EPSS data and CISA KEV status are both absent from available intelligence. The vulnerability requires an authenticated session with explicit write privilege on a Parameter Context, ruling out unauthenticated exploitation entirely. The worst-case impact - arbitrary code execution - is conditional on two non-default deployment conditions: the NiFi instance must have component-level authorization policies enabled, and at least one stopped processor referencing the targeted Parameter Context must evaluate the parameter as executable scripting content. Existing NiFi verification checks constrain the impact strictly to stopped components; running processors are not affected. The combination of authentication requirement, conditional deployment prerequisites, and scope limited to stopped components substantially narrows real-world exploitability relative to what a code-execution headline implies. This is a meaningful intra-platform privilege escalation risk for multi-tenant NiFi environments with scripting processors, but organizations without component-level authorization policies are unaffected by the authorization bypass entirely and face only parameter value tampering risk.

An authenticated NiFi user holding write access to a Parameter Context, but lacking authorization on a stopped scripting processor that references it, submits a crafted REST API PUT request updating a parameter value to inject malicious script content. NiFi's automatic component validation on the stopped processor then evaluates the injected script within the NiFi server process, achieving code execution without the attacker ever starting the processor or obtaining direct authorization to it.