Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
24 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
If an intermediate constrained CA permits the DNS name foo.example.com, and the leaf certificate has a wildcard in its DNS SAN of .example.com, python-cryptography's verifier accepts which allows escaping outside of the permitted names. PoC Impact Acceptance of invalid certificate chain.
Recommended action: Upgrade to 49.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack. This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission. Details The core issue arises in the recursive nature of buildchaininner, which does not de-duplicate against previously analyzed candidates. A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By…
Recommended action: Upgrade to 49.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pkcs7decryptder, pkcs7decryptpem, and pkcs7decryptsmime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1,…
Recommended action: Upgrade to 50.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in wheels prior to cryptograph 48.01 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20260609.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 48.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If a non-contiguous buffer was passed to APIs which accepted Python buffers (e.g. `Hash.update()`), this could lead to buffer overflows. For example: ```python h = Hash(SHA256()) b.update(buf[::-1]) ``` would read past the end of the buffer on Python >3.11
Recommended action: Upgrade to 46.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named bar.example.com to validate against a wildcard leaf certificate for .example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for bar.example.com. This behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead. In practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems.…
Recommended action: Upgrade to 46.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Summary The publickeyfromnumbers (or EllipticCurvePublicNumbers.publickey()), EllipticCurvePublicNumbers.publickey(), loadderpublickey() and loadpempublickey() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victimprivatekey]P via ECDH, this leaks information about victimprivatekey mod (smallsubgrouporder). For curves with cofactor 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. Credit This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab - Atuin…
Recommended action: Upgrade to 46.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20250211.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 44.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 37.0.0-43.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20240903.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 43.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If pkcs12.serializekeyandcertificates is called with both: 1. A certificate whose public key did not match the provided private key 2. An encryptionalgorithm with hmachash set (via PrivateFormat.PKCS12.encryptionbuilder().hmachash(...) Then a NULL pointer dereference would occur, crashing the Python process. This has been resolved, and now a ValueError is properly raised. Patched in https://github.com/pyca/cryptography/pull/10423
Recommended action: Upgrade to 42.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
Recommended action: Upgrade to 42.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL to crash leading to a potential Denial of Service attack Impact summary: Applications loading files in the PKCS12 format from untrusted sources might terminate abruptly. A file in PKCS12 format can contain certificates and keys and may come from an untrusted source. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly check for this case. This can lead to a NULL pointer dereference that results in OpenSSL crashing. If an application processes PKCS12 files from an untrusted source using the OpenSSL APIs then that application will be vulnerable to this issue. OpenSSL APIs that are vulnerable to this are: PKCS12parse(), PKCS12unpackp7data(), PKCS12unpackp7encdata(), PKCS12unpackauthsafes() and PKCS12newpass(). We have also fixed a similar issue in SMIMEwritePKCS7(). However since this function is related to writing data we do not consider it security significant. The FIPS…
Recommended action: Upgrade to 42.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Calling loadpempkcs7certificates or loadderpkcs7certificates could lead to a NULL-pointer dereference and segfault. PoC Here is a Python code that triggers the issue: Impact Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.
Recommended action: Upgrade to 41.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 2.5-41.0.3 are vulnerable to several security issues. More details about the vulnerabilities themselves can be found in https://www.openssl.org/news/secadv/20230908.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 41.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 0.8-41.0.2 are vulnerable to several security issues. More details about the vulnerabilities themselves can be found in https://www.openssl.org/news/secadv/20230731.txt, https://www.openssl.org/news/secadv/20230719.txt, and https://www.openssl.org/news/secadv/20230714.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 41.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
Recommended action: Upgrade to 41.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 0.5-40.0.2 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://www.openssl.org/news/secadv/20230530.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 41.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 0.8.1-39.0.0 are vulnerable to a security issue. More details about the vulnerabilities themselves can be found in https://www.openssl.org/news/secadv/20221213.txt and https://www.openssl.org/news/secadv/20230207.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 39.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Previously, Cipher.updateinto would accept Python objects which implement the buffer protocol, but provide only immutable buffers: This would allow immutable objects (such as bytes) to be mutated, thus violating fundamental rules of Python. This is a soundness bug -- it allows programmers to misuse an API, it cannot be exploited by attacker controlled data alone. This now correctly raises an exception. This issue has been present since updateinto was originally introduced in cryptography 1.8.
Recommended action: Upgrade to 39.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 37.0.0-38.0.3 are vulnerable to a number of security issues. More details about the vulnerabilities themselves can be found in https://www.openssl.org/news/secadv/20221101.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
Recommended action: Upgrade to 38.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HKDF in cryptography before 1.5.3 returns an empty byte-string if used with a length less than algorithm.digestsize.
Recommended action: Upgrade to 1.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. When certain sequences of update() calls with large values (multiple GBs) for symetric encryption or decryption occur, it's possible for an integer overflow to happen, leading to mishandling of buffers. This is patched in version 3.3.2 and newer.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
RSA decryption was vulnerable to Bleichenbacher timing vulnerabilities, which would impact people using RSA decryption in online scenarios. This is fixed in cryptography 3.2.
Recommended action: Upgrade to 3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in python-cryptography versions between =1.9.0 and <2.3. The finalizewithtag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalizewithtag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause key leakage.
Recommended action: Upgrade to 2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.