When Hazelcast goes EOL, the CVEs don't stop.
Supported Versions: 5.1.x, 5.2.x, 5.3.x
Never-Ending Support (NES) for Hazelcast keeps your in-memory data grid secure, compliant, and audit-ready after your release line stops getting upstream patches. If you run Hazelcast 5.1, 5.2, or 5.3, NES gives you a maintained build so your team controls the security posture and the migration timeline, not the release calendar.
TRUSTED BY ENTERPRISE
Security, compliance, and continuity, solved together
Hazelcast sits in the hot path of your application, holding session state, cached data, and the results other services depend on. Hazelcast 5.1, 5.2, and 5.3 no longer receive upstream releases. The last patch on the 5.3 line was 5.3.8 in July 2024, and each line now carries unpatched CVEs in its final release, which your scanners flag on every build. NES for Hazelcast is a maintained build of the exact line you already run.
Security Risk
Hazelcast handles cluster membership, the client protocol, and SQL connectors. When your line goes EOL, permission-check and deserialization flaws stay open with no upstream fix.
CVE fixes delivered on committed SLAs for your Hazelcast line, including the vulnerable dependencies Hazelcast bundles.
SLA-backed patch delivery tied to severity
Fixes for Hazelcast core and the hazelcast-spring integration
Dependency fixes bundled in, including Jackson-core and JSON-java
Compliance
An EOL data-grid dependency is an open audit finding with no remediation path under PCI DSS, SOC 2, DORA, NIS2, and the EU Cyber Resilience Act.
Every NES build ships with VEX statements auditors and scanner tools can consume, so you have documented evidence to close the unsupported-dependency finding.
VEX statements published per release
Documented patch history
Coverage evidence for SOC 2, PCI DSS, DORA, NIS2, CRA
Business Continuity Risk
Moving off your Hazelcast line can mean a cluster-wide upgrade, protocol and serialization changes, and a coordinated rolling restart across every service that shares the grid.
A drop-in build that keeps the same Maven coordinates, so you stay patched on your current line and migrate on your own schedule.
Same groupId and artifactId, only the version changes
No application code changes
Runway to plan a proper upgrade
What changes the day you install NES.
Before — the pain
Your grid runs on an EOL Hazelcast line. Scanners flag every build, no upstream patches are coming, and a new client-protocol or connector CVE stays exploitable until you migrate.
After — with HeroDevs
NES restores your patch path. You move to the NES build of your line and resume SLA-backed CVE fixes, with the same cluster behavior and client APIs.
Before — the pain
Internal audit, SOC 2, and customer security questionnaires all flag your EOL Hazelcast dependency. There is no remediation path short of a rushed upgrade, and no defensible answer for auditors.
After — with HeroDevs
A maintained, vendor-backed build with committed SLAs and VEX statements. The unsupported-dependency finding closes and you point auditors at documented patch history.
Before — the pain
Jumping Hazelcast lines can bring protocol and serialization changes that ripple across every service on the grid, and a rushed migration pulls engineers off the roadmap.
After — with HeroDevs
A drop-in build with no code changes. Your team gets the runway to plan a proper upgrade while the line you run stays secure and supported.
Not just hazelcast-core.
NES for Hazelcast covers the artifacts your services actually pull in, and the vulnerable libraries bundled inside them.
Core
hazelcast
The data-grid engine and client.
Spring integration
hazelcast-spring
Spring configuration and beans.
Bundled dependency fixes
Fixes for vulnerable libraries Hazelcast ships, delivered through HeroDevs NES builds:
Jackson-core (async parser number-length constraint bypass)
JSON-java (denial of service via deeply nested keys)
SUPPORTED LINES
Hazelcast 5.1.x, 5.2.x, and 5.3.x. Each build is a fork of the upstream open-source tag (5.1.7, 5.2.5, 5.3.8) with the fixes applied. Each line requires Java 8.
Easy to deploy, no disruptions
NES version strings by line: 5.1.7-hazelcast-5.1.9, 5.2.5-hazelcast-5.2.7, 5.3.8-hazelcast-5.3.10. Gradle, Nexus, and Artifactory setup guides are in the docs.
Add the registry
Register https://registry.nes.herodevs.com/maven as a Maven repository in your settings.xml or pom.xml. Allowlist registry.nes.herodevs.com and assets.nes.herodevs.com if your network filters outbound traffic.
Set up your token
Add your HeroDevs NES access token as the password on the herodevs-nes-registry server entry in settings.xml so the build can pull the patched artifacts.3
Update the version
Point com.hazelcast:hazelcast (and hazelcast-spring) at the NES version for your line and rebuild. No application code changes.
Scanners pass
The build is actively patched and ships with VEX statements, so the EOL finding closes.
A defensible answer for every standard, framework, or regulation
EOL software undermines patch-management expectations across regulations worldwide. NES gives you a maintained, vendor-backed build with committed SLAs and a documented patch history to demonstrate compliance to auditors and regulators.
PCI DSS
Req. 6.3.3 requires known critical and high-severity vulnerabilities to be patched within 30 days. EOL Hazelcast with no upstream patch puts you out of compliance. NES restores the patch path.
HIPAA
Unsupported components make it hard to show reasonable safeguards for systems handling ePHI. NES provides active maintenance and risk reduction.
SOC 2
Trust Services Criteria expect timely vulnerability remediation. EOL dependencies raise material findings during audit unless a compensating support path exists. NES is that support path.
NIS2
Article 21 covers patching, vulnerability, and supply-chain management. Running EOL software without a maintained support path creates risk NIS2 expects operators to actively mitigate.
DORA
DORA treats EOL software as a resilience gap for financial ICT assets. NES gives you a maintained build and a documented patch-management program.
Cyber Resilience Act
Governs software lifecycle security for products with digital elements. NES gives you a maintained, patched build for your EOL Hazelcast line during the coverage period.
NIST CSF 2.0
Control PR.PS-02 requires organizations to actively maintain or remove vulnerable software based on risk. NES enables compliance without a forced upgrade.
FedRAMP
Continuous monitoring expects flaw remediation on a defined cadence. A patched, vendor-backed build gives your ISSO the documented remediation path to justify keeping EOL Hazelcast in the authorization boundary.
Built by security engineers who patch what you run.
Every NES for Hazelcast build closes the known CVEs for your line and ships with VEX statements and release notes that map to the advisories your scanner is flagging. HeroDevs engineers build reproducers for the vulnerabilities we patch, so the fix is verified against the actual exploit, not just a version bump. HeroDevs is a CVE Numbering Authority and a funder of open-source sustainability.
CVE Numbering Authority
Discovery and publication of CVEs in HeroDevs-covered products.
VEX with every build
Machine-readable for your scanners.
Committed SLAs
Severity-tied patch delivery.
Frequently Asked Questions
Contact Us
Got questions about Never-Ending Support for your open-source library? We're here to help!
Discover how HeroDevs NES Products can keep your systems secure and compliant.
Learn how our solutions can deliver value to your organization.
Get detailed pricing information tailored to your needs.
Stay on Top of Java and JVM Security & Compliance Updates
View All Articles
