CVE-2026-82561: Apache NiFi: Missing Authorization for Components Referenced in Flow Update Methods
Apache NiFi 1.5.0 through 2.11.0 provide REST API methods that replace the entire contents of a Process Group using a client-supplied flow definition, covering Process Group flow replacement together with versioned flow update and rebase operations. Framework authorization for these methods was limited to read and write privileges on the Process Group itself, unlike the corresponding asynchronous update request methods, which also authorize the components encapsulated in the Process Group along with referenced Controller Services, Parameter Contexts, and Parameter Providers. As a result of the missing authorization, an authenticated user with write access to a Process Group could supply a flow definition that modifies or removes components in descendant Process Groups protected by more restrictive access policies, and could bind components to Controller Services and Parameter Contexts without authorization for those referenced components. Existing verification checks limited the impact to stopped components, and the issue applies only to deployments that use component-level authorization policies, because the framework enforces write permissions as the security boundary. Upgrading to Apache NiFi 2.12.0 is the recommended mitigation, which applies consistent reference resolution and component authorization across Process Group replacement and versioned flow update methods
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache NiFito a version that resolves this vulnerability.Fixed in 2.12.0Patch CVE-2026-82561
Event History
Frequently Asked Questions
Which deployments are affected by this authorization gap?
The issue applies only to deployments that use component-level authorization policies. The affected REST API methods are present in Apache NiFi versions 1.5.0 through 2.11.0.
What access does an attacker need?
An attacker must be authenticated and have write access to a Process Group. They can then submit a client-supplied flow definition through full Process Group replacement, versioned flow update, or rebase operations.
What actions could the attacker perform beyond their intended permissions?
They could modify or remove stopped components in descendant Process Groups that have more restrictive policies. They could also bind components to Controller Services and Parameter Contexts without authorization for those referenced resources.
Does this allow changes to running components?
Existing verification checks limit the impact to stopped components. The provided information does not indicate that the authorization gap can be used to modify running components.