CVE-2026-86089

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. 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 encapsulated components and referenced Controller Services, Parameter Contexts, and Parameter Providers. As a result, an authenticated user with write access could modify or remove components in descendant Process Groups protected by more restrictive access policies.

Apache NiFi 2.9.0 through 2.11.0 provide Connector configuration update and verification REST API methods that do not enforce authorization checking on Assets and Secrets referenced in the proposed configuration. An authenticated user authorized to modify a Connector but not to read a referenced Parameter Provider could apply Secret values backed by that Parameter Provider, and the methods accepted Asset identifiers without verifying ownership by the Connector being configured.

Apache NiFi 2.11.0 disabled support for gzip-encoded HTTP requests for the application REST API and rejected requests including the standard Content-Encoding header indicating gzip encoding. However, the framework enforcement filter did not check multiple instances of the Content-Encoding header or non-standard gzip encoding identifiers, allowing a malicious client to send crafted requests that could consume excessive amounts of memory.

In Apache NiFi before 0.7.2 and 1.x before 1.1.2 in a cluster environment, if an anonymous user request is replicated to another node, the originating node identity is used rather than the 'anonymous' user.

Apache NiFi versions before 0.7.4 and 1.x before 1.3.0 do not set the response header that tells browsers to only allow framing with the same origin.

Apache NiFi 2.0.0 through 2.10.0 allows creating, reading, and deleting Assets via REST API. The framework authorizes deletion based on the Parameter Context ID without verifying Asset ownership. Installations without different authorization levels across contexts are not affected. Upgrade to 2.11.0 fixes the issue.

Apache NiFi versions 1.10.0 through 2.10.0 provide a Parameter Context update REST API method that does not enforce authorization checking on components referencing Parameter values. An authenticated user authorized to modify a Parameter Context but not authorized on referencing components can alter Parameter values affecting those components. If a Parameter value contains executable scripting content, updating a Parameter can result in code execution during automatic component validation. The issue applies only to deployments using component-level authorization policies. Upgrade to Apache NiFi 2.11.0 is recommended.

In Apache NiFi before 0.7.2 and 1.x before 1.1.2 in a cluster environment, the proxy chain serialization/deserialization is vulnerable to an injection attack where a carefully crafted username could impersonate another user.

Apache NiFi 1.5.0 through 2.10.0 support gzip-encoded HTTP requests for the application REST API using a Jersey encoding filter. The framework enforced a configurable maximum request size on the compressed payload rather than the decompressed output, allowing a malicious client to send crafted requests that could consume excessive amounts of memory.

Authorization handling for Parameter Context validation requests in Apache NiFi 1.10.0 through 2.10.0 allows clients with read access to submit proposed Parameter values. The proposed values override current configuration, enabling users with read access to invoke predefined component validation methods with alternative settings. Apache NiFi installations that do not implement different levels of authorization for viewing and modifying Parameter Context configuration are not subject to this vulnerability.