RUSTSEC-2026-0047: PKCS7_verify Signature Validation Bypass in AWS-LC

[github-actions]

Details
Package	aws-lc-sys
Version	0.37.1
URL	https://aws.amazon.com/security/security-bulletins/2026-005-AWS
Patched Versions	>=0.38.0
Unaffected Versions	<0.24.0
Aliases	CVE-2026-3338, GHSA-hfpc-8r3f-gw53, GHSA-jchq-39cv-q4wj

Improper signature validation in PKCS7_verify() in AWS-LC allows an
unauthenticated user to bypass signature verification when processing PKCS7
objects with Authenticated Attributes.

Customers of AWS services do not need to take action. aws-lc-sys contains
code from AWS-LC. Applications using aws-lc-sys should upgrade to the most
recent release of aws-lc-sys.

There is no workaround; applications using aws-lc-sys should upgrade to the
most recent release of aws-lc-sys.

[traycerai]

Plan

Observations

The project uses aws-lc-sys 0.37.1 (locked in Cargo.lock) as a transitive dependency pulled in through aws-lc-rs 1.16.0, which is itself a transitive dependency of reqwest 0.13.2 (via rustls). The deny.toml already has a cmake wrapper exception for aws-lc-sys, so no changes are needed there. The advisory section in deny.toml does not yet ignore or acknowledge RUSTSEC-2026-0047.

Approach

Since aws-lc-sys is a transitive dependency (not directly declared in Cargo.toml), the fix is to force Cargo to resolve it to >=0.38.0 by bumping aws-lc-rs to its latest patched release (1.16.2), which depends on aws-lc-sys 0.38.0. This is done via a [patch] or by adding a direct aws-lc-rs dependency override. The cleanest approach for a transitive dep is to add a [patch.crates-io] entry or simply add aws-lc-rs as a direct dependency with a minimum version constraint, then regenerate the lock file.

Implementation Steps

1. Add a minimum-version override for aws-lc-rs in Cargo.toml

In file:Cargo.toml, under the [dependencies] section, add an explicit direct dependency on aws-lc-rs pinned to >=1.16.2 (the first release that pulls in aws-lc-sys 0.38.0):

aws-lc-rs = "1.16.2"

This forces Cargo's resolver to select aws-lc-rs 1.16.2 (or newer), which in turn requires aws-lc-sys >=0.38.0, eliminating the vulnerable 0.37.1.

Why not [patch.crates-io]? A direct dependency version bump is simpler and more idiomatic when the goal is just to raise the minimum version of a transitive dep. [patch] is reserved for replacing a crate with a local or git source.

2. Regenerate Cargo.lock

Run cargo update -p aws-lc-rs -p aws-lc-sys (or a full cargo update) so that Cargo.lock is updated to reflect aws-lc-rs 1.16.2 and aws-lc-sys 0.38.0.

3. Verify the advisory is resolved in deny.toml

After updating, run cargo deny check advisories to confirm RUSTSEC-2026-0047 no longer fires. No changes to file:deny.toml should be needed — the advisory is resolved by the version bump, not by adding an ignore entry (which would be the wrong approach for a real security vulnerability).

4. Confirm the dependency chain

After the lock file is regenerated, verify the chain looks like:

graph TD
    A[ruley] --> B[reqwest 0.13.2]
    A --> C[aws-lc-rs 1.16.2]
    B --> C
    C --> D[aws-lc-sys 0.38.0 ✓ patched]

Loading

The aws-lc-sys entry in Cargo.lock should now show version 0.38.0 instead of 0.37.1.

Import In IDE

🤖 Prompt for AI Agents

## Observations

The project uses `aws-lc-sys` **0.37.1** (locked in `Cargo.lock`) as a transitive dependency pulled in through `aws-lc-rs` **1.16.0**, which is itself a transitive dependency of `reqwest` **0.13.2** (via `rustls`). The `deny.toml` already has a `cmake` wrapper exception for `aws-lc-sys`, so no changes are needed there. The advisory section in `deny.toml` does **not** yet ignore or acknowledge RUSTSEC-2026-0047.

## Approach

Since `aws-lc-sys` is a transitive dependency (not directly declared in `Cargo.toml`), the fix is to force Cargo to resolve it to `>=0.38.0` by bumping `aws-lc-rs` to its latest patched release (`1.16.2`), which depends on `aws-lc-sys` `0.38.0`. This is done via a `[patch]` or by adding a direct `aws-lc-rs` dependency override. The cleanest approach for a transitive dep is to add a `[patch.crates-io]` entry or simply add `aws-lc-rs` as a direct dependency with a minimum version constraint, then regenerate the lock file.

## Implementation Steps

### 1. Add a minimum-version override for `aws-lc-rs` in `Cargo.toml`

In `file:Cargo.toml`, under the `[dependencies]` section, add an explicit direct dependency on `aws-lc-rs` pinned to `>=1.16.2` (the first release that pulls in `aws-lc-sys` `0.38.0`):

```
aws-lc-rs = "1.16.2"
```

This forces Cargo's resolver to select `aws-lc-rs` `1.16.2` (or newer), which in turn requires `aws-lc-sys` `>=0.38.0`, eliminating the vulnerable `0.37.1`.

> **Why not `[patch.crates-io]`?** A direct dependency version bump is simpler and more idiomatic when the goal is just to raise the minimum version of a transitive dep. `[patch]` is reserved for replacing a crate with a local or git source.

### 2. Regenerate `Cargo.lock`

Run `cargo update -p aws-lc-rs -p aws-lc-sys` (or a full `cargo update`) so that `Cargo.lock` is updated to reflect `aws-lc-rs` `1.16.2` and `aws-lc-sys` `0.38.0`.

### 3. Verify the advisory is resolved in `deny.toml`

After updating, run `cargo deny check advisories` to confirm RUSTSEC-2026-0047 no longer fires. No changes to `file:deny.toml` should be needed — the advisory is resolved by the version bump, not by adding an `ignore` entry (which would be the wrong approach for a real security vulnerability).

### 4. Confirm the dependency chain

After the lock file is regenerated, verify the chain looks like:

```mermaid
graph TD
    A[ruley] --> B[reqwest 0.13.2]
    A --> C[aws-lc-rs 1.16.2]
    B --> C
    C --> D[aws-lc-sys 0.38.0 ✓ patched]
```

The `aws-lc-sys` entry in `Cargo.lock` should now show version `0.38.0` instead of `0.37.1`.

---

Execution Information

Branch: main
Commit: a396814

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.