CVE-2026-68979: 
NixOS vulnerability analysis and mitigation

CVE-2026-68979 is a Missing Authorization vulnerability in Apache NiFi's Parameter Context update REST API, allowing authenticated users to modify parameter values on components they are not authorized to access. It affects Apache NiFi versions 1.10.0 through 2.10.0 (component org.apache.nifi:nifi-web-api). The vulnerability was reported on 2026-07-22 by researcher D0HY30N and publicly disclosed on 2026-08-03 via the Apache security mailing list. It carries a CVSS v4.0 base score of 5.9 (Medium) and a CVSS v3.1 base score of 9.8 (Critical, reflecting a broader threat model) (Apache Advisory, GitHub Advisory, OSS-Sec).

The root cause is CWE-862 (Missing Authorization): the Parameter Context update REST API endpoint (PUT /parameter-contexts/{id}) enforced authorization only on the Parameter Context resource itself — checking read/write privileges on the context — but did not verify whether the requesting user had authorization on the components that reference those parameter values. An authenticated user with Parameter Context write access could therefore update parameter values consumed by processors or other components they have no direct authorization over. In deployments where parameter values contain executable scripting content (e.g., used in ExecuteScript or similar processors), the NiFi framework automatically validates components upon parameter changes, triggering script compilation or execution even on stopped components — without the attacker needing to start or interact with those components directly. The issue is tracked as NIFI-16148 and is scoped to deployments that use component-level authorization policies (Apache Advisory, OSS-Sec).

An authenticated attacker with Parameter Context modification rights can alter parameter values affecting components they are not authorized to control, potentially achieving arbitrary code execution during automatic component validation on stopped components. The confidentiality impact is limited (low per CVSS v4), but integrity impact is high, as the attacker can inject malicious scripting content into component configurations. The vulnerability is most severe in multi-tenant NiFi deployments where component-level authorization policies are used to enforce security boundaries between users or teams, as it effectively allows privilege escalation across those boundaries (Apache Advisory, GitHub Advisory).

As of the disclosure date, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (GitHub Advisory). The NVD SSVC assessment confirms exploitation status as "none" and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.35–0.52%, placing it in roughly the 42nd percentile for exploitation probability within 30 days. Exploitation requires an authenticated account with Parameter Context write privileges, limiting the attacker pool, though the attack requires no user interaction once access is obtained (GitHub Advisory, OSS-Sec).

1. Reconnaissance: Identify Apache NiFi instances running versions 1.10.0 through 2.10.0 that use component-level authorization policies. Confirm the deployment uses multi-tenant access controls where different users have different component permissions.
2. Obtain authenticated access: Acquire credentials for a NiFi user account that has read/write authorization on at least one Parameter Context, but lacks authorization on one or more components that reference parameters from that context.
3. Identify target components: Browse the NiFi UI or query the REST API to identify processors or components (e.g., ExecuteScript, ExecuteGroovyScript) that reference parameters from the accessible Parameter Context and contain or could contain executable scripting content.
4. Craft malicious parameter value: Prepare a parameter value containing executable scripting content (e.g., a Groovy or Python script payload) designed to execute a reverse shell, exfiltrate data, or perform other malicious actions when evaluated.
5. Submit Parameter Context update: Send a PUT request to the Parameter Context update REST API endpoint (e.g., PUT /nifi-api/parameter-contexts/{id}) with the crafted malicious parameter value, authenticated as the low-privilege user.
6. Trigger automatic validation: NiFi automatically validates referencing components upon parameter changes. If the target component uses the modified parameter as script content, the framework evaluates/compiles the script during validation — executing the attacker's payload — without the component needing to be started (Apache Advisory, OSS-Sec).

• Network: Unexpected or anomalous PUT requests to /nifi-api/parameter-contexts/{id} from user accounts not typically associated with Parameter Context administration; outbound connections from the NiFi server process to unknown external IPs following a parameter update.
• Logs: NiFi application logs (nifi-app.log) showing parameter context updates by users who do not own or administer the referencing components; validation events on stopped components immediately following parameter updates; script compilation or execution log entries triggered without a component start event.
• Process: Unusual child processes spawned by the NiFi JVM process (e.g., bash, sh, curl, wget, python) during component validation phases rather than during normal component execution.
• File System: Unexpected files written to the NiFi working directory or temp directories by the NiFi service account following a parameter context update; new scripts or executables created in directories accessible to the NiFi process.

The primary remediation is to upgrade to Apache NiFi 2.11.0, which adds authorization checking on components referencing updated Parameter Context values, aligning the Parameter Context update method with the authorization model used by other API methods (Apache Advisory). As a workaround for organizations unable to upgrade immediately, restrict Parameter Context write access exclusively to trusted administrators who also have full authorization over all referencing components, effectively eliminating the privilege gap. Additionally, review and audit existing component-level authorization policies to ensure no user has Parameter Context write access without corresponding component-level access to all referencing components (OSS-Sec).

The vulnerability received coverage from several cybersecurity news outlets shortly after disclosure, including GBHackers, CyberPress, CyberSecurityNews, and SecurityOnline, which highlighted the authorization bypass risk in multi-tenant NiFi deployments (GBHackers, SecurityOnline). The DailyCyberSecurity Mastodon account also noted the advisory. Community reaction was measured, with the consensus that the real-world risk is constrained by the requirement for authenticated access and component-level authorization policies being in use. The Apache NiFi project credited researcher D0HY30N for the discovery (OSS-Sec).