CVE remediation for Chainguard Libraries

CVE remediation for Chainguard Libraries provides protection against critical and high CVEs. Applications often rely on older versions of libraries, but upstream maintainers may not apply and release patches for those versions. Chainguard addresses this gap by backporting vulnerability fixes from newer releases to older releases, particularly in cases where maintainers are no longer able to support and provide fixes.

CVE remediation helps reduce risk for organizations that cannot always upgrade quickly, especially when moving to a newer version would introduce disruptive changes. Remediated artifacts are published as incremental patch versions, allowing teams to take a targeted fix for a CVE without taking on a broader upgrade at the same time.

CVE remediation is available for a subset of Chainguard Libraries for Python, Chainguard Libraries for Java (available in private preview), and Chainguard Libraries for JavaScript. If you want to request CVE remediation for additional libraries, reach out to your account team.

About CVE remediation

CVE remediation focuses on critical and high vulnerabilities. Chainguard backports fixes that are already available in the new versions of the upstream project to older versions that may no longer receive updates.

Before publishing a remediated version, Chainguard validates that the remediated version does not introduce regressions. All upstream test suites are run before and after applying the fix to confirm functional consistency. Chainguard also develops additional regression tests to validate the effectiveness of the CVE fix.

Remediated libraries are distributed through a dedicated repository. This provides the option to make remediated versions available for your development or opt out of using these versions completely and continue to use upstream versions only.

Remediated version naming

Chainguard publishes remediated versions using ecosystem-specific version suffixes.

Python version naming

For Python, remediated packages use a +cgr.N local version suffix. For example, if flask==1.1.2 has a remediated build, Chainguard publishes it as flask==1.1.2+cgr.1. Python package managers treat this as a higher-precedence local version of the base release, so remediated versions can be selected automatically during dependency resolution when the remediated index is configured.

Java version naming

For Java, remediated artifacts use a -0.cgr.N suffix appended to the base version. For example, if org.apache.commons:commons-lang3:3.18.0 has a remediated build, that build is published as org.apache.commons:commons-lang3:3.18.0-0.cgr.1. If Chainguard publishes another remediated iteration for the same base version, the trailing number increases, such as -0.cgr.2 or -0.cgr.3.

JavaScript version naming

For JavaScript, remediated artifacts use a -cgr.N suffix appended to the base version. For example, a remediated build of example-package v4.17.21 is published as example-package@4.17.21-cgr.1.

Because -cgr.N is an npm prerelease identifier, it must not be treated as a newer ordinary release by npm semver resolution. The JavaScript build integration selects the remediated artifact while preserving the dependency version requested by the application.

Remediation and transitive dependencies

Python

For Python, installing a +cgr.N package doesn’t automatically remediate its entire dependency tree. Chainguard publishes a +cgr.N version only for a package that has a remediation to deliver, and it leaves that package’s own dependency declarations unchanged.

This is intentional. Most packages don’t pin their dependencies tightly enough to require a rewrite, so the package metadata stays identical to upstream.

Remediation propagates across the dependency tree through the index, not through dependency declarations. When you configure the Chainguard index, your package manager resolves every dependency, both direct and transitive, through Chainguard Libraries rather than the upstream index. As described in Remediated version naming, a +cgr.N build is a higher-precedence local version, so the resolver selects it automatically wherever Chainguard has published one. Dependencies without a remediation resolve to the standard upstream version served through the same index.

Java

Java remediation behavior differs from Python. For Java packages that publish a BOM, Chainguard may update the BOM to roll forward dependencies to remediated versions. This means transitive dependencies can receive CVE remediations without requiring changes to your own dependency declarations.

Note that BOM-based remediation is best-effort and does not cover all packages or dependency trees. To ensure full control over dependency versions in your project, use dependencyManagement or equivalent tooling to explicitly manage and override dependency versions.

JavaScript

JavaScript remediation operates on the resolved dependency tree in the project lockfile rather than through package metadata or semver precedence.

To preview available remediations, run:

chainctl libraries remediate

To adopt remediated artifacts, run:

chainctl libraries remediate --apply

The command walks the lockfile and updates each eligible package occurrence to the corresponding Chainguard remediated version when one is available. For a direct dependency, it sets the exact -cgr.N version in package.json. For a transitive dependency, it adds an override or resolution rule supported by your package manager. In both cases, it updates the lockfile.

This process can remediate transitive dependencies, but only when a remediated build exists for the exact package version resolved in the lockfile. Dependencies without a published -cgr.N build remain unchanged.

A single rule can cover more than one occurrence of a package. The package manager applies the rule during resolution wherever a dependency matches the rule’s package name and version, then records the substituted versions in the lockfile. Because matching is by name and version rather than by position, one rule can remediate every matching node in the dependency tree — you don’t need a separate rule for each occurrence. How widely a rule applies depends on its syntax: a rule scoped to a name and version matches only that version, while broader patterns can match additional ranges or nesting.

After applying remediation, review the updated lockfile to confirm that each dependency you intended to remediate resolves to the selected -cgr.N version. The lockfile is the authoritative record of what your package manager will install.

Re-run chainctl libraries remediate after every install or dependency update so that newly resolved entries are evaluated. You can also use a direct package override in package.json to select an exact remediated version manually.

Unlike Python, JavaScript remediation does not rely on a remediated index selecting a higher-precedence version. Unlike Java, it does not depend on BOM updates to propagate remediation through the dependency tree.

CVE remediation for vendored dependencies

Some Python packages bundle compiled code written in other languages (such as Go, Rust, or C/C++) directly into their wheel. When a CVE exists in a dependency of that vendored code, Chainguard may publish a remediated version even when no CVE has been filed against the Python package itself.

In these cases, Chainguard bumps the vulnerable dependency within the vendored code and publishes a new +cgr.N version of the package. Because the vulnerability exists at the vendored dependency level rather than the Python package level, no advisory entry is published in the VEX feed for these versions. However, scanners that inspect vendored binaries will reflect the fix in their results.

Browse libraries with CVE remediation

Remediated libraries are published in dedicated repositories:

• Python: In a PyPI-compatible index at https://libraries.cgr.dev/python-remediated/ - the simple index is at https://libraries.cgr.dev/python-remediated/simple/
• Java: In a repository at https://libraries.cgr.dev/java-remediated/ - a companion to the standard Chainguard Libraries for Java repository at https://libraries.cgr.dev/java/
• JavaScript: Consume remediated artifacts through the standard JavaScript endpoint: https://libraries.cgr.dev/javascript/.

You can:

• Browse them in the Chainguard Console
• Use the public VEX feed to understand what has been remediated
  • This feed does not include vendored dependencies.
• View them in a browser at the simple index URL
  • Learn more in Python overview > Manual access and in Java overview > Manual access.
• Expose them to your developers via a repo manager
  • Learn more in the global configuration docs for Python and Java.

Browse remediated libraries in the Chainguard Console

In the Chainguard Console, navigate to the Python or Java libraries, then click the Remediated tab. Click into a library to see which versions have remediated CVEs.

Learn more in Browsing Chainguard Libraries.

Public VEX feed

Advisories for each CVE addressed in our remediated libraries are published via a public VEX feed at https://libraries.cgr.dev/openvex/v1/all.json. Supported scanners and your own custom tooling can use this feed to identify and recognize remediated versions.

To view more details on the CVE and versions of a library that have been remediated, identify the library then navigate to the URL. For example: https://libraries.cgr.dev/openvex/v1/pypi/urllib3.openvex.json.

Scanning remediated libraries

Chainguard works closely with scanner partners so that remediated versions are properly recognized in vulnerability reports. This ensures that teams can maintain their existing scanning workflows while benefiting from patched dependencies.

Find more general information and specifics for supported scanners in Vulnerability Scanners and Chainguard Libraries.