# CVE remediation for Chainguard Libraries URL: https://chainguard-docs-preview-git-fix-learning-lab-jsonld.chainguard.app/chainguard/libraries/policies-and-security/cve-remediation.md Last Modified: October 2, 2026 Tags: Chainguard Libraries, CVE An overview of the CVE remediation feature 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/python/overview/), [Chainguard Libraries for Java](/chainguard/libraries/java/overview/) (available in private preview), and [Chainguard Libraries for JavaScript](/chainguard/libraries/javascript/overview/). 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](#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: ```bash chainctl libraries remediate ``` To adopt remediated artifacts, run: ```bash 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](#cve-remediation-for-vendored-dependencies). - View them in a browser at the simple index URL - Learn more in [Python overview > Manual access](/chainguard/libraries/python/overview/#manual-access) and in [Java overview > Manual access](/chainguard/libraries/java/overview/#manual-access). - Expose them to your developers via a repo manager - Learn more in the global configuration docs for [Python](/chainguard/libraries/python/global-configuration/) and [Java](/chainguard/libraries/java/global-configuration/). ### 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](/chainguard/libraries/introduction/browse/). ### 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](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](/chainguard/libraries/policies-and-security/scanners/).