OSSEVA FOR APACHE IGNITE
Apache Ignite support: patched 2.x, because Ignite publishes no end-of-life dates
Apache Ignite support from OSSeva keeps Ignite 2.x patched without waiting for an end-of-life date, because the Apache Ignite project publishes none. Each 2.x minor from 2.12 to 2.17 shipped a single release, and CVE-2024-52577 and CVE-2025-48977 are fixed only by moving to 2.17.0 and 2.18.0. Send your work email and an engineer replies within 1 business day.
| Who it is for | Teams running Ignite 2.8, 2.9, 2.13 or 2.16 caches, compute grids or persistent regions that are not moving to Ignite 3 |
|---|---|
| What you get | Patched builds on your 2.x line with the cache API, persistence format and client protocol unchanged. Assure adds a cluster audit, a costed Ignite 3 assessment and 24/7 reactive support. |
| How it is priced | Per cluster, not per node, cache or GB in memory. Ask for a quote. |
| What happens next | You send your work email, we confirm your version and components, and you get a coverage plan. |
Reply within 1 business day · No commitment · or book a 15-minute call
Last reviewed
Trusted globally by enterprises
Ignite 2.x releases, checked 20 October 2026
Ignite has no end-of-life policy and endoflife.date does not track it, so the useful fact is how many releases a line got. Releases are from the Apache release archive; the two advisories are from OSSeva's CVE directory.
| Minor line | Releases in the line | Affected by CVE-2024-52577 (fixed in 2.17.0) | Affected by CVE-2025-48977 (fixed in 2.18.0) |
|---|---|---|---|
| 2.8 | 2.8.0, 2.8.1 | Yes | Yes |
| 2.9 | 2.9.0, 2.9.1 | Yes | Yes |
| 2.13 | 2.13.0 | Yes | Yes |
| 2.14 | 2.14.0 | Yes | Yes |
| 2.15 | 2.15.0 | Yes | Yes |
| 2.16 | 2.16.0 | Yes | Yes |
| 2.17 | 2.17.0 | No | Yes |
| 2.18 | 2.18.0 (23 Apr 2026) | No | No |
A fix on a one-release line means moving to a newer minor. OSSeva patched builds cover 2.8, 2.9, 2.13 and 2.16.
The two advisories that decide the 2.x question
CVE-2024-52577 is a deserialization flaw that can run code on a server node. CVE-2025-48977 lets an authenticated REST API user read any file. Between them, every 2.x line except 2.18 is affected by at least one.
| CVE | Published | CVSS | Affected range (NVD) | Fixed upstream in |
|---|---|---|---|---|
| CVE-2024-52577 | 2025-02-14 | 9.0 | Apache Ignite 2.6.0 before 2.17.0 | 2.17.0 |
| CVE-2025-48977 | 2026-05-28 | 6.5 | Apache Ignite 2.0.0 through 2.17.0 | 2.18.0 |
Confirm any entry at nvd.nist.gov.
Ignite 2 to 3 migration →Hazelcast support, the other grid →
Why now
Ignite 3 is a rewrite, not a successor release
Ignite 3 replaced the storage engine, the SQL engine, the client protocol and the configuration model. Applications written against the 2.x cache and compute APIs do not port by changing a version number. That gap is why 2.x clusters are still carrying production load years into the 3.x line's existence.
Attention follows the new line, and 2.x is where the installed base is
Project energy has moved to 3.x. The 2.x series remains in extremely wide production use — in-memory caches fronting relational databases, compute grids running distributed closures, and persistent data regions holding primary copies. Widely deployed and quietly maintained is the exact combination extended support exists for.
Ignite executes arbitrary code by design
The compute grid ships user closures to nodes and runs them. Peer class loading distributes classes across the cluster automatically. These are features, not flaws — but they mean any weakness in node authentication or the discovery protocol converts directly into cluster-wide code execution, and they make an unpatched Ignite cluster a different risk profile from an unpatched cache.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 2.8.x(OSSeva patched) | EOL | Clean |
| 2.9.x(OSSeva patched) | EOL | Clean |
| 2.13.x(OSSeva patched) | EOL | Clean |
| 2.16.x(OSSeva patched) | Extended | Clean |
| 3.x(Rewritten line — upstream maintained) | Current | Clean |
Running a Apache Ignite version or build not listed here?
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 Ignite 2.x with the API and storage format unchanged.
- Security backports across the 2.x line
- Discovery, communication SPI and REST advisory coverage
- Peer class loading and deserialization hardening guidance
- Maven / Docker / tarball delivery
- Signed artifacts (GPG)
- Ignite 3 migration assessment
- 24/7 managed operations
OSSeva Assure
Patch plus cluster audit and a costed assessment of the 3.x move.
- Everything in Patch
- Baseline topology and data region configuration review
- Discovery port exposure and authentication audit
- Cache and compute API usage inventory
- SOC 2 / HIPAA attestation package
- Ignite 3 migration assessment with effort estimate
- 24/7 reactive support
OSSeva Operate
Full MSP: 24/7 cluster monitoring, 15-min SLA, named Ignite engineers.
- Everything in Assure
- 24/7 heap, off-heap and baseline topology monitoring
- 15-minute P1 incident response SLA
- Named senior Apache Ignite engineer
- Checkpointing, WAL and rebalance tuning
- Migration execution to Ignite 3 or an alternative grid
- Quarterly capacity planning reviews
All tiers priced per cluster/application — not per core.
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 and topology via the REST connector
curl -s 'http://ignite:8080/ignite?cmd=version'
curl -s 'http://ignite:8080/ignite?cmd=top&attr=true' | jq '.response | length'
# Discovery and communication ports. A node that can join the ring
# can run compute closures — these must not be broadly reachable.
nmap -p 47100,47500,10800,8080 ignite-node.internal<dependency>
<groupId>io.osseva.ignite</groupId>
<artifactId>ignite-core</artifactId>
<version>2.16.1-osseva-1</version>
</dependency>
<dependency>
<groupId>io.osseva.ignite</groupId>
<artifactId>ignite-indexing</artifactId>
<version>2.16.1-osseva-1</version>
</dependency>Migrate from Unsupported Apache Ignite 2.x clusters
OSSeva patches the 2.x line in place, so the cache API, persistence format and client protocol your applications were built against do not change. Where a move is warranted, the assessment costs Ignite 3 against the alternatives honestly — because a rewrite on the vendor's schedule is not automatically the right answer for your estate.
Pricing model
OSSeva for Apache Ignite is priced per cluster — not per node, cache or GB held in memory.
When does Apache Ignite 2.x reach end of life?
The Apache Ignite project publishes no end-of-life dates, and endoflife.date does not track it, so there is no date to plan around. What is on record is the release history: 2.12 through 2.17 each shipped a single release, 2.18.0 followed on 23 April 2026, and CVE-2024-52577 and CVE-2025-48977 are fixed only on 2.17.0 and 2.18.0. OSSeva patches 2.8, 2.9, 2.13 and 2.16 in place.
Is Apache Ignite 2.x still supported?
The 2.x series still gets new minor releases: Apache Ignite 2.18.0 was announced on 6 May 2026, alongside Ignite 3.0.0 from February 2025 and 3.1.0 from October 2025. Older 2.x lines do not get patch releases. 2.13 and 2.16 each had a single release, 2.13.0 and 2.16.0, so a fix means moving to a newer minor. OSSeva ships patched builds on 2.8, 2.9, 2.13 and 2.16.
Can we upgrade from Ignite 2 to Ignite 3 in place?
No. Ignite 3 is a ground-up rewrite with a new storage engine, a new SQL engine, a new client protocol and a new configuration model. Application code written against the 2.x cache and compute APIs has to be ported, and data has to be migrated rather than read in place. It should be planned as a migration project with its own budget.
Why is an unpatched Ignite cluster higher risk than an unpatched cache?
Because Ignite is a compute grid as well as a data grid. It ships user closures to nodes and executes them, and peer class loading distributes classes across the cluster automatically. Those are intended features, but they mean a weakness in node authentication or the discovery protocol becomes cluster-wide code execution rather than data exposure.
Does OSSeva cover Ignite native persistence as well as in-memory caches?
Yes. Clusters using native persistence hold primary copies of data rather than a cache of something authoritative elsewhere, which raises both the availability and the integrity stakes. Coverage includes the persistence layer, and the Operate tier manages checkpointing, WAL and rebalance behaviour directly.
Should we move to Ignite 3 or to a different data grid entirely?
That depends on which Ignite features you actually use. If the estate leans on SQL and native persistence, Ignite 3 is a reasonable destination. If it is primarily distributed caching, other grids may be a shorter path. OSSeva covers GemFire, Geode, Hazelcast and Ignite, so the assessment compares them on your usage rather than steering toward one product.
Who provides Apache Ignite support besides GridGain?
Support comes from the Apache Ignite project, from commercial vendors such as GridGain, from cloud managed services, and from third-party support companies. OSSeva fits where you run community Apache Ignite 2.x and are not moving to Ignite 3. It covers GemFire, Geode, Hazelcast and Ignite under one contract, includes end-of-life versions, and runs where you run.
Does OSSeva support current Apache Ignite versions or only end-of-life ones?
Both. OSSeva's support matrix lists Ignite 3.x as current and upstream maintained, 2.16.x as extended, and 2.8.x, 2.9.x and 2.13.x as end of life with OSSeva patching. OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days.
How is OSSeva Apache Ignite support priced?
OSSeva for Apache Ignite is priced per cluster, not per node, cache or GB held in memory. Patch covers the patched builds, Assure adds the audit work and 24/7 reactive support, and Operate adds proactive 24/7 monitoring with a 15-minute P1 SLA. Book a discovery call for a quote.
Get a quote
Ready to get Apache Ignite patched and supported?
Tell us your Apache Ignite versions and an engineer replies within 1 business day with coverage and a price. Prefer a call? It takes 15 minutes.
Prefer to talk or read more first?