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)

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - PyJWT 是 Python 中的 JSON Web 令牌實作。在 之前， 2.13.0PyJWKClient 將其 uri 參數直接傳遞給 urllib.request.urlopen（），該引數使用 Python stdlib 的預設 OpenerDirector 註冊 HTTPHandler、HTTPSHandler、FTPHandler、FileHandler 和 DataHandler。目前沒有記錄在案的選項來限制 PyJWKClient 將獲取哪些方案。如果應用程式的 jku URL 擷取路徑接受受攻擊者影響的 URL（例如，來自JWT標頭、設定檔、OAuth 流程參數），攻擊者可以導致 PyJWKClient 透過 file://（本機檔案系統上的 SSRF）讀取任意本機檔案，導致 PyJWKClient 嘗試FTP/資料 URI 擷取（更廣泛的 SSRF 表面），或偽造 PyJWT 驗證為有效的令牌。程式庫不會直接將非 HTTP（S） URI 內容傳回給攻擊者;原始報告中描述的鏈結植物 JWKS 偽造令牌場景需要此修正程式無法解決的其他應用程式層缺陷 （攻擊者對檔案系統路徑的寫入存取權、不受信任的 JKU 衍生）。此弱點已在 2.13.0 中修正。(CVE-2026-48522)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - PyJWT 是 Python 中的 JSON Web Token 实现。在之前 2.13.0，PyJWKClient 将其 uri 参数直接传递给使用 Python stdlib 的默认 OpenerDirector 注册 HTTPHandler、HTTPSHandler、FTPHandler、FileHandler 和 DataHandler 的 urllib.request.urlopen（）。目前没有记录的选项来限制 PyJWKClient 将获取的方案。如果应用程序的 jku URL 摄取路径接受受攻击者影响的 URL（例如，来自 JWT 标头、配置文件、OAuth 流参数），攻击者可导致 PyJWKClient 通过 file://（本地文件系统上的 SSRF）读取任意本地文件，导致 PyJWKClient 尝试 FTP / data-URI 提取（更广泛的 SSRF 表面），或伪造 PyJWT 验证为有效的标记。库不会直接将非 HTTP（S） URI 内容返回给攻击者;原始报告中描述的链式工厂 （JWKS 伪造标记） 场景需要其他应用层缺陷（攻击者对文件系统路径的写入访问权限、不受信任的 JKU 派生），而此补丁并未解决这些缺陷。此漏洞已在 2.13.0 中修复。(CVE-2026-48522)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - PyJWTは、PythonのJSON Webトークン実装です。2.13.0より前に、PyJWKClientはuri引数をurllib.request.urlopen()に直接渡します。urlopen()は、HTTPHandler、HTTPSHandler、FTPHandler、FileHandler、DataHandlerを登録するPython stdlibのデフォルトのOpenerDirectorを使用します。現在、PyJWKClientがフェッチするスキームを制限するドキュメント化されたオプションはありません。アプリケーションのjku URLインジェストパスが攻撃者の影響を受けるURL(ヘッダー、構成ファイル、OAuthフローパラメーターなどJWT受け入れる場合、攻撃者は file://(ローカルファイルシステムのSSRF)を介してPyJWKClientに任意のローカルファイルを読み込ませたり、PyJWKClientにFTP/data-URIフェッチ(より広いSSRFサーフェス)を試行させたり、PyJWTが有効と検証するトークンを偽造したりする可能性があります。このライブラリは、非 HTTP(S) URI のコンテンツを攻撃者に直接返しません。元のレポートで説明されている、チェーンされたプラント、つまり JWKS からトークンを偽造するシナリオでは、この修正では対処しない追加のアプリケーション層の欠陥(ファイルシステムパスに対する攻撃者の書き込みアクセス、信頼できない JKU の派生)が必要です。この脆弱性は 2.13.0 で修正されました。(CVE-2026-48522)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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.

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

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.

ID	名前	製品	ファミリー	公開日	更新日	深刻度
443249	SCA: security update for PyJWT (GHSA-993g-76c3-p5m4)	Tenable Self-Hosted Container Security	SCA Checks	2026/6/16	2026/8/1	medium
443249	SCA: security update for PyJWT (GHSA-993g-76c3-p5m4)	Tenable Cloud Security	SCA Checks	2026/6/16	2026/8/1	medium
317716	Linux Distros 未修補的弱點：CVE-2026-48522	Nessus	Misc.	2026/5/29	2026/7/27	medium
317716	Linux Distros 未修补的漏洞：CVE-2026-48522	Nessus	Misc.	2026/5/29	2026/7/27	medium
317716	Linux Distros のパッチ未適用の脆弱性: CVE-2026-48522	Nessus	Misc.	2026/5/29	2026/7/27	medium
317716	Linux Distros Unpatched Vulnerability : CVE-2026-48522	Nessus	Misc.	2026/5/29	2026/7/27	medium
319736	TencentOS Server 4: python-jwt (TSSA-2026:0427)	Nessus	Tencent Local Security Checks	2026/6/8	2026/6/8	medium
322913	SUSE SLES16 Security Update : python-PyJWT (SUSE-SU-2026:22170-1)	Nessus	SuSE Local Security Checks	2026/6/26	2026/6/26	high
323065	SUSE SLED15 / SLES15 Security Update : python-PyJWT (SUSE-SU-2026:2626-1)	Nessus	SuSE Local Security Checks	2026/6/26	2026/6/26	high
323028	SUSE SLED15 / SLES15 Security Update : python-PyJWT (SUSE-SU-2026:2627-1)	Nessus	SuSE Local Security Checks	2026/6/26	2026/6/26	high

検出

プラグインの検索

medium

medium

medium

medium

medium

medium

medium

high

high

high