OSSEVA FOR APACHE NIFI
NiFi 2.0 moved on. Your 1.x flows could not.
Apache NiFi development has moved entirely to the 2.x line — 2.12.0 shipped 13 September 2026. The 1.x line ended at 1.28.1 and receives no further releases. NiFi 2.0 requires Java 21 and dropped dozens of processors, so the upgrade is a flow rebuild rather than a version bump.
Last reviewed
Trusted globally by enterprises
Why now
The 1.x line has stopped
NiFi 1.28.1 was the end of the 1.x series. All development, all fixes and every release since have gone to 2.x. There is no 1.x maintenance branch receiving security patches, and there will not be one — which leaves every production 1.x canvas permanently exposed to anything disclosed from here on.
NiFi 2.0 removed processors that live in production flows
The 2.0 release raised the Java baseline to 21 and removed a substantial set of deprecated processors, controller services and reporting tasks. Flows built over years against those components do not import cleanly. The upgrade is a rebuild-and-revalidate exercise against real data, scheduled around whatever those flows feed.
NiFi holds credentials for everything it connects to
A NiFi instance stores database passwords, cloud keys, SFTP credentials and API tokens in its parameter contexts and controller services, and routes regulated data between them. Authentication and authorisation advisories in NiFi are not confined to NiFi — they reach every system in the canvas.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 1.19.x(1.x line ended — OSSeva patched) | EOL | Clean |
| 1.23.x(1.x line ended — OSSeva patched) | EOL | Clean |
| 1.26.x(1.x line ended — OSSeva patched) | EOL | Clean |
| 1.28.x(Final 1.x release — OSSeva patched) | EOL | Clean |
| 2.x(Upstream maintained) | Current | Clean |
What you get
Three tiers — pick the level of engagement that matches your team's operational needs and compliance requirements.
OSSeva Patch
CVE patches for NiFi 1.x with the canvas untouched.
- Security backports across the 1.x line, flows unchanged
- Authentication, authorisation and policy advisory coverage
- Bundled NAR dependency patching (Jetty, Jackson, Netty)
- Docker / tarball delivery
- Signed artifacts (GPG)
- Flow inventory and 2.x migration assessment
- 24/7 managed operations
OSSeva Assure
Patch plus a processor inventory mapped against what 2.x removed.
- Everything in Patch
- Full processor and controller service inventory
- Removed-component gap analysis against NiFi 2.x
- Parameter context and credential handling audit
- SOC 2 / HIPAA attestation package
- Costed flow migration plan to 2.x
- 24/7 managed operations
OSSeva Operate
Full MSP: 24/7 dataflow monitoring, 15-min SLA, named NiFi engineers.
- Everything in Assure
- 24/7 queue backpressure and flow throughput monitoring
- 15-minute P1 incident response SLA
- Named senior NiFi engineer
- Content and provenance repository management
- Flow migration execution to NiFi 2.x
- Quarterly dataflow and capacity reviews
All tiers priced per cluster/application — not per core. Contact for pricing →
How it installs
OSSeva artifacts arrive via your existing package infrastructure. Pull the patched version the same way you pull upstream today — just from the OSSeva registry.
# Version of a running instance
curl -s -k https://nifi:8443/nifi-api/system-diagnostics \
| jq '.systemDiagnostics.aggregateSnapshot.versionInfo'
# Every processor type on the canvas — the 2.x gap analysis starts here
curl -s -k https://nifi:8443/nifi-api/process-groups/root/processors \
| jq -r '.processors[].component.type' | sort | uniq -c | sort -rn# Same flow.xml.gz, same NARs, patched dependencies
docker pull artifacts.osseva.io/nifi:1.28.1-osseva-1
docker run -d --name nifi \
-p 8443:8443 \
-v /opt/nifi/conf:/opt/nifi/nifi-current/conf \
-v /opt/nifi/state:/opt/nifi/nifi-current/state \
artifacts.osseva.io/nifi:1.28.1-osseva-1Migrate from Unsupported NiFi 1.x deployments
OSSeva patches the 1.x line in place so the existing canvas, NARs and parameter contexts keep working exactly as configured. The move to 2.x is then scoped from a real processor inventory — including which removed components need replacements built — rather than discovered halfway through a migration window.
Pricing model
OSSeva for Apache NiFi is priced per cluster — not per flow, processor or volume of data moved.
Frequently asked questions
Who provides Apache NiFi enterprise support?
OSSeva provides enterprise support for Apache NiFi today, including the 1.x line upstream no longer patches. Patch ships signed 1.x builds with backported CVE fixes, covering bundled dependencies such as Jetty 9.4 and Spring Framework 5.3 that the NiFi project says cannot be upgraded on 1.x. Assure adds compliance attestation and VEX statements. Operate adds 24/7 managed operations with a 15-minute P1 response.
How do you upgrade NiFi 1.x to 2.0?
In stages. NiFi's migration guidance requires upgrading to 1.27.0 before moving to 2.0.0. NiFi 2 requires Java 21, removes the components deprecated in 1.x, and needs nifi.flow.configuration.file changed to point at flow.json.gz instead of flow.xml.gz. Replace removed processors and controller services while still on 1.27 or 1.28, then move the flow.
Is Apache NiFi 1.x still supported?
No. Apache NiFi 1.28 is the last minor release of the 1.x series, and the NiFi download page gives its end of support as 8 December 2024. The final release, 1.28.1, shipped on 19 November 2024. The project says any exceptional 1.x fix will not include dependency upgrades. The current line is 2.x, and NiFi 2.12.0 was released on 13 September 2026.
Why can't we just upgrade to NiFi 2.x?
Because 2.0 was a deliberate clean break. It raised the Java baseline to 21 and removed a large set of deprecated processors, controller services and reporting tasks. Flows built against those components do not import cleanly, so the upgrade means rebuilding parts of the canvas and revalidating the output against real data — work that has to be scheduled around whatever those flows feed.
Does patching NiFi require rebuilding our flows?
No. OSSeva ships patched builds on the 1.x line you already run, so flow.xml.gz, the NAR set, parameter contexts and controller services all stay as configured. The canvas is untouched; only the underlying binaries change.
Where do most NiFi vulnerabilities actually come from?
Two places. The first is NiFi's own authentication, authorisation and policy handling, which matters because NiFi holds credentials for every system in the canvas. The second, and more frequent, is the third-party libraries bundled inside the NARs — Jetty, Jackson, Netty and their dependencies. OSSeva patches both.
We run NiFi in a Cloudera distribution. Does that change coverage?
It changes what you are entitled to upstream, not what is running. Cloudera Flow Management packages NiFi with its own support lifecycle, and estates frequently hold versions that are behind both the Cloudera and Apache lines. OSSeva covers the NiFi binaries you actually run, Apache or Cloudera-packaged, matched to the exact version rather than the badge.
Ready to get Apache NiFi patched and supported?
Start with a 45-minute discovery call. We confirm your version coverage, scope the engagement, and have you onboarded within your first quarter.