CVE-2026-102273 is a high-severity (CVSS 7.4) CWE-347 vulnerability in pyjwt. A fix is available for pyjwt — see the affected versions and patch details below.
PyJWT accepts public JWK containers as HMAC secrets
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-102273.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-102273 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
pyjwtReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when
an application mixes symmetric and asymmetric algorithms in one verification
path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it
is wrapped in a JWKS object, nested in an array, or represented in another
container form that does not expose a top-level kty member.
Impact
An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:
- allows both HS* and asymmetric algorithms;
- passes raw public JWK/JWKS JSON as
key=; and - uses that same value as the HMAC secret.
This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT's algorithm-selection guidance.
Fix status
The fix is on master in commit 801cd12 (fix: reject public JWK container HMAC keys). HMACAlgorithm.prepare_key now rejects public JWK members found in
objects, arrays, nested containers, BOM/UTF variants, and recursion-limit
inputs. It also recognizes escaped JSON member names without treating ordinary
string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.
The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were skipped by the project configuration. A fresh independent Astra/max security review accepted the final diff with no blocking findings.
The affected range is = 2.13.0. The fix is on the unreleased development
branch; the patched version will be recorded when a released 2.x version
containing the fix is available. This advisory is being moved to draft pending
that release.
Reporter credit
Credit: Charles Vosburgh / Trilobyte.
Original report
The original report and reproduction package are retained in the private advisory record.
Maintainer update — 2026-09-11
The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | pyjwt | ≥ 2.13.0&&< 2.14.0 | 2.14.0pip install --upgrade 'pyjwt==2.14.0' |
Affected Products
pyjwtpyjwt_projectDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pyjwt, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update pyjwt to 2.14.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-102273 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Red Hat rates this vulnerability as Important because an attacker with access to a public verification key can forge cryptographic tokens to bypass authentication, allowing impersonation of privileged users and unauthorized access to protected application resources. Exploitation is limited to environments where…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2026-102273 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat AI Inference Server 3.5 | rhaii/vllm-rocm-rhel9:1791425869 | RHSA-2026:82059 |
| Red Hat AI Inference Server 3.5 | rhaii/vllm-gaudi-rhel9:1791427182 | RHSA-2026:82061 |
| Red Hat Ansible Automation Platform 2.7 | ansible-automation-platform-27/ee-supported-rhel9:1791258340 | RHSA-2026:79378 |
Frequently Asked Questions
Is CVE-2026-102273 in your dependencies?
Find it across PyPI, including transitive dependencies.