fix(deps): allow cryptography 49.x to clear two open CVEs - #315
Merged
Merged
Conversation
cryptography was pinned to ^46.0.7 (>=46.0.7,<47.0.0), which is inside the vulnerable range for both of these and three majors below the fix, so Dependabot could not resolve an upgrade: - CVE-2026-69249 (high) duplicate self-signed intermediates cause exponential certificate path-building - CVE-2026-69248 (medium) verifier accepts wildcard DNS names, allowing escape from permittedSubtrees Both are fixed in 49.0.0. Dependabot has failed on this dependency on every run since 2026-06-17 (10 consecutive failures) because the constraint made the security update unsatisfiable, so this will not self-heal without widening it. The constraint lives in .speakeasy/gen.yaml under python.additionalDependencies.main — that is the source of truth the generator writes pyproject.toml from, so both are updated here to keep them consistent and to make the fix effective before the next regen. Verified against 49.0.0: the SDK's whole cryptography surface is serialization.load_pem_private_key and hashes.SHA256 in src/gr4vy/auth.py, both unchanged across 47-49. Resolved the runtime set (PyJWT 2.14.0, python-jose 3.5.0, cryptography 49.0.0) and exercised the ES512 thumbprint, jwt.encode and jwt.decode paths successfully. Neither CVE is reachable from this SDK in practice — both are in X.509 path building and name constraints, which it never invokes — but the vulnerable version still ships in the dependency tree and will be flagged by merchants' scanners. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
🧪 Test coverage
Endpoint reach is measured from HTTP requests actually sent by the suite (see tests/utils/client.py). See TESTING.md. |
cbetta
marked this pull request as ready for review
September 15, 2026 09:52
cbetta
added a commit
that referenced
this pull request
Sep 15, 2026
## What Moves `cryptography` from `^49.0.0` to `^50.0.1`. Follow-up to #315, which took `^49.0.0` as the minimal change that cleared the two open CVEs. 50.0.1 is the current release, so this takes the extra runway rather than sitting one major behind from the day it landed. ## No security urgency 49.x is **already outside** the vulnerable range (`>=42.0.0, <=48.0.0`) for both CVE-2026-69249 and CVE-2026-69248, and the alerts are closed. 50.0.1 carries no known advisories. This is purely about not needing another bump shortly — merge it whenever suits. ## Speakeasy-managed Same as #315: the constraint is set in `.speakeasy/gen.yaml` under `python.additionalDependencies.main`, with the generated `pyproject.toml` kept in step. Worth noting as evidence the approach is sound — generation **2.4.11 landed on top of #315 and preserved the `^49.0.0` value**, so `gen.yaml` is confirmed as the durable place for this. ## Verification Resolved the runtime set cleanly (`cryptography 50.0.1`, `PyJWT 2.14.0`, `python-jose 3.5.0`) and exercised the real auth paths from `src/gr4vy/auth.py` against 50.0.1 — ES512 key load, JWK thumbprint, `jwt.encode` and `jwt.decode` all pass. `cryptography` 50 requires Python ≥3.9; this SDK requires ≥3.10. The SDK's whole surface here is `serialization.load_pem_private_key` and `hashes.SHA256`, both unchanged across 49→50. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Widens the
cryptographyconstraint from^46.0.7to^49.0.0, closing two open Dependabot alerts.permittedSubtreesVulnerable range is
>=42.0.0, <=48.0.0; both are fixed in 49.0.0.Why it needs doing by hand
The old pin (
>=46.0.7,<47.0.0) sat inside the vulnerable range and three majors below the fix, which made the security update unsatisfiable. Dependabot has therefore failed on this dependency on every run since 2026-06-17 — 10 consecutive failures, alwayspip in /. for cryptography. It will not self-heal until the constraint is widened.Speakeasy-managed — where the change belongs
The real source of truth is
.speakeasy/gen.yamlunderpython.additionalDependencies.main; the generator writespyproject.tomlfrom it. Editing onlypyproject.tomlwould be reverted by the next regen.Both files are updated here:
gen.yamlso the change survives regeneration, andpyproject.tomlso the fix is effective immediately rather than waiting for the next generation cycle.Verification
The SDK's entire use of
cryptographyis two calls insrc/gr4vy/auth.py—serialization.load_pem_private_keyandhashes.SHA256— both unchanged across 47→49.Resolved the runtime set cleanly (
cryptography 49.0.0,PyJWT 2.14.0,python-jose 3.5.0;python-joserequires onlycryptography>=3.4.0, no upper cap) and exercised the real auth paths against 49.0.0: ES512 key load, JWK thumbprint,jwt.encodeandjwt.decodeall pass.cryptography49 requires Python ≥3.9; this SDK requires ≥3.10.Risk
Low. Neither CVE is reachable from this SDK in practice — both live in X.509 path building and name constraints, which it never invokes. The reason to fix is that the vulnerable version still ships in the dependency tree and will be flagged by merchants' own scanners.
Note
cryptography50.0.1 is already out and also unaffected. I kept to^49.0.0as the minimal change that closes both CVEs and matches the existing caret convention — happy to go to 50.x instead if you'd prefer the extra runway.🤖 Generated with Claude Code