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.

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

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

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

ID	Name	Product	Family	Severity
323065	SUSE SLED15 / SLES15 Security Update : python-PyJWT (SUSE-SU-2026:2626-1)	Nessus	SuSE Local Security Checks	high
323028	SUSE SLED15 / SLES15 Security Update : python-PyJWT (SUSE-SU-2026:2627-1)	Nessus	SuSE Local Security Checks	high
322913	SUSE SLES16 Security Update : python-PyJWT (SUSE-SU-2026:22170-1)	Nessus	SuSE Local Security Checks	high
443249	SCA: security update for PyJWT (GHSA-993g-76c3-p5m4)	Tenable Cloud Security	SCA Checks	medium
443249	SCA: security update for PyJWT (GHSA-993g-76c3-p5m4)	Tenable Self-Hosted Container Security	SCA Checks	medium
319736	TencentOS Server 4: python-jwt (TSSA-2026:0427)	Nessus	Tencent Local Security Checks	medium
317716	Linux Distros Unpatched Vulnerability : CVE-2026-48522	Nessus	Misc.	medium

Detections

Analytics

CVE-2026-48522

medium

Tenable Plugins

high

high

high

medium

medium

medium

medium