Loading vulnerability…
PyJWT versions prior to 2.14.0 contain an asymmetric-key detection bypass in is_pem_format. The function does not recognize every PEM representation accepted by the cryptography loader. When an application permits both HMAC and asymmetric JWT algorithms and uses an affected mutated public-key PEM encoding as raw verification-key bytes, HMACAlgorithm.prepare_key can misclassify the asymmetric public key as an HMAC secret. An attacker who knows that public key can forge HMAC-signed JWTs that the application accepts as authentic. PyJWT 2.14.0 fixes the detection mismatch.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
The repository contains eight files, including two Python programs and supporting container configuration, dependencies, documentation, and a reproduction RSA public key. utils.py reads the key, signs hardcoded claims with HS256, prints the JWT through logging, and verifies it locally. app.py implements a Flask POST /verify service that uses the same key bytes and accepts both RS256 and HS256. The intended exploit is an asymmetric-key detection bypass: indentation before the PEM END marker causes the vulnerable guard to miss the key, allowing its publicly known bytes to serve as an HMAC secret. This is a basic token-forgery demonstration, not a detection-only script or a remote exploitation framework. The container configuration uses Python 3.9-slim, runs the verifier as a non-root user, and publishes port 8080. requirements.txt pins Flask 2.2.5, Werkzeug 2.2.3, and PyJWT 2.4.0. Notable limitations include the lowercase dockerfile versus the compose reference to Dockerfile, and the absence of cryptography from the declared dependencies, meaning RSA verification and the README's claimed PEM-loader compatibility are not established by the supplied environment. utils.py performs no network submission despite the README's expected-output example suggesting otherwise. Successful exploitation also requires the attacker to reproduce the verifier's exact key bytes, not merely obtain an equivalent RSA public key. The README attributes the issue to CVE-2026-102268 and claims versions before 2.14.0 are affected; those advisory and fix claims were not independently verified. Its mention of CVE-2026-102270 concerns a related ReDoS issue that this code does not exploit. Analysis is static, with no execution performed. Repository URL, git reference, and archive size were not supplied; empty strings and zero represent unavailable metadata, not a measured empty archive.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
5 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A network-accessible, low-complexity vulnerability in PyJWT packages distributed for specified Ubuntu and Debian releases. It requires no privileges or user interaction and can compromise confidentiality and integrity, with no stated availability impact.
A critical PyJWT algorithm-confusion/signature-verification bypass caused by incomplete PEM asymmetric-key detection. Under a mixed HMAC/asymmetric algorithm allow-list and a loader-accepted but regex-missed public-key PEM format, an attacker who knows the public key can forge arbitrary HS256 JWTs.
An important PyJWT authentication-bypass vulnerability caused by inconsistent PEM recognition. In applications that mix HMAC and asymmetric JWT algorithms, an attacker who knows the asymmetric public key may forge authenticated HMAC JWTs using a mutated PEM encoding.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.