Conversation
RUSTSEC-2026-0042 / CVE-2026-4428 (CVSS 7.4) is a logic error in AWS-LC's CRL distribution-point matching that lets a revoked certificate pass revocation checking. It affects aws-lc-fips-sys below 0.13.13; both lockfiles pinned 0.13.12. Almost certainly not exploitable here. The advisory is about AWS-LC's own X.509 validation path, reached through `X509_V_FLAG_CRL_CHECK`, and specifically about partitioned CRLs carrying an Issuing Distribution Point extension. This driver does its CRL checking in rustls: `tls::crl_verifier` wraps `WebPkiServerVerifier`, and the only aws-lc-rs surface the crate touches is primitives -- cipher, digest, signature, rand, pbkdf, encoding, iv. AWS-LC's certificate-path code is never entered. Taking it anyway, because the exposure argument is a reading of our call graph rather than a property a scanner can see: anything auditing the lockfile reports a High against a FIPS artifact, and answering that with prose every time costs more than the bump. For a compliance build the version in the lock is itself part of the claim. Scope is a lockfile change, nothing more. aws-lc-rs 1.16.1 requires `aws-lc-fips-sys ^0.13.1`, so the patched release is reachable without moving aws-lc-rs or aws-lc-sys, and neither moves here. The module goes from AWS-LC 3.2.0 to 3.6.0 -- still the certificated 3.x line, so this does not disturb what the `aws-lc-rs` upper bound on the FIPS stack exists to hold. python/Cargo.lock.sdist gets the same bump. Its helper script only has `check` and `refresh`, and `refresh` deliberately does not bump versions, so it leaves a still-valid 0.13.12 alone; the update was run with `cargo update -p aws-lc-fips-sys` against the same temporary sdist workspace the script builds, then checked with the script. Verified against a real FIPS build (conda GCC 13): the three `tls::fips_tests` assertions pass, so 0.13.17 reports FIPS mode and the installed provider and ClientConfig are still FIPS; the binary carries 1502 `aws_lc_fips_0_13_*` symbols and 0 `aws_lc_0_38_0_*`, so the linking story is unchanged. One question for the compliance owner, which this commit cannot settle: the certificate names a specific module version, so whether 3.6.0 is in scope under the same certificate as 3.2.0 needs confirming before this is treated as like-for-like.
zeroshade
marked this pull request as ready for review
September 25, 2026 19:23
![snowflake-security-bot[bot]](https://avatars.githubusercontent.com/u/140554735?s=60&v=4){kind=small}
snowflake-copybara Bot
pushed a commit
that referenced
this pull request
Sep 29, 2026
…visory fix (CVE-2026-4428) Imported from #1350. Original PR body: ## What Takes the `aws-lc-fips-sys` fix for **RUSTSEC-2026-0042 / CVE-2026-4428** (CVSS 7.4). Lockfiles only — `Cargo.lock` and `python/Cargo.lock.sdist`, `0.13.12` → `0.13.17`. The advisory is a logic error in AWS-LC's CRL distribution-point matching that lets a revoked certificate pass revocation checking. It affects `aws-lc-fips-sys` below `0.13.13`. ## Are we exploitable? Almost certainly not. The advisory concerns AWS-LC's own X.509 validation path, reached via `X509_V_FLAG_CRL_CHECK`, and specifically partitioned CRLs carrying an Issuing Distribution Point extension. This driver does CRL checking in rustls — `tls::crl_verifier` wraps `WebPkiServerVerifier` — and the only `aws-lc-rs` surface `sf_core` touches is primitives (cipher, digest, signature, rand, pbkdf, encoding, iv). AWS-LC's certificate-path code is never entered. Taking it anyway: that argument is a reading of our call graph, not something a scanner can see. Anything auditing the lockfile reports a High against a FIPS artifact, and for a compliance build the version in the lock is itself part of the claim. ## Scope `aws-lc-rs` 1.16.1 requires `aws-lc-fips-sys ^0.13.1`, so the patched release is reachable **without moving `aws-lc-rs` or `aws-lc-sys`** — and neither moves here. The module goes `AWS-LC 3.2.0` → `3.6.0`, still the 3.x branch selected by the `aws-lc-rs` upper bound on the FIPS stack, but that bound does not establish CMVP validation. Certificate #5314 names static AWS-LC FIPS 3.1.0, not 3.2.0 or 3.6.0. `python/Cargo.lock.sdist` gets the same bump. Its helper only has `check` and `refresh`, and `refresh` deliberately does not bump versions, so it leaves a still-valid `0.13.12` alone. The update was run with `cargo update -p aws-lc-fips-sys` against the same temporary sdist workspace the script builds, then validated with the script. ## Verification Real FIPS build, conda GCC 13 toolchain: - all three `tls::fips_tests` assertions pass — `0.13.17` reports FIPS mode, and the installed rustls provider and `ClientConfig` are still FIPS - binary carries **1502** `aws_lc_fips_0_13_*` symbols and **0** `aws_lc_0_38_0_*`, so the linking story is unchanged - 2282 tests pass with `--features fips-tls`, 2279 on the default build ## For the compliance owner The certificate names a specific module version. The public policy for static certificate #5314 names AWS-LC FIPS 3.1.0, not the previously locked 3.2.0 or the patched 3.6.0 selected here. A CMVP-recognized maintenance determination or revised policy covering the exact module is needed before claiming validation. Downgrading to 3.1.0 to fit the published policy would reintroduce CVE-2026-4428: AWS lists FIPS module versions below 3.3.0 as affected. ## Relationship to the FIPS stack Independent. The vulnerable version is on `main` today, so this is deliberately **not** stacked on #1346–#1349 — it can merge on its own rather than waiting on that review. Once it lands, rebasing the stack picks it up; the bound in #1346 (`>=1.13.2, <1.18`) accepts this resolution unchanged. --- Internal CI validates this change before merge. On merge to main the outbound mirror will push the commit back to the public repo; close the original mirror PR with a link to the mirrored commit. Co-authored-by: Matt Topol <zotthewizard@gmail.com> GitOrigin-RevId: b718912c1e6a4f2713e6785c7683ef336c1e68c3
Contributor
|
Merged in the private repo. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Takes the
aws-lc-fips-sysfix for RUSTSEC-2026-0042 / CVE-2026-4428 (CVSS 7.4). Lockfiles only —Cargo.lockandpython/Cargo.lock.sdist,0.13.12→0.13.17.The advisory is a logic error in AWS-LC's CRL distribution-point matching that lets a revoked certificate pass revocation checking. It affects
aws-lc-fips-sysbelow0.13.13.Are we exploitable?
Almost certainly not. The advisory concerns AWS-LC's own X.509 validation path, reached via
X509_V_FLAG_CRL_CHECK, and specifically partitioned CRLs carrying an Issuing Distribution Point extension. This driver does CRL checking in rustls —tls::crl_verifierwrapsWebPkiServerVerifier— and the onlyaws-lc-rssurfacesf_coretouches is primitives (cipher, digest, signature, rand, pbkdf, encoding, iv). AWS-LC's certificate-path code is never entered.Taking it anyway: that argument is a reading of our call graph, not something a scanner can see. Anything auditing the lockfile reports a High against a FIPS artifact, and for a compliance build the version in the lock is itself part of the claim.
Scope
aws-lc-rs1.16.1 requiresaws-lc-fips-sys ^0.13.1, so the patched release is reachable without movingaws-lc-rsoraws-lc-sys— and neither moves here. The module goesAWS-LC 3.2.0→3.6.0, still the 3.x branch selected by theaws-lc-rsupper bound on the FIPS stack (#1346), but that bound does not establish CMVP validation. Certificate #5314 names static AWS-LC FIPS 3.1.0, not 3.2.0 or 3.6.0.python/Cargo.lock.sdistgets the same bump. Its helper only hascheckandrefresh, andrefreshdeliberately does not bump versions, so it leaves a still-valid0.13.12alone. The update was run withcargo update -p aws-lc-fips-sysagainst the same temporary sdist workspace the script builds, then validated with the script.Verification
Real FIPS build, conda GCC 13 toolchain:
tls::fips_testsassertions pass —0.13.17reports FIPS mode, and the installed rustls provider andClientConfigare still FIPSaws_lc_fips_0_13_*symbols and 0aws_lc_0_38_0_*, so the linking story is unchanged--features fips-tls, 2279 on the default buildFor the compliance owner
The certificate names a specific module version. The public policy for static certificate #5314 names AWS-LC FIPS 3.1.0, not the previously locked 3.2.0 or the patched 3.6.0 selected here. A CMVP-recognized maintenance determination or revised policy covering the exact module is needed before claiming validation. Downgrading to 3.1.0 to fit the published policy would reintroduce CVE-2026-4428: AWS lists FIPS module versions below 3.3.0 as affected.
Relationship to the FIPS stack
Independent. The vulnerable version is on
maintoday, so this is deliberately not stacked on #1346–#1349 — it can merge on its own rather than waiting on that review. Once it lands, rebasing the stack picks it up; the bound in #1346 (>=1.13.2, <1.18) accepts this resolution unchanged.