OSSEVA FOR HAZELCAST
Open core, closed support window.
Hazelcast development runs on the Platform 5.x line — 5.7.0 shipped 13 May 2026. IMDG 3.x and 4.x deployments, and older 5.x releases, sit outside it. Under an open-core model, staying on the community edition without a subscription means staying without patches.
Last reviewed
Trusted globally by enterprises
Why now
IMDG 3.x and 4.x are behind a line that keeps moving
Hazelcast has consolidated on the Platform 5.x series, with 5.5.0 in July 2024, 5.6.0 in October 2025 and 5.7.0 in May 2026. Deployments on IMDG 3.x or 4.x are several majors behind an actively moving line, and the further back they sit, the less likely a fix is ever backported to them.
Open core means the free edition and the supported edition are not the same product
Hazelcast splits community and enterprise editions, with features including WAN replication, persistence, security hardening and rolling upgrades on the commercial side. Teams that deployed the community edition to avoid licensing then find that support, and the operational tooling that makes upgrades safe, are exactly what they opted out of.
The grid holds session state, and the grid speaks Java serialization
Hazelcast clusters typically hold HTTP session state, cached credentials and hot business data, and members exchange serialized Java objects over the cluster protocol. Deserialization advisories in this class of product are remote code execution with the grid's own trust level — and clusters are often deployed flat, with member ports reachable more widely than intended.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| IMDG 3.12.x(Several majors behind — OSSeva patched) | EOL | Clean |
| IMDG 4.0.x(Several majors behind — OSSeva patched) | EOL | Clean |
| IMDG 4.2.x(Several majors behind — OSSeva patched) | EOL | Clean |
| Platform 5.3.x(Superseded — OSSeva patched) | Extended | Clean |
| Platform 5.5.x(Released Jul 2024) | Extended | Clean |
| Platform 5.7.x(Released May 2026) | 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 the Hazelcast line you run, no subscription required.
- Security backports for IMDG 3.x, 4.x and older Platform 5.x
- Deserialization and cluster protocol advisory priority coverage
- Client library patching in step with member builds
- Maven / Docker delivery
- Signed artifacts (GPG)
- Cluster security audit
- 24/7 managed operations
OSSeva Assure
Patch plus grid audit and a costed comparison of the paths off 3.x / 4.x.
- Everything in Patch
- Cluster topology, partition and split-brain review
- Member port exposure and join-mechanism audit
- Serialization configuration and class filtering review
- SOC 2 / HIPAA attestation package
- Upgrade or migration options assessment
- 24/7 managed operations
OSSeva Operate
Full MSP: 24/7 grid monitoring, 15-min SLA, named data grid engineers.
- Everything in Assure
- 24/7 heap, partition and member health monitoring
- 15-minute P1 incident response SLA
- Named senior in-memory data grid engineer
- Eviction, near-cache and backup-count tuning
- Rolling upgrade or migration execution
- Quarterly capacity planning 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 and member list from the REST endpoint
curl -s http://hazelcast:5701/hazelcast/rest/cluster
# Confirm the member port is not reachable beyond the cluster subnet.
# Hazelcast members trust each other; anything that can join, can read.
nmap -p 5701-5703 hazelcast-member.internal
# From a client application
java -cp hazelcast.jar com.hazelcast.instance.BuildInfoProvider<dependency>
<groupId>io.osseva.hazelcast</groupId>
<artifactId>hazelcast</artifactId>
<version>4.2.8-osseva-1</version>
</dependency>
<!-- Client and member artifacts are built and released together
so both ends of a connection stay on the same patch level. -->
<dependency>
<groupId>io.osseva.hazelcast</groupId>
<artifactId>hazelcast-client</artifactId>
<version>4.2.8-osseva-1</version>
</dependency>Migrate from Unsupported Hazelcast IMDG 3.x / 4.x
OSSeva patches the Hazelcast line already in production, so the serialization format, cluster protocol and client compatibility your applications depend on stay fixed. Where a move makes sense, the assessment compares upgrading within Hazelcast against migrating to an alternative grid, costed against the features actually in use rather than the feature matrix.
Pricing model
OSSeva for Hazelcast is priced per cluster — not per member, per GB stored or per client connection.
Frequently asked questions
Is Hazelcast open source?
It is open core. There is a community edition and a commercial edition, and features that enterprises rely on — including WAN replication, persistence, additional security hardening and rolling upgrade tooling — sit on the commercial side. Teams that chose the community edition to avoid licensing costs generally also opted out of support and of the tooling that makes upgrades low-risk.
What happens to Hazelcast IMDG 3.x and 4.x deployments?
They fall further behind with each Platform release. Development has consolidated on the 5.x line, with 5.7.0 released in May 2026, and fixes are not backported several majors down. A 3.12 or 4.2 cluster is stable but static — it will not receive security updates from upstream.
How risky is an unpatched in-memory data grid, really?
Higher than most teams assume, for two reasons. Grids hold session state and cached credentials, so a read is immediately valuable. And members exchange serialized Java objects with implicit trust in one another, which makes deserialization advisories in this class of product remote code execution rather than information disclosure. Clusters deployed on a flat network compound both.
Can OSSeva upgrade a Hazelcast cluster without downtime?
Within a line, usually yes — members are replaced one at a time with partitions rebalanced as they leave and rejoin. Across majors it depends on whether the serialization format and client protocol are compatible, which is what the Assure assessment establishes before anything is scheduled.
How does Hazelcast compare to GemFire, Geode and Ignite for our workload?
They overlap heavily and the right answer depends on which features you actually use rather than which product is broadly better. OSSeva covers all four, so the assessment is not a sales exercise for one of them — see the GemFire and Ignite coverage for how those estates are handled.
Ready to get Hazelcast 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.