Apache Cassandra 3.0
Apache Cassandra 3.0
The Apache Cassandra 3.0 reached end of service life on Sep 5, 2024 — Apache Cassandra no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.
24/7 engineers own your Apache Cassandra 3.0 incidents end to end.
Mitigation and patch-around guidance when the vendor no longer ships fixes.
Controls evidence and documentation that keep auditors satisfied.
Specifications
- product
- apache-cassandra
- release
- 3.0
- product Label
- Apache Cassandra
- release Label
- 3.0
- codename
- lts
- latest Version
- 3.0.32
- release Date
- 2015-11-09
- maintained
- source Url
- https://endoflife.date/apache-cassandra
Lifecycle Dates
- End of Service Life
- Sep 5, 2024
- Last OEM Support
- Sep 5, 2024
OEM vs. 3rd Party Support
See how third-party support compares to the vendor contract for Apache Cassandra 3.0 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.
| Feature | OEM Support | 3rd Party Support |
|---|---|---|
| Post-EOSL Support | ||
| Break/Fix Support | Until EOSL | |
| 24/7 Monitoring | ||
| Vulnerability Scanning & Remediation | ||
| Managed Operations | ||
| Procedure & Configuration Review | ||
| Compliance & Audit Documentation | Limited | |
| Discounted Migration to Other Platforms |
Why Choose 3rd Party Support for Apache Cassandra 3.0?
Vulnerability Remediation
Scanning, mitigation and patch-around guidance for Apache Cassandra 3.0 when the vendor no longer ships fixes.
Compliance Maintenance
Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.
24/7 Expert Support
Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.
Apache Cassandra 3.0 Support: Frequently Asked Questions
Is the Apache Cassandra 3.0 still supported?
Apache Cassandra ended support for the Apache Cassandra 3.0 on Sep 5, 2024 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.
When is the Apache Cassandra 3.0 end of service life (EOSL) date?
Apache Cassandra lists the end of service life for the Apache Cassandra 3.0 as Sep 5, 2024.
Can I keep using the Apache Cassandra 3.0 after its EOSL date?
Yes. EOSL means Apache Cassandra stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.
How much does third-party support for the Apache Cassandra 3.0 cost?
Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.
Known Vulnerabilities Affecting Apache Cassandra 3.0
7 published CVEs affect the Apache Cassandra 3.0, including 5 rated critical or high severity. Apache Cassandra no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.
| CVE | Severity | CVSS | Published | Summary |
|---|---|---|---|---|
| CVE-2016-3427 | CRITICAL | 9.8 | Apr 21, 2016 | Unspecified vulnerability in Oracle Java SE 6u113, 7u99, and 8u77; Java SE Embedded 8u77; and JRockit R28.3.9 allows remote attackers to affect confidentiality, integrity, and availability via vectors related to JMX. |
| CVE-2021-44521 | CRITICAL | 9.1 | Feb 11, 2022 | When running Apache Cassandra with the following configuration: enable_user_defined_functions: true enable_scripted_user_defined_functions: true enable_user_defined_functions_threads: false it is possible for an attacker to execute arbitrary code on the host. The attacker would need to have enough permissions to create user defined functions in the cluster to be able to exploit this. Note that this configuration is documented as unsafe, and will continue to be considered unsafe after this CVE. |
| CVE-2025-26467 | HIGH | 8.8 | Aug 25, 2025 | Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches. This issue affects Apache Cassandra 3.0.30, 3.11.17, 4.0.16, 4.1.7, 5.0.2, but this advisory is only for 4.0.16 because the fi |
| CVE-2025-23015 | HIGH | 8.8 | Feb 4, 2025 | Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches. This issue affects Apache Cassandra through 3.0.30, 3.11.17, 4.0.15, 4.1.7, 5.0.2. Users are recommended to upgrade to versions |
| CVE-2020-17516 | HIGH | 7.5 | Feb 3, 2021 | Apache Cassandra versions 2.1.0 to 2.1.22, 2.2.0 to 2.2.19, 3.0.0 to 3.0.23, and 3.11.0 to 3.11.9, when using 'dc' or 'rack' internode_encryption setting, allows both encrypted and unencrypted internode connections. A misconfigured node or a malicious user can use the unencrypted connection despite not being in the same rack or dc, and bypass mutual TLS requirement. |
| CVE-2020-13946 | MEDIUM | 5.9 | Sep 1, 2020 | In Apache Cassandra, all versions prior to 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2, it is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorised operations. Users should also be aware of CVE-2019-2684, a JRE vulne |
| CVE-2019-2684 | MEDIUM | 5.9 | Apr 23, 2019 | Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: RMI). Supported versions that are affected are Java SE: 7u211, 8u202, 11.0.2 and 12; Java SE Embedded: 8u201. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java S |