Skip to content

fix(deps): update dependency pyjwt to v2.12.0 [security] #589

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
renovate wants to merge 1 commit into
base: main
Choose a base branch
from
+1 −1
Open

fix(deps): update dependency pyjwt to v2.12.0 [security] #589

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ dependencies = [
"httpx~=0.28.1",
"pydantic>=2.10.4",
"pyjwt>=2.10.0 ; python_full_version >= '3.9'",
Copy link
Contributor

@greptile-apps greptile-apps bot Mar 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Python 3.9+ lower bound still allows vulnerable versions

The Python 3.9+ specifier >=2.10.0 was not tightened to >=2.12.0. While a fresh lock file regeneration would likely resolve to 2.12.0, the loose lower bound means a user performing an unconstrained install (e.g., without the lock file, or in a mixed environment) could still receive PyJWT 2.10.x or 2.11.x — both of which are vulnerable to CVE-2026-32597.

Consider tightening this to >=2.12.0 to close this gap:

Suggested change
"pyjwt>=2.10.0 ; python_full_version >= '3.9'",
"pyjwt>=2.12.0 ; python_full_version >= '3.9'",

"pyjwt>=2.9.0,<2.10 ; python_full_version == '3.8.*'",
"pyjwt>=2.12,<2.13; python_full_version == '3.8.*'",
Copy link
Contributor

@greptile-apps greptile-apps bot Mar 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PyJWT 2.12 does not support Python 3.8

The original <2.10 upper bound was intentional: PyJWT 2.10.0 dropped Python 3.8 support (see #1007 — "Drop support for Python 3.8 (EOL)"). Changing the constraint to >=2.12,<2.13 while keeping the python_full_version == '3.8.*' marker will cause a dependency resolution failure for Python 3.8 users because no version in the [2.12, 2.13) range supports Python 3.8.

Running uv sync or pip install on Python 3.8 will fail with something like: "No solution found when resolving dependencies: Because pyjwt (>=2.12,<2.13) requires Python >=3.9 and workos depends on pyjwt>=2.12,<2.13 for Python==3.8.*, no version of workos can be installed on Python 3.8."

Since the CVE fix is only available in 2.12.x which requires Python 3.9+, the project must choose between:

  1. Dropping Python 3.8 support entirely in workos-python (Python 3.8 has been EOL since October 2024)
  2. Keeping the <2.10 cap for Python 3.8 and accepting Python 3.8 users are exposed to CVE-2026-32597

Comment on lines 14 to +15
Copy link
Contributor

@greptile-apps greptile-apps bot Mar 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uv.lock not updated — security fix not applied

The uv.lock file was not regenerated as part of this PR. It still pins:

  • pyjwt 2.9.0 for python_full_version < '3.9'
  • pyjwt 2.10.1 for python_full_version >= '3.9'

Both versions are vulnerable to CVE-2026-32597. Anyone running uv sync (the standard install path) will still receive the old vulnerable versions, making this security fix effectively inert until the lock file is regenerated.

The [package.metadata] section in uv.lock also still reflects the old constraint >=2.9.0,<2.10 for Python 3.8.

The lock file must be regenerated (uv lock) and committed alongside this change for the security fix to actually take effect. The PR table in the description notes 2.10.1 → 2.12.0, implying both the specifier and the resolved lock version should be updated together.

]

[project.urls]
Expand Down
Loading