Apache Ignite Vulnerabilities by Version: CVEs for Ignite 2.x and Ignite 3

The short answer

Apache Ignite ships fixes for the 2.x series only in the newest 2.x minor release. There have been no 2.x patch releases since 2.11.1 in December 2021: every line since has had a single release, from 2.12.0 to 2.18.0, and recent CVEs were fixed only in the next minor release. Today 2.18.0, from 23 April 2026, is the only 2.x release with every fix. The two recent CVEs show the effect. CVE-2024-52577, a remote code execution through deserialization scored 9.0, is fixed only from 2.17.0. CVE-2025-48977, a file read through the REST API, is fixed only in 2.18.0. A cluster on 2.16.0 or older has neither fix.

The Ignite download page labels Ignite 2 a long-term support release that "continues to receive maintenance updates". The project publishes no end date for that support and no policy for older 2.x minors, so in practice LTS means the 2.x series keeps getting new minor releases, not that any one of them gets patches.

Ignite release lines and their CVEs

Release dates are from the Ignite download page, the Apache release archive and Maven Central. Each row lists the CVEs on the Apache security advisories for Ignite, and the older ones on NVD, that name the line and have no fix on it.

The Apache advisories for Ignite since 2023 all concern 2.x, and none names Ignite 3. That reflects how new Ignite 3 is, not a finding that it has no flaws. For release dates on every line, see the Apache Ignite end-of-life chart.

Notable Ignite CVEs by release line

CVSS is NVD's own score. Apache, as the CNA, scores the two recent CVEs with CVSS 4.0, at 9.5 for CVE-2024-52577 and 8.5 for CVE-2025-48977. None of these CVEs is in CISA's Known Exploited Vulnerabilities catalogue.

Three of the five rows are the same weakness in different places: Ignite nodes deserialize Java objects from the network, and any class on the classpath with a dangerous deserialization path becomes a way in. The 2018 fixes added allow and block lists through the IGNITE_MARSHALLER_WHITELIST and IGNITE_MARSHALLER_BLACKLIST system properties. CVE-2024-52577 is the finding that some endpoints ignored configured class serialization filters from 2.6.0 until 2.17.0, so a cluster that relied on filtering had a gap it could not see. Ignite's compute grid and peer class loading make that worse, because classes reach nodes by design. CVE-2025-48977 needs the REST HTTP API, which runs only when the optional ignite-rest-http module is enabled, and CVE-2020-1963 needs the SQL engine, which comes from the ignite-indexing module.

What each line gets

Ignite 2.18

2.18.0 carries every fix above. Because the 2.x series has no patch releases, the next CVE will be fixed in 2.19.0 or later, so staying covered means taking each new 2.x minor release.

Ignite 2.17

2.17.0 has the fix for CVE-2024-52577 but not for CVE-2025-48977. Moving to 2.18.0 is a minor upgrade within 2.x.

Ignite 2.12 to 2.16

These lines each had one release, and none has the fixes for CVE-2024-52577 or CVE-2025-48977. The advisory for CVE-2025-48977 gives the general mitigation for all versions as making sure there are no vulnerable classes in the custom code deployed to Ignite, and the upgrade path as 2.18.

Ignite 2.8 to 2.11

2.8.1, 2.9.1 and 2.11.1 were the last 2.x patch releases. 2.8.1 fixed CVE-2020-1963, so a cluster on 2.8.0 should at least move to 2.8.1. Beyond that, these lines have the same two open CVEs as 2.12 to 2.16.

Ignite 3

Ignite 3 is a separate product line with its own storage engine, SQL engine, client protocol and configuration model. Applications written against the 2.x cache and compute APIs need code changes to move, and the migration tools that ship with 3.1 handle part of the work; see migrating Apache Ignite 2.x to Ignite 3.

What to do on each line

• 2.18. Stay on it, and plan to take each new 2.x minor release when it ships.
• 2.12 to 2.17. Move to 2.18.0. Until then, keep discovery, communication and thin client ports off untrusted networks, disable the REST HTTP module where you do not use it, and review which classes your deployed code puts on node classpaths.
• 2.11 and older. Move to 2.18.0, or take patched builds from a supplier that backports fixes. Until then, configure a class serialization filter, knowing from CVE-2024-52577 that some endpoints ignored it before 2.17.0, remove ignite-indexing from nodes that do not use SQL, and enable Ignite authentication.
• Ignite 3. Treat it as a migration project and cost it against staying on 2.x, rather than as the fix for a CVE.

Where OSSeva fits

OSSeva ships patched builds of Apache Ignite 2.8, 2.9, 2.13 and 2.16 with the cache API, persistence format and client protocol unchanged, covering discovery, communication SPI and REST advisories, delivered as signed Maven artifacts, Docker images and tarballs. OSSeva backports fixes of this class to the end-of-life release lines it patches. They are available now on the Patch, Assure and Operate tiers. Assure adds a discovery port exposure and authentication audit, a cache and compute API usage inventory and an Ignite 3 migration assessment with an effort estimate, and Operate adds 24/7 heap, off-heap and baseline topology monitoring with a 15-minute P1 response and a named senior Apache Ignite engineer. See Apache Ignite support and Ignite 2 extended support.