fix(deps): update dependency cryptography to v46.0.6 [security]#1760
fix(deps): update dependency cryptography to v46.0.6 [security]#1760oep-renovate[bot] wants to merge 1 commit intomainfrom
Conversation
JiwaniZakir
left a comment
There was a problem hiding this comment.
The change in libs/spicedb_tools/uv.lock correctly bumps cryptography from 46.0.5 to 46.0.6 and updates all corresponding wheel hashes and sdist entries for the full platform matrix (manylinux, musllinux, macOS, Windows, armv7l, ppc64le, etc.). It's worth verifying whether any other uv.lock or requirements*.txt files elsewhere in the repo pin cryptography independently — a single lock file update won't cover sibling services or libraries that manage their own dependency sets. Additionally, since this is tagged as a security fix, it would strengthen the PR to reference the specific CVE(s) addressed by 46.0.6 in the commit message or PR description, so the audit trail is clear without requiring reviewers to cross-reference the upstream changelog.
Signed-off-by: oep-renovate[bot] <212772560+oep-renovate[bot]@users.noreply.github.com>
41fdd14 to
b74d9a5
Compare
This PR contains the following updates:
==46.0.5→==46.0.646.0.5→46.0.6cryptography has incomplete DNS name constraint enforcement on peer names
CVE-2026-34073 / GHSA-m959-cc7f-wv43
More information
Details
Summary
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.comto validate against a wildcard leaf certificate for*.example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint forbar.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. Consequently, we consider this a medium-to-low impact severity.
See CVE-2025-61727 for a similar bypass in Go's
crypto/x509.Remediation
Users should upgrade to 46.0.6 or newer.
Attribution
Reporter: @1seal
Severity
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:UReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pyca/cryptography (cryptography)
v46.0.6Compare Source
Configuration
📅 Schedule: (UTC)
🚦 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.
This PR has been generated by Renovate Bot.