CVE-2026-102268

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

Prerequisites (both conditions must hold; both are deployment properties, not attacker-controlled at request time):

• The jwt.decode allow-list mixes an HMAC algorithm with an asymmetric one, e.g. algorithms=["ES256", "HS256"] (the RFC 8725 footgun the guard exists to backstop).
• The verification key is passed as raw PEM text/bytes on the non-PyJWK path, in a byte-form that cryptography's loader accepts but PyJWT's is_pem_format regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.

The attacker additionally needs the public verification key, which is public by definition, and cryptography must be installed.

The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when is_pem_format() recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.

Summary

A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT's is_pem_format() return False while cryptography.load_pem_public_key() accepts the identical bytes. The asymmetric-key rejection in HMACAlgorithm.prepare_key is skipped, the public key becomes the HMAC secret, and an attacker who knows the public key mints a valid HS256 token — universal forgery — whenever the verify allow-list mixes an HMAC and an asymmetric algorithm.

Details

At jwt/algorithms.py:331-335, HMACAlgorithm.prepare_key contains the sole family-mismatch guard:

if is_pem_format(key_bytes) or is_ssh_key(key_bytes):
    raise InvalidKeyError(
        "The specified key is an asymmetric key or x509 certificate and"
        " should not be used as an HMAC secret."
    )

If neither predicate fires, :357 returns key_bytes unchanged — the PEM text is used directly as the HMAC secret.

is_pem_format (jwt/utils.py:116-127) is bool(_PEM_RE.search(key)), where _PEM_RE requires ----[- ]BEGIN (...)[- ]----\r?\n, then .+?\r?\n, then the END marker. The LF in each \r?\n is mandatory, the markers are anchored directly after a newline, and only [- ] is tolerated adjacent to them — not arbitrary whitespace. So a key with a tab/space before the END marker, with bare \r terminators, or folded onto one line is not recognized as PEM. cryptography's load_pem_public_key is tolerant of exactly these forms and still returns the key.

Reach: jwt/api_jws.py:386 performs the allow-list check (passes when HS256 is in the list) and takes the non-PyJWK branch to alg_obj.prepare_key(key) at :407. The mismatch guard above is the only thing standing between a mixed allow-list and using the public key as an HMAC secret.

PoC

Vulnerable path: jwt/algorithms.py:331 (guard gated on is_pem_format) -> is_pem_format returns False for a loader-accepted PEM -> jwt/algorithms.py:357 returns the public-key bytes as the HMAC secret -> HS256 verification succeeds.

Reproduced on PyJWT 2.13.0 (commit 7144e453) with cryptography 49.0.0, using only the public API. For each of an EC (ES256) and an RSA-2048 (RS256) key: start from the correct public-key PEM, apply a mutation, confirm is_pem_format now returns False while cryptography still loads the bytes, then verify a token signed alg=HS256 with the public-key text as the HMAC secret, under algorithms=["ES256","HS256"] (resp. ["RS256","HS256"]).

Observed output:

pyjwt 2.13.0
  ec  canonical (control)                is_pem_format=True  crypto_loads=True  forgery=BLOCKED:InvalidKeyError
  ec  marker-adjacent (tab before…

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102271)

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102271)

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102271)

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.(CVE-2026-102271)

Prerequisites (both conditions must hold; both are deployment properties, not attacker-controlled at request time):

• The jwt.decode allow-list mixes an HMAC algorithm with an asymmetric one, e.g. algorithms=["ES256", "HS256"] (the RFC 8725 footgun the guard exists to backstop).
• The verification key is passed as raw PEM text/bytes on the non-PyJWK path, in a byte-form that cryptography's loader accepts but PyJWT's is_pem_format regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.

The attacker additionally needs the public verification key, which is public by definition, and cryptography must be installed.

The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when is_pem_format() recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.

Summary

A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT's is_pem_format() return False while cryptography.load_pem_public_key() accepts the identical bytes. The asymmetric-key rejection in HMACAlgorithm.prepare_key is skipped, the public key becomes the HMAC secret, and an attacker who knows the public key mints a valid HS256 token — universal forgery — whenever the verify allow-list mixes an HMAC and an asymmetric algorithm.

Details

At jwt/algorithms.py:331-335, HMACAlgorithm.prepare_key contains the sole family-mismatch guard:

if is_pem_format(key_bytes) or is_ssh_key(key_bytes):
    raise InvalidKeyError(
        "The specified key is an asymmetric key or x509 certificate and"
        " should not be used as an HMAC secret."
    )

If neither predicate fires, :357 returns key_bytes unchanged — the PEM text is used directly as the HMAC secret.

is_pem_format (jwt/utils.py:116-127) is bool(_PEM_RE.search(key)), where _PEM_RE requires ----[- ]BEGIN (...)[- ]----\r?\n, then .+?\r?\n, then the END marker. The LF in each \r?\n is mandatory, the markers are anchored directly after a newline, and only [- ] is tolerated adjacent to them — not arbitrary whitespace. So a key with a tab/space before the END marker, with bare \r terminators, or folded onto one line is not recognized as PEM. cryptography's load_pem_public_key is tolerant of exactly these forms and still returns the key.

Reach: jwt/api_jws.py:386 performs the allow-list check (passes when HS256 is in the list) and takes the non-PyJWK branch to alg_obj.prepare_key(key) at :407. The mismatch guard above is the only thing standing between a mixed allow-list and using the public key as an HMAC secret.

PoC

Vulnerable path: jwt/algorithms.py:331 (guard gated on is_pem_format) -> is_pem_format returns False for a loader-accepted PEM -> jwt/algorithms.py:357 returns the public-key bytes as the HMAC secret -> HS256 verification succeeds.

Reproduced on PyJWT 2.13.0 (commit 7144e453) with cryptography 49.0.0, using only the public API. For each of an EC (ES256) and an RSA-2048 (RS256) key: start from the correct public-key PEM, apply a mutation, confirm is_pem_format now returns False while cryptography still loads the bytes, then verify a token signed alg=HS256 with the public-key text as the HMAC secret, under algorithms=["ES256","HS256"] (resp. ["RS256","HS256"]).

Observed output:

pyjwt 2.13.0
  ec  canonical (control)                is_pem_format=True  crypto_loads=True  forgery=BLOCKED:InvalidKeyError
  ec  marker-adjacent (tab before…

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)

• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)

• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)

• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)

• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)

• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)

• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)

• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)

• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)
• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)
• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)
• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)
• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)
• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)
• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)
• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)
• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

TuxCare rebuilt pyjwt to address 6 CVEs. Fixed in 2.10.1.post5+tuxcare.

TuxCare rebuilt pyjwt to address 6 CVEs. Fixed in 2.8.0.post4+tuxcare.

TuxCare rebuilt pyjwt to address 7 CVEs. Fixed in 2.3.0.post4+tuxcare.

TuxCare rebuilt pyjwt to address 3 CVEs. Fixed in 1.7.1.post4+tuxcare.

These are all security issues fixed in the python313-PyJWT-2.15.1-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

Root has patched CVE-2026-102268 in the pyjwt package for Root:PyPI. Multiple fixed versions available.

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).

This update for python-PyJWT fixes the following issues:

• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).

YuSung Han discovered that PyJWT did not properly validate certain JWK keys when performing HMAC verification. An attacker could possibly use this issue to forge authentication tokens. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-102266)

Rohan Das discovered that PyJWT incorrectly handled redirects when fetching key sets. A remote attacker could possibly use this issue to cause PyJWT to disclose sensitive information. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS. (CVE-2026-102267)

It was discovered that PyJWT incorrectly recognized certain PEM representations. An attacker who knew the public key could possibly use this issue to forge authentication tokens. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS. (CVE-2026-102268)

Nuno Lopes discovered that PyJWT incorrectly handled DER public keys when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102271)

It was discovered that PyJWT did not properly handle certain JWK keys prefixed with a byte-order mark. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102272)

Charles Vosburgh discovered that PyJWT incorrectly handled certain JWK containers when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102273)

USN-8916-1 fixed vulnerabilities in PyJWT. This update provides the corresponding fix for PyJWT on Ubuntu 26.10.

Original advisory details:

YuSung Han discovered that PyJWT did not properly validate certain JWK keys when performing HMAC verification. An attacker could possibly use this issue to forge authentication tokens. (CVE-2026-102266)

Rohan Das discovered that PyJWT incorrectly handled redirects when fetching key sets. A remote attacker could possibly use this issue to cause PyJWT to disclose sensitive information. (CVE-2026-102267)

It was discovered that PyJWT incorrectly recognized certain PEM representations. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102268)

Nuno Lopes discovered that PyJWT incorrectly handled DER public keys when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102271)

It was discovered that PyJWT did not properly handle certain JWK keys prefixed with a byte-order mark. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102272)

Charles Vosburgh discovered that PyJWT incorrectly handled certain JWK containers when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102273)