Skip to content

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented May 18, 2023

This PR contains the following updates:

Package Change Age Confidence
cryptography (changelog) ^3.4.7^46.0.0 age confidence
cryptography (changelog) ==3.4.7==46.0.5 age confidence

GitHub Vulnerability Alerts

CVE-2023-23931

Previously, Cipher.update_into would accept Python objects which implement the buffer protocol, but provide only immutable buffers:

>>> outbuf = b"\x00" * 32
>>> c = ciphers.Cipher(AES(b"\x00" * 32), modes.ECB()).encryptor()
>>> c.update_into(b"\x00" * 16, outbuf)
16
>>> outbuf
b'\xdc\x95\xc0x\xa2@​\x89\x89\xadH\xa2\x14\x92\x84 \x87\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

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 update_into was originally introduced in cryptography 1.8.

CVE-2023-0286

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.

GHSA-5cpq-8wj7-hf2v

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.

GHSA-jm77-qphf-c4w8

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.

GHSA-v8gr-m533-ghj9

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.

CVE-2023-49083

Summary

Calling load_pem_pkcs7_certificates or load_der_pkcs7_certificates could lead to a NULL-pointer dereference and segfault.

PoC

Here is a Python code that triggers the issue:

from cryptography.hazmat.primitives.serialization.pkcs7 import load_der_pkcs7_certificates, load_pem_pkcs7_certificates

pem_p7 = b"""
-----BEGIN PKCS7-----
MAsGCSqGSIb3DQEHAg==
-----END PKCS7-----
"""

der_p7 = b"\x30\x0B\x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x07\x02"

load_pem_pkcs7_certificates(pem_p7)
load_der_pkcs7_certificates(der_p7)

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.

CVE-2023-50782

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.

CVE-2024-0727

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: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().

We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.

CVE-2026-26007

Vulnerability Summary

The public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() 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 = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). 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 Automated Vulnerability Discovery Engine

Release Notes

pyca/cryptography (cryptography)

v46.0.5

Compare Source

v46.0.4

Compare Source

v46.0.3

Compare Source

v46.0.2

Compare Source

v46.0.1

Compare Source

v46.0.0

Compare Source

v45.0.7

Compare Source

v45.0.6

Compare Source

v45.0.5

Compare Source

v45.0.4

Compare Source

v45.0.3

Compare Source

v45.0.2

Compare Source

v45.0.1

Compare Source

v45.0.0

Compare Source

v44.0.3

Compare Source

v44.0.2

Compare Source

v44.0.1

Compare Source

v44.0.0

Compare Source

v43.0.3

Compare Source

v43.0.1

Compare Source

v43.0.0

Compare Source

v42.0.8

Compare Source

v42.0.7

Compare Source

v42.0.6

Compare Source

v42.0.5

Compare Source

v42.0.4

Compare Source

v42.0.3

Compare Source

v42.0.2

Compare Source

v42.0.1

Compare Source

v42.0.0

Compare Source

v41.0.7

Compare Source

v41.0.6

Compare Source

v41.0.5

Compare Source

v41.0.4

Compare Source

v41.0.3

Compare Source

v41.0.2

Compare Source

v41.0.1

Compare Source

v41.0.0

Compare Source

v40.0.2

Compare Source

v40.0.1

Compare Source

v40.0.0

Compare Source

v39.0.2

Compare Source

v39.0.1

Compare Source

v39.0.0

Compare Source

v38.0.4

Compare Source

v38.0.3

Compare Source

v38.0.2

Compare Source

v38.0.1

Compare Source

v38.0.0

Compare Source

v37.0.4

Compare Source

v37.0.3

Compare Source

v37.0.2

Compare Source

v37.0.1

Compare Source

v37.0.0

Compare Source

v36.0.2

Compare Source

v36.0.1

Compare Source

v36.0.0

Compare Source

v35.0.0

Compare Source

v3.4.8

Compare Source


Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from 6f1a080 to b25da18 Compare June 3, 2023 08:56
@renovate renovate bot changed the title Update dependency cryptography to v39 [SECURITY] Update dependency cryptography to v41 [SECURITY] Jun 3, 2023
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from b25da18 to 7c1fdf0 Compare July 15, 2023 05:16
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from 7c1fdf0 to c69c23e Compare August 3, 2023 11:56
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from c69c23e to 16ec85c Compare September 22, 2023 02:04
@renovate renovate bot changed the title Update dependency cryptography to v41 [SECURITY] Update dependency cryptography to v41 [SECURITY] - autoclosed Nov 1, 2023
@renovate renovate bot closed this Nov 1, 2023
@renovate renovate bot deleted the renovate/pypi-cryptography-vulnerability branch November 1, 2023 02:36
@renovate renovate bot changed the title Update dependency cryptography to v41 [SECURITY] - autoclosed Update dependency cryptography to v41 [SECURITY] Nov 2, 2023
@renovate renovate bot reopened this Nov 2, 2023
@renovate renovate bot restored the renovate/pypi-cryptography-vulnerability branch November 2, 2023 08:41
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from 16ec85c to b007bb4 Compare November 2, 2023 08:43
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from b007bb4 to b116096 Compare November 30, 2023 02:41
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from b116096 to 09773c3 Compare February 6, 2024 02:07
@renovate renovate bot changed the title Update dependency cryptography to v41 [SECURITY] Update dependency cryptography [SECURITY] Feb 6, 2024
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from 09773c3 to e73dc5e Compare February 7, 2024 05:04
@renovate renovate bot changed the title Update dependency cryptography [SECURITY] Update dependency cryptography to v42 [SECURITY] Feb 7, 2024
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from e73dc5e to d2320ca Compare February 18, 2024 08:35
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from d2320ca to d2c5a91 Compare August 11, 2025 23:37
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch 2 times, most recently from bac84ae to a55100b Compare November 25, 2025 19:37
@renovate renovate bot force-pushed the renovate/pypi-cryptography-vulnerability branch from a55100b to 7f1e2b8 Compare February 11, 2026 08:07
@renovate renovate bot changed the title Update dependency cryptography to v42 [SECURITY] Update dependency cryptography to v46 [SECURITY] Feb 11, 2026
@renovate
Copy link
Contributor Author

renovate bot commented Feb 11, 2026

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: poetry.lock
Creating virtualenv autocsr-EwhKHD6C-py3.14 in /home/ubuntu/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies...


The current project's Python requirement (>=3.7,<4.0) is not compatible with some of the required packages Python requirement:
  - cryptography requires Python !=3.9.0,!=3.9.1,>=3.8, so it will not be satisfied for Python >=3.7,<3.8 || 3.9.0 || 3.9.1
  - cryptography requires Python !=3.9.0,!=3.9.1,>=3.8, so it will not be satisfied for Python >=3.7,<3.8 || 3.9.0 || 3.9.1
  - cryptography requires Python !=3.9.0,!=3.9.1,>=3.8, so it will not be satisfied for Python >=3.7,<3.8 || 3.9.0 || 3.9.1
  - cryptography requires Python !=3.9.0,!=3.9.1,>=3.8, so it will not be satisfied for Python >=3.7,<3.8 || 3.9.0 || 3.9.1
  - cryptography requires Python !=3.9.0,!=3.9.1,>=3.8, so it will not be satisfied for Python >=3.7,<3.8 || 3.9.0 || 3.9.1
  - cryptography requires Python !=3.9.0,!=3.9.1,>=3.8, so it will not be satisfied for Python >=3.7,<3.8 || 3.9.0 || 3.9.1

Because no versions of cryptography match >46.0.0,<46.0.1 || >46.0.1,<46.0.2 || >46.0.2,<46.0.3 || >46.0.3,<46.0.4 || >46.0.4,<46.0.5 || >46.0.5,<47.0.0
 and cryptography (46.0.0) requires Python !=3.9.0,!=3.9.1,>=3.8, cryptography is forbidden.
And because cryptography (46.0.1) requires Python !=3.9.0,!=3.9.1,>=3.8
 and cryptography (46.0.2) requires Python !=3.9.0,!=3.9.1,>=3.8, cryptography is forbidden.
And because cryptography (46.0.3) requires Python !=3.9.0,!=3.9.1,>=3.8
 and cryptography (46.0.4) requires Python !=3.9.0,!=3.9.1,>=3.8, cryptography is forbidden.
So, because cryptography (46.0.5) requires Python !=3.9.0,!=3.9.1,>=3.8
 and autocsr depends on cryptography (^46.0.0), version solving failed.

  • Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties
    
    For cryptography, a possible solution would be to set the `python` property to ">=3.8,<3.9.0 || >3.9.0,<3.9.1 || >3.9.1,<4.0"
    For cryptography, a possible solution would be to set the `python` property to ">=3.8,<3.9.0 || >3.9.0,<3.9.1 || >3.9.1,<4.0"
    For cryptography, a possible solution would be to set the `python` property to ">=3.8,<3.9.0 || >3.9.0,<3.9.1 || >3.9.1,<4.0"
    For cryptography, a possible solution would be to set the `python` property to ">=3.8,<3.9.0 || >3.9.0,<3.9.1 || >3.9.1,<4.0"
    For cryptography, a possible solution would be to set the `python` property to ">=3.8,<3.9.0 || >3.9.0,<3.9.1 || >3.9.1,<4.0"
    For cryptography, a possible solution would be to set the `python` property to ">=3.8,<3.9.0 || >3.9.0,<3.9.1 || >3.9.1,<4.0"

    https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies,
    https://python-poetry.org/docs/dependency-specification/#using-environment-markers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants