AWS LC Patch Fixes PKCS#7 Chain Validation in v1.69.0

AWS’ open-source cryptographic library AWS‑LC received a pair of serious PKCS#7 validation fixes in early March 2026 after researchers reported that the library’s PKCS7_verify() routine could incorrectly bypass certificate chain validation for certain multi‑signer PKCS#7 objects, allowing unauthenticated actors to subvert signature-chain checks. The issue (tracked as CVE‑2026‑3336) is joined by a related signature‑validation bypass (CVE‑2026‑3338) and a timing side‑channel in AES‑CCM tag verification (CVE‑2026‑3337). Amazon published an advisory and the AWS‑LC project released a patch in v1.69.0 (with corresponding aws‑lc‑sys and FIPS packages updated) to address these problems. If your build chain, application, or container images include AWS‑LC (including static linking or vendor forks), you must treat this as a supply‑chain vulnerability and act now to locate, test, and update the affected components.

Background / Overview​

AWS‑LC is an open‑source, general‑purpose cryptographic library derived from and maintained in part to serve AWS internal needs and external consumers. It exposes classic TLS, CMS/PKCS#7, and AEAD APIs used by server and client applications, SDKs, embedded devices, and many downstream projects that choose AWS‑LC as a dependency or vendor‑distributed binary.
The three issues disclosed together share a theme: subtle, specification‑level mistakes in cryptographic plumbing that are difficult to detect during ordinary integration testing but can yield large security consequences when they affect certificate verification or signature semantics. The PKCS#7 problems specifically concern how AWS‑LC processes CMS/PKCS#7 objects that include multiple signers and authenticated attributes; a malformed or specially crafted multi‑signer payload could cause the library to accept a chain that should have been rejected.
Key facts you need to know now:

• Affected AWS‑LC versions: from v1.41.0 up to (but not including) v1.69.0.
• Patched release: AWS‑LC v1.69.0 (and matching aws‑lc‑sys v0.38.0, and updated FIPS packages).
• CVE identifiers: CVE‑2026‑3336 (PKCS7_verify certificate chain validation bypass), CVE‑2026‑3338 (PKCS7_verify signature validation bypass), and CVE‑2026‑3337 (AES‑CCM timing side‑channel).
• Severity and scoring: the PKCS7 chain bypass has been scored as High (CVSS ~7.5 in public advisories) and is exploitable without privileges and without user interaction in many contexts.
• Workarounds: for the PKCS7 issues there are no known workarounds—the only reliable mitigation is to upgrade to the patched releases.

---

Why this matters: the attack surface and real‑world impact​

What PKCS#7 / CMS is used for in practice​

PKCS#7 (CMS) is used widely to carry signed and/or encrypted content in many systems:

• Email (S/MIME) signature validation and verification.
• Software and package signing formats that embed CMS payloads.
• Certificate distribution and management protocols (SCEP, some enrollment flows).
• Secure messaging and archival formats.
• Some TLS stacks and appliances use CMS objects for certificate bundles or authority keys.

When a cryptographic library fails to correctly verify certificate chains in these contexts, attackers can craft signed objects that appear valid to the application while actually being forged, enabling:

• Forged signed messages to be accepted.
• Malicious software or packages to pass signature checks.
• Enrollment or certificate import processes to accept attacker‑controlled certificates.
• Interception or modification of signed artifacts without detection.

The specific failure mode: multi‑signer objects and the “except final signer” nuance​

The disclosed flaw is subtle and specific: PKCS7_verify() may bypass certificate chain verification for all but the final signer when processing multi‑signer PKCS#7 objects. In practice this means attackers who can supply multi‑signer CMS objects—whether via an email attachment, package metadata, or a certificate provisioning payload—may be able to construct chains that evade verification checks for some signer entries.
Why that’s dangerous: many implementations assume that each signer listed in a multi‑signer object is independently validated against trust anchors and revocation policies. If one signer entry is not correctly chain‑verified, the application may accept a payload believing all signers were checked, and then act on that trust (execute code, grant authentication, install certs, etc.). The attack can be invisible to logs that only record “PKCS#7 signature verified” without per‑signer audit details.

Possible exploitation scenarios​

• Code or package distribution: an attacker supplies a signed update that includes a multi‑signer CMS object crafted so that an ordinary consumer library will treat it as properly signed even though one or more signers are not trusted.
• S/MIME or document workflows: forged or tampered signed documents accepted by mail clients or document validators.
• Certificate enrollment tools or device onboarding: malicious CMS payloads used in automated flows to install or trust an attacker CA in a device or service.
• Supply‑chain attacks: CI pipelines or artifact repositories that parse and validate PKCS#7 objects using AWS‑LC embedded in tooling could be tricked into accepting attacker artifacts.

---

What AWS and maintainers have done​

AWS published a security bulletin and the AWS‑LC project published a security advisory and a release containing fixes. The patched release, v1.69.0, explicitly lists:

• “Ensure all signer certificate chains are verified” — changes to PKCS7 verification logic.
• Various PKCS7 fixups, improved error reporting, and other related improvements.
• Replacement of unsafe memcmp usage in certain AEAD paths and fixes to authenticated attribute parsing logic.

The disclosure process included credit to an external research team (acknowledged in the advisory), and the maintainers have indicated no customer action is required for managed AWS services—but strongly recommend that applications and products using AWS‑LC update their dependencies.

---

Immediate, practical remediation checklist (for engineers and security teams)​

• Identify (inventory) where AWS‑LC is used in your environment.
• Search code repos, build manifests, SBOMs, CI artifacts, container images, vendor binaries, and static linked executables for aws‑lc, aws‑lc‑sys, or FIPS package versions.
• Don’t forget languages and ecosystems that pull native libs via wrappers (Rust aws-lc-sys, Python wheels with native linkage, Java native agents, etc.).
• Prioritize externally reachable components and signing/enrollment flows.
• Prioritize components that process PKCS#7/CMS objects or perform signature/certificate validation and any artifacts that are consumed from untrusted parties.
• Upgrade to patched versions.
• Update to AWS‑LC v1.69.0 (and corresponding aws‑lc‑sys v0.38.0, AWS‑LC‑FIPS 3.2.0, aws‑lc‑sys‑fips v0.13.12) and rebuild/redeploy.
• Rebuild and redeploy binaries and container images.
• For statically linked apps, rebuild with the patched library; replacing a system package without rebuilding statically linked artifacts will not remediate them.
• Run regression tests that explicitly validate PKCS#7 behaviors.
• Add unit and integration tests that exercise multi‑signer CMS payloads, authenticated attributes, revocation and chain validation failures.
• Review and rotate signing keys / certificates if you detect evidence of abuse.
• If you discover an artifact that was accepted that shouldn’t have been, investigate and consider revoking or reissuing keys/certs used in distribution or enrollment.
• Harden monitoring and detection.
• Add logs or alerts for PKCS#7 parsing errors, unusual signers, or unexpected modification of signed artifacts. Instrument libraries to expose per‑signer verification outcomes where possible.
• Validate third‑party and vendor components.
• Contact vendors who ship products with embedded AWS‑LC and confirm they’ve patched; request CVE mapping or a signed patch schedule.

---

Technical analysis: why this class of bug is hard to catch​

The complexity of CMS/PKCS#7 semantics​

PKCS#7/CMS supports multiple signers, embedded certificate sets, authenticated attributes, detached signatures, and many edge cases around canonicalization and algorithm negotiation. Different implementations historically interpret the specs and edge cases differently, and small state‑machine errors or incorrect early returns during verification loops can silently skip critical checks.
A routine like PKCS7_verify() typically:

• Parses the PKCS#7 structure.
• For each signer, extracts the signerInfo and the certificate (or finds an issuing chain).
• Verifies the signature over the signed attributes or content.
• Verifies that the signer’s certificate chains to a trust anchor and is not revoked.

A logic bug that breaks the loop or conditionally skips chain validation (for example, when multiple signer entries share some fields, or when authenticated attributes are present) will only be triggered by particular combinations of signers that most unit tests do not cover.

The danger of “silent success”​

Security code often returns a simple boolean “verified” flag. This high‑level result hides the per‑signer nuance: an API consumer may assume that a true result means every signer was checked and trusted. Without detailed logs or per‑signer status, silent acceptance is easy to miss until a real exploit triggers a downstream failure.

Timing side‑channels and AEAD verification​

CVE‑2026‑3337 highlights a complementary but different class of risk: timing channels during AES‑CCM tag verification. Even when algorithmic correctness is intact, observable timing differences in cryptographic verification can leak validity bits to attackers able to send many crafted requests and measure response timing precisely. This is particularly relevant for constrained IoT or embedded systems where network jitter is low and operations are repeatable.

---

Detection and testing guidance​

• Add canonical CMS test vectors that cover:
• Single and multi‑signer payloads.
• Authenticated attributes present and absent.
• Detached signature validation.
• Embedded certificate chains with missing intermediates.
• Use fuzz testing against PKCS7_verify() and surrounding parsing logic.
• Use timing analysis tools to check that AEAD tag verification code paths are constant time across valid/invalid tags where feasible.
• Instrument applications to log per‑signer verification outcomes to help post‑incident forensics.

---

Supply‑chain and operational recommendations​

• Maintain and regularly update an SBOM (software bill of materials) at repo and image levels to make rapid discovery of vulnerable components feasible.
• Treat cryptographic library updates as high‑urgency patches: they often fix subtle correctness and security properties not mitigable by configuration alone.
• Avoid long‑term static linking to unpatched vendor binaries; where static linking is necessary, establish a rebuild policy tied to cryptographic CVE notifications.
• For managed cloud customers: verify whether managed services use an affected version internally (many providers flag this for you), but do not assume all managed services are unaffected—your own client or edge components may use AWS‑LC.
• Consider defensive layering: validate signatures using a secondary verification step or a hardened verification library in critical flows (accepting that introduces complexity and potential interoperability concerns).

---

Vendor and maintainer process: what worked and what could be better​

Strengths

• Coordinated disclosure: the advisory acknowledges an external researcher and provides a clear patched release. The maintainers issued a point release that bundles fixes across multiple related issues.
• Clear patch boundaries: v1.69.0 is identified as containing the fixes, making remediation concrete for maintainers and downstream consumers.
• Updated FIPS and wrapped packages were released alongside the main library, reducing friction for FIPS customers.

Risks and shortcomings

• No workaround: while accurate, the absence of any temporary mitigation increases urgency and operational risk for teams that cannot immediately rebuild and redeploy.
• The vulnerability class illustrates the perennial difficulty of exhaustive test coverage for parsing/verification code; downstream consumers may not have test harnesses that exercise unusual PKCS#7 permutations.
• Supply‑chain blindness: many vendors and device makers incorporate cryptographic libraries indirectly; without SBOM discipline, impacted runtime artifacts may linger in production for months.

---

Recommended long‑term actions for architecture and risk teams​

• Treat cryptographic libraries as high‑impact dependencies and bake rapid update pipelines for them into CI/CD: automated rebuilds, test, and staged rollout.
• Invest in cryptographic integration tests that model real‑world CMS/PKCS#7 usage within your product, including negative tests and malformed inputs.
• Maintain an asset inventory and SBOM; invalidate and rebuild images that contain vulnerable versions, but also track where static linking prevents quick fixes.
• When possible, decouple signature validation from trust decisions: verify signatures and separately validate trust anchors with explicit policy layers that log decision rationale.
• For highly sensitive signing infrastructure (code repositories, artifacts, update servers), require multi‑party attestation and secondary verification paths to reduce single‑point‑failure risk.

---

Incident response playbook (if you detect possible exploitation)​

• Isolate affected systems that perform PKCS#7 verification on untrusted inputs.
• Capture forensic artifacts: relevant CMS messages, logs, and network captures.
• Rebuild and redeploy with AWS‑LC v1.69.0 (or vendor‑patched binaries).
• Identify signed artifacts validated during the detection window and re‑verify them with patched verification logic.
• Revoke or reissue affected signing keys if you find evidence of forged artifacts accepted before the patch.
• Notify partners and customers if signed artifacts distributed externally may have been trusted inadvertently.
• Perform a post‑mortem to identify supply‑chain pathways that allowed the vulnerable library to reach production.

---

Conclusion​

CVE‑2026‑3336 and the related CVEs in AWS‑LC are a reminder that cryptographic correctness is brittle and that small implementation mistakes in parsing and verification can have outsized security consequences. The fixes released in AWS‑LC v1.69.0 close the immediate vulnerability, but the broader operational takeaway is unavoidable: you must know where cryptographic libraries live in your environment, be able to rebuild and redeploy affected artifacts quickly, and have tests that exercise realistic cryptographic edge cases.
If your organization uses AWS‑LC directly or indirectly, inventory now, prioritize flows that accept or process PKCS#7/CMS objects, and plan immediate upgrades to the patched releases. Cryptography is unforgiving; when the primitives or verification steps are wrong, trust is broken. Fixing the library is the first step—closing the supply‑chain window that lets stale, vulnerable builds persist in production is the one that will reduce the odds this class of bug yields real world damage.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center