CVE-2017-11424
published 2017-08-24CVE-2017-11424: In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1…
PriorityP340high7.5CVSS 3.0
AVNACLPRNUINSUCNIHAN
EPSS
1.80%
76.4th percentile
In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | debian_linux | — | — |
| debian | debian_linux | — | — |
| debian | pyjwt | < pyjwt 1.4.2-1.1 (bookworm) | pyjwt 1.4.2-1.1 (bookworm) |
| pyjwt_project | pyjwt | <= 1.5.0 | — |
| pyjwt_project | pyjwt | >= 0 < 1.4.2-1.1 | 1.4.2-1.1 |
| pyjwt_project | pyjwt | >= 0 < 1.4.2-1.1 | 1.4.2-1.1 |
| pyjwt_project | pyjwt | >= 0 < 1.4.2-1.1 | 1.4.2-1.1 |
| pyjwt_project | pyjwt | >= 0 < 1.4.2-1.1 | 1.4.2-1.1 |
| pyjwt_project | pyjwt | >= 0 < 1.5.1 | 1.5.1 |
| pyjwt_project | pyjwt | >= 0 < 2.13.0 | 2.13.0 |
CVSS provenance
nvdv3.07.5HIGHCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
nvdv2.05.0MEDIUMAV:N/AC:L/Au:N/C:N/I:P/A:N
ghsa8.8HIGH
osv7.5HIGH
vendor_debian7.5HIGH
vendor_redhat7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Ubuntu
PyJWT vulnerability
vendor_ubuntu·2017-08-30
CVE-2017-11424 PyJWT vulnerability
Title: PyJWT vulnerability
Summary: PyJWT could be made to crash if it received specially crafted
input.
It was discovered that a vulnerability in PyJWT doesn't check
invalid_strings properly for some public keys. A remote attacker
could take advantage of a key confusion to craft JWTs from scratch.
Instructions: In general, a standard system update will make all the necessary changes.
Red Hat
python-jwt: Incorrect handling of PEM-encoded public keys
vendor_redhat·2017-06-22·CVSS 7.5
CVE-2017-11424 [HIGH] python-jwt: Incorrect handling of PEM-encoded public keys
python-jwt: Incorrect handling of PEM-encoded public keys
In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
Package: python-jwt (Red Hat Enterprise Linux 7) - Not affected
Package: python-jwt (Red Hat Storage 3) - Will not fix
Debian
CVE-2017-11424: pyjwt - In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_k...
vendor_debian·2017·CVSS 7.5
CVE-2017-11424 [HIGH] CVE-2017-11424: pyjwt - In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_k...
In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
Scope: local
bookworm: resolved (fixed in 1.4.2-1.1)
bullseye: resolved (fixed in 1.4.2-1.1)
forky: resolved (fixed in 1.4.2-1.1)
sid: resolved (fixed in 1.4.2-1.1)
trixie: resolved (fixed in 1.4.2-1.1)
GHSA
PyJWKClient: missing scheme allowlist enables CVE-2024-21643-class SSRF + token forgery via file://, ftp://, data: schemes
ghsa·2026-06-15·CVSS 8.8
CVE-2026-48522 [HIGH] CWE-441 PyJWKClient: missing scheme allowlist enables CVE-2024-21643-class SSRF + token forgery via file://, ftp://, data: schemes
PyJWKClient: missing scheme allowlist enables CVE-2024-21643-class SSRF + token forgery via file://, ftp://, data: schemes
> [!NOTE]
> The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. Severity is scored for the scheme-acceptance bug in isolation.
## Summary
PyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib's default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict w
GHSA
PyJWT vulnerable to key confusion attacks
ghsa·2022-05-13
CVE-2017-11424 [HIGH] PyJWT vulnerable to key confusion attacks
PyJWT vulnerable to key confusion attacks
In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
OSV
PyJWT vulnerable to key confusion attacks
osv·2022-05-13
CVE-2017-11424 [HIGH] PyJWT vulnerable to key confusion attacks
PyJWT vulnerable to key confusion attacks
In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
OSV
CVE-2017-11424: In PyJWT 1
osv·2017-08-24·CVSS 7.5
CVE-2017-11424 [HIGH] CVE-2017-11424: In PyJWT 1
In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys [epel-7]
bugzilla·2017-08-17·CVSS 7.5
CVE-2017-11424 [HIGH] CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys [epel-7]
CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys [epel-7]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of epel-7.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
Discussion:
Use the following template to for the '
Bugzilla
CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys
bugzilla·2017-08-17·CVSS 7.5
CVE-2017-11424 [HIGH] CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys
CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys
In PyJWT 1.5.0 and below the 'invalid_strings' check in 'HMACAlgorithm.prepare_key' does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string '-----BEGIN RSA PUBLIC KEY-----' which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
Upstream bug:
https://github.com/jpadilla/pyjwt/pull/277
Discussion:
Created python-jwt tracking bugs for this issue:
Affects: epel-7 [bug 1482530]
Affects: fedora-all [bug 1482531]
---
CVE-2017-12880 was rejected in favour of CVE-2017-11424.
---
Analysi
Bugzilla
CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys [fedora-all]
bugzilla·2017-08-17·CVSS 7.5
CVE-2017-11424 [HIGH] CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys [fedora-all]
CVE-2017-11424 python-jwt: Incorrect handling of PEM-encoded public keys [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported
CTF
cr0wnair / writeup_cr0wnair
ctf_writeups·2021
cr0wnair / writeup_cr0wnair
# UnionCTF - Cr0wnAir
To solve this challenge, we had to exploit a vulnerability in `jpv` which allows us to bypass the regex validation in order to get a JWT. Then, we were able to change the algorithm from `RS256` to `HS256` and forge a new JWT with the public key, a key that we were able to retrieve thanks to a weak `e`.
The source code of the app is given, so let's take a look at it (only what will be interesting for us) :
```js
// routes/checkin.js
const express = require('express');
const jpv = require("jpv");
const jwt = require("jwt-simple");
const path = require("path");
const router = express.Router();
const config = require('../config');
const pattern = {
firstName: /^\w{1,30}$/,
lastName: /^\w{1,30}$/,
passport: /^[0-9]{9}$/,
ffp: /^(|CA[0-9]{8})$/,
extras: [
{sssr: /^(BU
2017-08-24
Published