AWS-LC

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 4 Last 12 months 5 Lifetime Certificate validation 40 % Signature verification 30 % Side channel / timing 20 % Memory safety 10 % Latest advisories Loading the feed Overview AWS-LC is Amazon's general-purpose cryptography library, forked from BoringSSL and OpenSSL and FIPS-validated. It is the crypto layer under a large part of the AWS service fleet, and it is now a supported backend for curl and nginx, so it is spreading beyond Amazon's own estate. CVE-2026-3338 is the reference point: PKCS7_verify accepted signatures it should have rejected, a signature validation bypass in a FIPS-validated library. AWS routes these reports to its Vulnerability Disclosure Program on HackerOne, which is open, live and pays nothing. The paid Amazon programme covers consumer retail and devices only. sorona.xyz pays you directly on qualified, reproduced findings. In scope AWS-LC's contributing guide sends security reports to the AWS vulnerability reporting page, and neither that page nor the VDP policy draws a boundary inside the library. Treat the whole aws-lc tree as in scope The X.509 stack end to end: chain building, path validation, name constraints, CRL and OCSP handling, and every parser that touches a certificate before it is trusted The libcrypto surface inherited from the OpenSSL API, including PKCS#7, CMS, PKCS#12, PKCS#8 and the ASN.1 template machinery underneath all of them The TLS implementation carried over from BoringSSL: handshake state, record layer, session resumption and cipher suite negotiation Every symmetric and asymmetric primitive the library ships, covering AES modes and their tag verification, the hash and MAC families, RSA, the elliptic curve implementations, and the post-quantum algorithms The FIPS module: its boundary, its power-on self-tests and its service indicators, where a defect carries a certification consequence on top of the security one The random number generator, its entropy sources, its per-thread state and its fork handling Constant-time behaviour across the library. A timing signal in tag verification or in a scalar multiplication is a reportable defect here rather than a hardening suggestion The bignum layer and the hand-written assembly selected per CPU feature, including paths only reachable on specific microarchitectures The libssl and libcrypto compatibility shims that let curl, nginx and other OpenSSL consumers link against AWS-LC unmodified Out of scope Amazon retail properties, devices and consumer applications, which the AWS VDP policy explicitly sends to Amazon's separate public bug bounty programme AWS service configuration and the operational estate rather than a defect in this library's source Findings in BoringSSL or OpenSSL that AWS-LC has not inherited, which belong with the upstream project Reports filed as public GitHub issues on aws/aws-lc , since the private advisory channel is disabled and AWS asks for reports through its own intake Theoretical weaknesses in a standardised algorithm rather than a defect in this implementation of it Most-valued findings Signature verification that accepts what it should reject. CVE-2026-3338 did exactly that in PKCS7_verify , inside a library carrying a FIPS validation Certificate path validation defects, the densest part of the record here. CVE-2026-4428 got the CRL distribution point scope check wrong, and a separate March 2026 advisory bypassed X.509 name constraints using Unicode and wildcard forms in the common name Timing and other side channel signals in primitive implementations, the class CVE-2026-3337 landed in against AES-CCM tag verification Memory corruption reachable from attacker-supplied ASN.1, certificates or TLS records, the surface inherited wholesale from BoringSSL and OpenSSL Anything that breaks the FIPS module boundary, or that lets a self-test report success over a broken implementation Divergence between AWS-LC and OpenSSL inside a compatibility shim, where a caller's security assumption silently stops holding after a drop-in swap Defects in the post-quantum implementations, which are newer code with far less external review than the classical primitives beside them Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through the AWS Vulnerability Disclosure Program at hackerone.com/aws_vdp, or by email to [email protected] ; CONTRIBUTING.md names both GitHub private vulnerability reporting is switched off on aws/aws-lc , so the advisory button is not an option here even though it is the norm elsewhere in this category The AWS VDP accepts submissions and pays no bounty. Amazon's paid programme is a separate scope of consumer domains and mobile apps with no source code in it, so there is no reward to negotiate Name the build. AWS-LC ships a FIPS branch alongside the general branch and the code paths diverge, so a finding against one may not exist in the other Give the CPU features in play. Several primitives dispatch to different assembly per microarchitecture, and a defect may only be reachable on one of them State whether the defect is inherited from BoringSSL or OpenSSL or is specific to AWS-LC, because an inherited bug needs coordination with the upstream project as well Disclosure Coordinated with the AWS security team through the VDP and published as a GitHub Security Advisory on aws/aws-lc once a release carries the fix. The 2026 record shows fixes going out in small same-day pairs, two on 2 March and two more on 19 March, so plan for an embargo that runs to the next release rather than to a published day count. One of those March advisories shipped with no CVE assigned, so do not treat a CVE as the marker that disclosure has happened. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability