CVE-2026-101917

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.

Summary CVE-2026-48524 (GHSA-fhv5-28vv-h8m8, "PyJWKClient unbounded JWKS endpoint requests via attacker-controlled kid values (DoS)") was fixed in 2.13.0 by stopping fetch_data() from clearing the cache on a fetch error. That closed one amplification path but did not add the mitigation the advisory's title implies: there is still no rate-limit, negative-cache, or minimum-refresh-interval for unknown kids.

At HEAD, get_signing_key(kid) (jwt/jwks_client.py:185-211), on any unknown kid, calls get_signing_keys(refresh=True), and refresh=True bypasses jwk_set_cache unconditionally and forces a fresh fetch_data(). The kid is read from the unverified token header (get_signing_key_from_jwt decodes with verify_signature=False), so no valid token and no authentication is required. lru_cache does not cache the raised exception, so even the same unknown kid repeated re-fetches on every call.

Affected pyjwt <= 2.13.0 (the latest release; the patched release for CVE-2026-48524). No fixed version yet.

Proof of concept (verified on 2.13.0, cache enabled = realistic prod config) import threading, http.server, socketserver, json from jwt import PyJWKClient hits = {'n': 0} JWKS = json.dumps({"keys":[{"kty":"oct","kid":"real","k":"AAAA"}]}).encode() class H(http.server.BaseHTTPRequestHandler): def do_GET(self): hits['n'] += 1 self.send_response(200); self.send_header('Content-Type','application/json'); self.end_headers() self.wfile.write(JWKS) def log_message(self,*a): pass srv = socketserver.TCPServer(('127.0.0.1',0), H); port = srv.server_address[1] threading.Thread(target=srv.serve_forever, daemon=True).start() c = PyJWKClient(f'http://127.0.0.1/:{port}/jwks.json', cache_keys=True, lifespan=3600) for i in range(8): try: c.get_signing_key(f'attacker-unknown-kid-{i}') except Exception: pass before = hits['n'] for _ in range(5): try: c.get_signing_key('same-unknown') except Exception: pass print('distinct unknown kids: 8 -> fetches:', hits['n']) print('same unknown kid x5 -> extra fetches:', hits['n'] - before)

Output: distinct unknown kids: 8 -> fetches: 9 same unknown kid x5 -> extra fetches: 5 Each unknown kid forces a fresh JWKS fetch; a repeated identical unknown kid still re-fetches every time against an unexpired cache. No rate-limit or negative-cache.

Impact One unauthenticated request -> one outbound JWKS HTTP fetch + full JSON parse on the victim server. An attacker floods tokens carrying junk kids, so the victim hammers its own JWKS/IdP endpoint (amplification: attacker -> victim -> IdP), exhausting victim CPU/sockets and potentially tripping the JWKS provider's rate-limit, causing an application-wide auth outage. This is the unauthenticated DoS the parent advisory is named for, still reachable after the 2.13.0 fix.

Suggested fix Guard the forced refresh on unknown kids: negative-cache unknown kids for a short TTL, or enforce a minimum interval between forced JWKS refreshes, so a repeated or unknown kid cannot force unbounded fetches.

Note: the same-kid-repeated result (5 identical unknown kids producing 5 fetches against an unexpired cache) shows this is request amplification, not legitimate key-rotation handling, since that refresh can never succeed.

Reported by Babakizo (Securva).

Maintainer update — 2026-09-10

The maintainer confirmed the reported behavior against PyJWT 2.13.0. With JWKS caching enabled, an unknown kid previously forced an unconditional JWKS refresh, including when the same unknown value was repeated while the cached key set was still valid. This allowed unauthenticated token headers to cause unnecessary outbound JWKS requests and repeated parsing work.

The fix is now on master in commit ba4853a. PyJWKClient now applies a 30-second cooldown after successful JWKS fetches before permitting another unknown-kid refresh, serializes concurrent refresh decisions per client, and allows…

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.(CVE-2026-101917)

PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/api_jwt.py, verify_signature=False. This issue is fixed in version 2.15.0.(CVE-2026-101918)

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.(CVE-2026-102265)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.(CVE-2026-102269)

PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.(CVE-2026-102275)

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.(CVE-2026-101917)

PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/api_jwt.py, verify_signature=False. This issue is fixed in version 2.15.0.(CVE-2026-101918)

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.(CVE-2026-102265)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.(CVE-2026-102269)

PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.(CVE-2026-102275)

setup.py test %endif

Security Fix(es):

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.(CVE-2026-101917)

PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/api_jwt.py, verify_signature=False. This issue is fixed in version 2.15.0.(CVE-2026-101918)

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.(CVE-2026-102265)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.(CVE-2026-102269)

PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.(CVE-2026-102275)

Summary CVE-2026-48524 (GHSA-fhv5-28vv-h8m8, "PyJWKClient unbounded JWKS endpoint requests via attacker-controlled kid values (DoS)") was fixed in 2.13.0 by stopping fetch_data() from clearing the cache on a fetch error. That closed one amplification path but did not add the mitigation the advisory's title implies: there is still no rate-limit, negative-cache, or minimum-refresh-interval for unknown kids.

At HEAD, get_signing_key(kid) (jwt/jwks_client.py:185-211), on any unknown kid, calls get_signing_keys(refresh=True), and refresh=True bypasses jwk_set_cache unconditionally and forces a fresh fetch_data(). The kid is read from the unverified token header (get_signing_key_from_jwt decodes with verify_signature=False), so no valid token and no authentication is required. lru_cache does not cache the raised exception, so even the same unknown kid repeated re-fetches on every call.

Affected pyjwt <= 2.13.0 (the latest release; the patched release for CVE-2026-48524). No fixed version yet.

Proof of concept (verified on 2.13.0, cache enabled = realistic prod config) import threading, http.server, socketserver, json from jwt import PyJWKClient hits = {'n': 0} JWKS = json.dumps({"keys":[{"kty":"oct","kid":"real","k":"AAAA"}]}).encode() class H(http.server.BaseHTTPRequestHandler): def do_GET(self): hits['n'] += 1 self.send_response(200); self.send_header('Content-Type','application/json'); self.end_headers() self.wfile.write(JWKS) def log_message(self,*a): pass srv = socketserver.TCPServer(('127.0.0.1',0), H); port = srv.server_address[1] threading.Thread(target=srv.serve_forever, daemon=True).start() c = PyJWKClient(f'http://127.0.0.1/:{port}/jwks.json', cache_keys=True, lifespan=3600) for i in range(8): try: c.get_signing_key(f'attacker-unknown-kid-{i}') except Exception: pass before = hits['n'] for _ in range(5): try: c.get_signing_key('same-unknown') except Exception: pass print('distinct unknown kids: 8 -> fetches:', hits['n']) print('same unknown kid x5 -> extra fetches:', hits['n'] - before)

Output: distinct unknown kids: 8 -> fetches: 9 same unknown kid x5 -> extra fetches: 5 Each unknown kid forces a fresh JWKS fetch; a repeated identical unknown kid still re-fetches every time against an unexpired cache. No rate-limit or negative-cache.

Impact One unauthenticated request -> one outbound JWKS HTTP fetch + full JSON parse on the victim server. An attacker floods tokens carrying junk kids, so the victim hammers its own JWKS/IdP endpoint (amplification: attacker -> victim -> IdP), exhausting victim CPU/sockets and potentially tripping the JWKS provider's rate-limit, causing an application-wide auth outage. This is the unauthenticated DoS the parent advisory is named for, still reachable after the 2.13.0 fix.

Suggested fix Guard the forced refresh on unknown kids: negative-cache unknown kids for a short TTL, or enforce a minimum interval between forced JWKS refreshes, so a repeated or unknown kid cannot force unbounded fetches.

Note: the same-kid-repeated result (5 identical unknown kids producing 5 fetches against an unexpired cache) shows this is request amplification, not legitimate key-rotation handling, since that refresh can never succeed.

Reported by Babakizo (Securva).

Maintainer update — 2026-09-10

The maintainer confirmed the reported behavior against PyJWT 2.13.0. With JWKS caching enabled, an unknown kid previously forced an unconditional JWKS refresh, including when the same unknown value was repeated while the cached key set was still valid. This allowed unauthenticated token headers to cause unnecessary outbound JWKS requests and repeated parsing work.

The fix is now on master in commit ba4853a. PyJWKClient now applies a 30-second cooldown after successful JWKS fetches before permitting another unknown-kid refresh, serializes concurrent refresh decisions per client, and allows…

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. 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.

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).

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).

Kingsley Olukanni discovered that PyJWT did not properly handle unknown key identifiers when retrieving signing keys. An attacker could possibly use this issue to amplify requests to the configured key endpoint, resulting in a denial of service. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS and Ubuntu 26.10. (CVE-2026-101917)

Ekalabya Ghosh discovered that PyJWT did not properly handle certain recursively nested JSON payloads. An attacker could possibly use this issue to cause an application to fail, resulting in a denial of service. (CVE-2026-101918)

Pedram Hayati discovered that PyJWT did not properly handle malformed RSA keys in a JSON Web Key Set. An attacker could possibly use this issue to cause authentication failures or a denial of service. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS and Ubuntu 26.10. (CVE-2026-102274)

It was discovered that PyJWT did not properly validate certain OKP private key components. An attacker could possibly use this issue to confuse the identity of public and private keys, and use a stolen sender-constrained token without the legitimate private key. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS and Ubuntu 26.10. (CVE-2026-102275)