PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option ("b64": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2051 advisory.

    PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, 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 which schemes PyJWKClient will fetch. If an application's jku URL ingestion path     accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the     attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause     PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies     as valid. 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. This vulnerability is fixed in 2.13.0. (CVE-2026-48522)

    PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS     tokens using the unencoded-payload option (b64: false, RFC 7797), PyJWT performs Base64URL decoding of     the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false,     PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In     practice, this turns the middle segment into an attacker-controlled work amplifier: a remote client can     supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if     the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies     detached JWS using PyJWT. This vulnerability is fixed in 2.13.0. (CVE-2026-48525)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:2626-1 advisory.

    This update for python-PyJWT fixes the following issues

    - CVE-2026-48522: `PyJWKClient` passes URI arguments directly to `urllib.request.urlopen()` and allows for     SSRF and       token forgery (bsc#1266798).
    - CVE-2026-48523: verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()`     are called       with a PyJWK key (bsc#1266799).
    - CVE-2026-48524: unlimited processing of JWTs with unknown kid values by `PyJWKClient.get_signing_key()`     leads to       unbounded JWKS endpoint requests and DoS (bsc#1266800).
    - CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in `b64=false` detached JWS     allows for DoS       (bsc#1266801).
    - CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens     allows for       forged HS256 tokens (bsc#1266802).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:2627-1 advisory.

    This update for python-PyJWT fixes the following issues

    - CVE-2026-48522: `PyJWKClient` passes URI arguments directly to `urllib.request.urlopen()` and allows for     SSRF and       token forgery (bsc#1266798).
    - CVE-2026-48523: verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()`     are called       with a PyJWK key (bsc#1266799).
    - CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in `b64=false` detached JWS     allows for DoS       (bsc#1266801).
    - CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens     allows for       forged HS256 tokens (bsc#1266802).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES16 / SLES_SAP16 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:22170-1 advisory.

    This update for python-PyJWT fixes the following issues

    - CVE-2026-48522: `PyJWKClient` passes URI arguments directly to `urllib.request.urlopen()` and allows for     SSRF and       token forgery (bsc#1266798).
    - CVE-2026-48523: verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()`     are called       with a PyJWK key (bsc#1266799).
    - CVE-2026-48524: unlimited processing of JWTs with unknown kid values by `PyJWKClient.get_signing_key()`     leads to       unbounded JWKS endpoint requests and DoS (bsc#1266800).
    - CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in `b64=false` detached JWS     allows for DoS       (bsc#1266801).
    - CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens     allows for       forged HS256 tokens (bsc#1266802).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS
    tokens using the unencoded-payload option ("b64": false, RFC 7797), PyJWT performs Base64URL decoding of
    the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false,
    PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In
    practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can
    supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if
    the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies
    detached JWS using PyJWT. This vulnerability is fixed in 2.13.0. (CVE-2026-48525)

The version of Tencent Linux installed on the remote TencentOS Server 4 host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the TSSA-2026:0427 advisory.

    Package updates are available for TencentOS Server 4 that fix the following vulnerabilities:

    CVE-2026-48525:
    PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS     tokens using the unencoded-payload option (b64: false, RFC 7797), PyJWT performs Base64URL decoding of     the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false,     PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In     practice, this turns the middle segment into an attacker-controlled work amplifier: a remote client can     supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if     the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies     detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.

    CVE-2026-48524:
    PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces     a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting.
    Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The     vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with     sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting,     transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.

    CVE-2026-48523:
    PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side     algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The     token header alg is checked against the caller-supplied algorithms allow-list, but signature verification     is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who     controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed     algorithm in the JWT header, and still be accepted. The issue affects the documented     PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.

    CVE-2026-48522:
    PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, 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 which schemes PyJWKClient will fetch. If an application's jku URL ingestion path     accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the     attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause     PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies     as valid. 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. This vulnerability is fixed in 2.13.0.

Tenable has extracted the preceding description block directly from the Tencent Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS     tokens using the unencoded-payload option (b64: false, RFC 7797), PyJWT performs Base64URL decoding of     the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false,     PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In     practice, this turns the middle segment into an attacker-controlled work amplifier: a remote client can     supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if     the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies     detached JWS using PyJWT. This vulnerability is fixed in 2.13.0. (CVE-2026-48525)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
337210	Amazon Linux 2023 : python3-jwt, python3-jwt+crypto (ALAS2023-2026-2051)	Nessus	Amazon Linux Local Security Checks	Local	medium
323065	SUSE SLED15 / SLES15 Security Update : python-PyJWT (SUSE-SU-2026:2626-1)	Nessus	SuSE Local Security Checks	Local	high
323028	SUSE SLED15 / SLES15 Security Update : python-PyJWT (SUSE-SU-2026:2627-1)	Nessus	SuSE Local Security Checks	Local	high
322913	SUSE SLES16 Security Update : python-PyJWT (SUSE-SU-2026:22170-1)	Nessus	SuSE Local Security Checks	Local	high
443265	SCA: security update for pyjwt (GHSA-w7vc-732c-9m39)	Tenable Cloud Security	SCA Checks	Local	medium
443265	SCA: security update for pyjwt (GHSA-w7vc-732c-9m39)	Tenable Self-Hosted Container Security	SCA Checks	Local	medium
319736	TencentOS Server 4: python-jwt (TSSA-2026:0427)	Nessus	Tencent Local Security Checks	Local	medium
317761	Linux Distros Unpatched Vulnerability : CVE-2026-48525	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-48525

medium

Tenable Plugins

medium

high

high

high

medium

medium

medium

medium