Chainguard Libraries for Java is now GA and includes CVE remediation

Today, Chainguard Libraries for Java is now generally available and includes CVE remediation. We’re starting with backporting fixes for critical and high-severity CVEs across the Spring Boot ecosystem, which is widely used to build backend applications and APIs without manually configuring a server or dozens of libraries. To date, we’ve backported remediations for dozens of CVEs across spring-boot, spring-framework, spring-security, and h2database.

The risks of an unpatched, pinned Java dependency

We’re adding CVE remediation to Chainguard Libraries for Java at a time when advanced frontier models have changed the threat calculus. AI tools are now scanning open source projects at a rate that produces hundreds of new security reports each month. Spring received 482 new reports in April 2026 alone. Meanwhile, the mean time to exploit a CVE has gone from 63 days in 2018 to -7 days in 2025, meaning active exploits arrive before patches. That pace makes the traditional playbook for handling legacy CVEs untenable.

Ninety percent of the Fortune 500 rely on Java for their core systems. All of them struggle with the same question: how do I fix this CVE for this older version I’m pinned on? Take the last release of Spring Boot 2.7, for example. It reached end of life in November 2023 and has 143 CVEs across 79 projects. None of those CVEs have received patches, which means teams are stuck carrying that risk.

Today, engineering teams building in Java are caught between three tough options with their legacy Java applications.

1. They could try to get an exception to use the library from their security team. However, this doesn’t make them any safer and doesn’t solve the risk problem at hand.

2. They could try to backport CVE fixes themselves. However, this takes hours and doesn’t scale across teams using the same vulnerable library across hundreds of applications and APIs.

3. They could try upgrading to a newer version that addresses the critical CVEs. However, upgrading can take months (sometimes even a year) and prevents the team from building new product functionality that drives revenue. Like option two, it also doesn’t scale, as each team needs to upgrade to major versions while ensuring their applications don’t break in the process.

Stay safe while you plan your next upgrade

Chainguard Libraries for Java introduces an important fourth option: swap your vulnerable Java library for one that Chainguard has remediated via a backported fix. All you need to do is reference the remediated version in your pom.xml file. This keeps your application safe while your team can complete your next major version upgrade without disrupting your development workflow. Now, packages you consume from the Chainguard endpoint both reduce your known vulnerability risk and protect you from the next inter-ecosystem, credential-harvesting worm.

All Chainguard remediated packages come with SBOMs and provenance. This gives your team verifiable proof of the artifact’s integrity and security to an auditor.

Other CVE remediation solutions deliver a patch file layered on top of the original vulnerable library. That approach can close the risk gap, but it leaves an audit trail problem. Your scanner still sees the original vulnerable version identifier, and an auditor reviewing your artifact sees a known CVE with a manual modification on top. Chainguard ships a new version with a -0.cgr.N suffix, so your scanner and your auditor see a clean, versioned artifact rather than a patch. Wiz, AWS Inspector, Grype, and Trivy all recognize Chainguard’s remediated Java libraries, and we plan to continue adding more scanners in the coming months.

In the console, you can see which CVEs are remediated in a specific version, which other versions have the same backported fix, and access links to advisory details. You can also access all of Chainguard’s remediated versions through our public VEX feed.

Reach out today to get started with Chainguard Libraries for Java.