Overview 14 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
14matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
14
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
14
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
14
100.0%
split by
peak 4 / year
20172
No exploit published2
High2
not blocked2
No public exploit2
20183
No exploit published3
High3
not blocked3
No public exploit3
20191
No exploit published1
High1
not blocked1
No public exploit1
20204
No exploit published4
High4
not blocked4
No public exploit4
20210
20220
20231
No exploit published1
High1
not blocked1
No public exploit1
20240
20250
20263
No exploit published3
High3
not blocked3
No public exploit3
2017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-44914 | High | 2026-06-22 | No exploit published | No public exploit | Apache NiFi 1.12.0 through 2.9.0 are missing authorization when replacing Process Groups that include extension components with specific Required Permissions based on the Restricted annotation. The Restricted annotation indicates additional privileges required, but framework authorization did not check restricted status when handling requests to replace Process Groups. The missing authorization permits a user with general write access to add components with Restricted status. Apache NiFi installations that do not implement specific authorization for Restricted components are not subject to this vulnerability because the framework enforces write permissions as the security boundary. Upgrading to Apache NiFi 2.9.0 is the recommended mitigation, which removes the implementation of Restricted status authorization from the framework. |
| CVE-2026-39816 | High | 2026-05-08 | No exploit published | No public exploit | The optional extension component TinkerpopClientService is missing the Restricted annotation with the Execute Code Required Permission in Apache NiFi 2.0.0-M1 through 2.8.0. The TinkerpopClientService supports configuration of ByteCode Submission for the Script Submission Type, enabling Groovy Script execution in the service prior to submitting the query. The missing Restricted annotation allows users without the Execute Code Permission to configure the Service in installations that use fine-grained authorization and have the optional TinkerpopClientService installed. Apache NiFi installations that do not have the nifi-other-graph-services-nar installed are not subject to this vulnerability. Upgrading to Apache NiFi 2.9.0 is the recommended mitigation. |
| CVE-2026-25903 | High | 2026-02-17 | No exploit published | No public exploit | Apache NiFi 1.1.0 through 2.7.2 are missing authorization when updating configuration properties on extension components that have specific Required Permissions based on the Restricted annotation. The Restricted annotation indicates additional privileges required to add the annotated component to the flow configuration, but framework authorization did not check restricted status when updating a component previously added. The missing authorization requires a more privileged user to add a restricted component to the flow configuration, but permits a less privileged user to make property configuration changes. Apache NiFi installations that do not implement different levels of authorization for Restricted components are not subject to this vulnerability because the framework enforces write permissions as the security boundary. Upgrading to Apache NiFi 2.8.0 is the recommended mitigation. |
| CVE-2023-49145 | High | 2023-11-27 | No exploit published | No public exploit | Apache NiFi 0.7.0 through 1.23.2 include the JoltTransformJSON Processor, which provides an advanced configuration user interface that is vulnerable to DOM-based cross-site scripting. If an authenticated user, who is authorized to configure a JoltTransformJSON Processor, visits a crafted URL, then arbitrary JavaScript code can be executed within the session context of the authenticated user. Upgrading to Apache NiFi 1.24.0 or 2.0.0-M1 is the recommended mitigation. |
| CVE-2020-9491 | High | 2020-10-01 | No exploit published | No public exploit | In Apache NiFi 1.2.0 to 1.11.4, the NiFi UI and API were protected by mandating TLS v1.2, as well as listening connections established by processors like ListenHTTP, HandleHttpRequest, etc. However intracluster communication such as cluster request replication, Site-to-Site, and load balanced queues continued to support TLS v1.0 or v1.1. |
| CVE-2020-9487 | High | 2020-10-01 | No exploit published | No public exploit | In Apache NiFi 1.0.0 to 1.11.4, the NiFi download token (one-time password) mechanism used a fixed cache size and did not authenticate a request to create a download token, only when attempting to use the token to access the content. An unauthenticated user could repeatedly request download tokens, preventing legitimate users from requesting download tokens. |
| CVE-2020-9486 | High | 2020-10-01 | No exploit published | No public exploit | In Apache NiFi 1.10.0 to 1.11.4, the NiFi stateless execution engine produced log output which included sensitive property values. When a flow was triggered, the flow definition configuration JSON was printed, potentially containing sensitive values in plaintext. |
| CVE-2020-1942 | High | 2020-02-11 | No exploit published | No public exploit | In Apache NiFi 0.0.1 to 1.11.0, the flow fingerprint factory generated flow fingerprints which included sensitive property descriptor values. In the event a node attempted to join a cluster and the cluster flow was not inheritable, the flow fingerprint of both the cluster and local flow was printed, potentially containing sensitive values in plaintext. |
| CVE-2019-12421 | High | 2019-11-19 | No exploit published | No public exploit | When using an authentication mechanism other than PKI, when the user clicks Log Out in NiFi versions 1.0.0 to 1.9.2, NiFi invalidates the authentication token on the client side but not on the server side. This permits the user's client-side token to be used for up to 12 hours after logging out to make API requests to NiFi. |
| CVE-2018-17195 | High | 2018-12-19 | No exploit published | No public exploit | The template upload API endpoint accepted requests from different domain when sent in conjunction with ARP spoofing + man in the middle (MiTM) attack, resulting in a CSRF attack. The required attack vector is complex, requiring a scenario with client certificate authentication, same subnet access, and injecting malicious code into an unprotected (plaintext HTTP) website which the targeted user later visits, but the possible damage warranted a Severe severity level. Mitigation: The fix to apply Cross-Origin Resource Sharing (CORS) policy request filtering was applied on the Apache NiFi 1.8.0 release. Users running a prior 1.x release should upgrade to the appropriate release. |
| CVE-2018-17194 | High | 2018-12-19 | No exploit published | No public exploit | When a client request to a cluster node was replicated to other nodes in the cluster for verification, the Content-Length was forwarded. On a DELETE request, the body was ignored, but if the initial request had a Content-Length value other than 0, the receiving nodes would wait for the body and eventually timeout. Mitigation: The fix to check DELETE requests and overwrite non-zero Content-Length header values was applied on the Apache NiFi 1.8.0 release. Users running a prior 1.x release should upgrade to the appropriate release. |
| CVE-2017-12632 | High | 2018-01-23 | No exploit published | No public exploit | A malicious host header in an incoming HTTP request could cause NiFi to load resources from an external server. The fix to sanitize host headers and compare to a controlled whitelist was applied on the Apache NiFi 1.5.0 release. Users running a prior 1.x release should upgrade to the appropriate release. |
| CVE-2017-5635 | High | 2017-10-19 | No exploit published | No public exploit | 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. |
| CVE-2017-7667 | High | 2017-06-12 | No exploit published | No public exploit | Apache NiFi before 0.7.4 and 1.x before 1.3.0 need to establish the response header telling browsers to only allow framing with the same origin. |