Threats Tagged 'cve-2026-48525'

> [!NOTE] > Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed. 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. --- ## Affected Component(s) * `jwt/api_jws.py` * `PyJWS.decode()` / `PyJWS.decode_complete()` * `_load()` (parsing and Base64URL decoding) --- ## Root Cause (exact logic flaw) ### What happens in the code In `jwt/api_jws.py`, `decode_complete()` does the following (order matters): * Calls `_load(jwt)` first, which decodes the token segments * Only after that, checks `header.get("b64")` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input This behavior is visible in `decode_complete()`: * `_load(jwt)` happens **before** the `b64=false` handling * then `payload = detached_payload` and `signing_input = ... detached_payload` happens afterward ([GitHub][1]) Inside `_load()`, PyJWT unconditionally performs: * `payload = base64url_decode(payload_segment)` This is the expensive step the attacker can amplify ([GitHub][1]) ### Why this becomes a vulnerability For `b64=false` detached JWS, the payload segment in compact form is effectively **not needed** for verification in PyJWT’s own logic (since the library uses `detached_payload` as the real payload). Yet PyJWT still decodes it first, meaning: * cost is paid **even when signature is invalid** * the decoded bytes are **discarded** * attacker controls the size of this cost via token length --- ## Impact (evidence-driven) ### Security impact * **Unauthenticated remote DoS**: decoding work happens before signature rejection → attacker does not need signing key. * **CPU amplification**: Base64URL decode time scales linearly with payload segment size. * **Memory amplification**: decoded output allocates large byte buffers (tens of MB per request). * **Operational impact**: request queueing / worker starvation under modest concurrency bursts. ### Standards context (RFC 7797) RFC 7797 explicitly notes this option is used when payload is large and/or detached, and discusses interoperability requirements around marking it critical (“crit” with “b64”). ([IETF Datatracker][2]) (PyJWT supports `crit` validation, but the issue here is decode order / unbounded decode of an unused segment.) --- ## Affected Versions * **Confirmed affected:** PyJWT **2.12.1** (tested from your local editable install and repo). * **Likely affected:** all versions that include detached payload support for JWS decoding, which was introduced in **2.4.0** (“Add detached payload support for JWS encoding and decoding”). ([pyjwt.readthedocs.io][3]) (For GHSA, this phrasing is strong: “confirmed” + “likely since feature introduction”.) --- # Threat Model ### Typical real deployment A service verifies signed HTTP requests or webhooks using detached JWS: * token is provided in JSON body / query / header * actual payload is the HTTP request body passed as `detached_payload` ### Attacker * remote unauthenticated client * can send requests to verify endpoint * does **not** need a valid signature (invalid signature still triggers the expensive decode path) ### Attack chain 1. Attacker crafts a JWS compact token with header containing `"b64": false` and `crit:["b64"]`. 2. Attacker inflates the **payload segment** (middle segment) to millions of Base64URL characters. 3. Server calls `PyJWS.decode(...detached_payload=...)`. 4. PyJWT decodes the inflated segment (CPU + memory). 5. Signature is rejected afterward (401) — but resources already consumed. 6. Repeated requests or bursts cause queueing/worker starvation → DoS. --- # Proof of Concept - file names + results ## PoC placement * [server_localhost.py](https://github.com/user-attachments/files/26132755/server_localhost.py) * [client_localhost.py](https://github.com/user-attachments/files/26132757/client_localhost.py) * [flood_localhost.py](https://github.com/user-attachments/files/26132760/flood_localhost.py) --- ## PoC # 1 - Localhost verification server **File:** [server_localhost.py](https://github.com/user-attachments/files/26132755/server_localhost.py) **Purpose:** real HTTP endpoint (`POST /verify`) that calls PyJ

This update includes the following RPMs: rust: * cargo-1.97.0-1.1.hum1 (aarch64, x86_64) * clippy-1.97.0-1.1.hum1 (aarch64, x86_64) * rust-1.97.0-1.1.hum1 (aarch64, x86_64) * rust-analyzer-1.97.0-1.1.hum1 (aarch64, x86_64) * rust-debugger-common-1.97.0-1.1.hum1 (noarch) * rust-doc-1.97.0-1.1.hum1 (aarch64, x86_64) * rust-gdb-1.97.0-1.1.hum1 (noarch) * rust-lldb-1.97.0-1.1.hum1 (noarch) * rust-src-1.97.0-1.1.hum1 (noarch) * rust-std-static-1.97.0-1.1.hum1 (aarch64, x86_64) * rust-std-static-aarch64-unknown-none-softfloat-1.97.0-1.1.hum1 (noarch) * rust-std-static-aarch64-unknown-uefi-1.97.0-1.1.hum1 (noarch) * rust-std-static-i686-pc-windows-gnu-1.97.0-1.1.hum1 (noarch) * rust-std-static-wasm32-unknown-unknown-1.97.0-1.1.hum1 (noarch) * rust-std-static-wasm32-wasip1-1.97.0-1.1.hum1 (noarch) * rust-std-static-x86_64-pc-windows-gnu-1.97.0-1.1.hum1 (noarch) * rust-std-static-x86_64-unknown-none-1.97.0-1.1.hum1 (noarch) * rust-std-static-x86_64-unknown-uefi-1.97.0-1.1.hum1 (noarch) * rustfmt-1.97.0-1.1.hum1 (aarch64, x86_64) * rust-1.97.0-1.1.hum1.src (src)

PyJWKClient in the kimi-cli library allows fetching JSON Web Key Sets (JWKS) from URLs with schemes beyond HTTP and HTTPS, including file://, ftp://, and data:. This can lead to server-side request forgery (SSRF) on local files and other protocols. An attacker who can influence the jku URL and write to a local file path can forge JWT tokens that the application accepts as valid. The vulnerability affects PyJWT versions 2.11.0 and 2.12.1 and likely earlier versions. A fix is available that restricts allowed URL schemes to HTTP and HTTPS.

This update includes the following RPMs: llvm21: * clang21-21.1.8-6.hum1 (aarch64, x86_64) * clang21-analyzer-21.1.8-6.hum1 (aarch64, x86_64) * clang21-devel-21.1.8-6.hum1 (aarch64, x86_64) * clang21-libs-21.1.8-6.hum1 (aarch64, x86_64) * clang21-resource-filesystem-21.1.8-6.hum1 (aarch64, x86_64) * clang21-tools-extra-21.1.8-6.hum1 (aarch64, x86_64) * clang21-tools-extra-devel-21.1.8-6.hum1 (aarch64, x86_64) * compiler-rt21-21.1.8-6.hum1 (aarch64, x86_64) * git-clang-format21-21.1.8-6.hum1 (aarch64, x86_64) * libomp21-21.1.8-6.hum1 (aarch64, x86_64) * libomp21-devel-21.1.8-6.hum1 (aarch64, x86_64) * lld21-21.1.8-6.hum1 (aarch64, x86_64) * lld21-devel-21.1.8-6.hum1 (aarch64, x86_64) * lld21-libs-21.1.8-6.hum1 (aarch64, x86_64) * lldb21-21.1.8-6.hum1 (aarch64, x86_64) * lldb21-devel-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-cmake-utils-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-devel-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-doc-21.1.8-6.hum1 (noarch) * llvm21-filesystem-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-googletest-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-libs-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-static-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-test-21.1.8-6.hum1 (aarch64, x86_64) * python3-clang21-21.1.8-6.hum1 (aarch64, x86_64) * llvm21-21.1.8-6.hum1.src (src)