Weak validation logic within device dissociation API routines allows a remote entity to forcefully unbind unrelated user endpoints, causing severe denial of service.
Dräger Core 1.0.5 and Dräger M540 Converter Service 1.0.9 contain a denial of service vulnerability that allows network-adjacent attackers to trigger high CPU load by sending specially crafted, unencrypted SDC messages during the discovery process. Attackers with access to the hospital network can send malformed SDC packets to exhaust CPU resources in the affected process, causing further SDC messages to no longer be processed.
React Router is a router for React. In versions 7.0.0 through 7.14.x of react-router and versions 2.10.0 through 2.17.4 of @remix-run/server-runtime, certain crafted requests can consume disproportionate server resources via unbounded path expansion in the __manifest endpoint, resulting in response time degradation and/or service unavailability for end users. This affects React Router Framework Mode applications as well as Remix applications. This does not impact applications using Declarative Mode (`<BrowserRouter>`) or Data Mode (`createBrowserRouter/<RouterProvider>`). This is patched in react-router version 7.15.0 and @remix-run/server-runtime version 2.17.5.
OpenClaude is an open-source coding-agent command line interface for cloud and local model providers. Prior to version 0.5.1, the OpenClaude MCP authentication flow starts a temporary local HTTP server to handle OAuth callbacks. To prevent CSRF attacks, the server validates a state parameter against an internally stored value. However, due to a logic flaw in the order of conditionals, an attacker can completely bypass this check and force the server to shut down — without knowing the state value at all. This issue has been patched in version 0.5.1.
OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval. This issue has been patched in version 0.9.0.
Apache Fluss versions prior to 0.9.1 configure the Netty LengthFieldBasedFrameDecoder with Integer.MAX_VALUE as the maximum frame length, allowing unauthenticated remote attackers to exhaust JVM heap memory on TabletServer and CoordinatorServer by sending specially crafted frame headers, resulting in denial of service.
This issue affects Apache Fluss (incubating): 0.8.0 and 0.9.0.
Users are recommended to upgrade to version 0.9.1, which fixes the issue.
An uncontrolled allocation of resources without limits or throttling in the e-mail handling in OTRS allows excessive allocation which may lead to the abortion of the webserver.This issue affects OTRS:
* 8.0.X
* 2023.X
* 2024.X
* 2025.X
* 2026.X before 2026.4.X
Please note that ((OTRS)) Community Edition 6.x, OTRS 7.x and products based on the ((OTRS)) Community Edition also very likely to be affected
An improper neutralization of active SVG content in OTRS or ((OTRS)) Community Edition ticket article rendering allows attackers to inject specially crafted SVG payloads via email content, leading to browser-side resource exhaustion and denial of service when affected tickets are opened by an agent or customer. The issue can be exploited without JavaScript execution and is not mitigated by the configured Content Security Policy (CSP).
This issue affects OTRS:
* 7.0.X
* 8.0.X
* 2023.X
* 2024.X
* 2025.X
* 2026.X before 2026.4.X
Please note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected
iskorotkov/avro versions prior to 2.33.0 contain a vulnerability in the Avro array and map decoders where an attacker-controlled block-count value is processed without proper error checking. This allows a remote unauthenticated attacker to cause excessive CPU consumption by sending a specially crafted payload with a very large block count followed by truncated data, resulting in a denial-of-service condition. The issue is fixed in version 2.33.0.
Uncontrolled resource consumption in the Wireless Control Module (WCM) of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker with write access to the in-vehicle network to permanently immobilize the motorcycle. The WCM enforces a brute-force lockout on the immobilizer authentication algorithm, but the lockout counter is reachable by any unauthenticated message, has no session binding, and does not reset on power cycle. An attacker can deliberately trip the lockout with a small number of crafted frames, leaving the bike un-startable until dealer service. Specific thresholds have been withheld pending vendor remediation.
Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with viewer-level access can submit a request containing an oversized input value to an analytics collections management endpoint. Kibana will consume excessive CPU and memory resources while processing the request. This results in Kibana becoming unavailable to all users until the service is manually recovered.
Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated low-privileged user can cause Kibana to consume exponentially increasing amounts of memory by submitting a specially crafted Timelion visualization expression containing deeply chained function calls. The resulting data structure grows without bound, exhausting available memory and causing the Kibana service to crash and become unavailable to all users.
Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user can send a specially crafted compressed request payload that is processed prior to authorization checks, causing excessive memory and CPU resource consumption that can result in a Kibana instance becoming unresponsive or crashing.
CVE-2026-33464 is a medium severity vulnerability in Elastic Kibana affecting versions 8.0.0, 9.0.0, and 9.4.0. It involves uncontrolled resource consumption (CWE-400) where an authenticated user with low privileges can send an oversized payload to an internal API. This causes the Kibana process to exhaust system resources, leading to denial of service by making the service unresponsive until recovery or restart. There is no confirmed patch or official remediation available at this time.
> [!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
CVE-2026-48155 is a medium severity vulnerability in the pypdf library prior to version 6.12.0. It allows an attacker to craft a PDF that causes uncontrolled resource consumption, specifically large memory usage, when extracting text in layout mode with large character offsets. This issue is fixed in pypdf version 6.12.0.
Volcano is a Kubernetes-native batch scheduling system. Prior to v1.14.2, v1.13.3, and v1.12.4, the Volcano webhook server does not enforce a size limit on incoming HTTP request bodies. Any in-cluster pod that can reach the webhook endpoint may send an arbitrarily large request body, potentially causing the webhook server to be killed by OOM. All Volcano deployments with the webhook server exposed to in-cluster traffic are affected. This vulnerability is fixed in v1.14.2, v1.13.3, and v1.12.4.
bird-lg-go is a BIRD looking glass in Go. Prior to 1.4.5, the apiHandler (and similarly webHandlerTelegramBot) processes user-provided JSON payloads by directly using json.NewDecoder(r.Body).Decode(&request) without restricting the maximum read size. An unauthenticated remote attacker can stream an extremely large, endless JSON payload (e.g., several Gigabytes of padding) over a single TCP connection. Because Go's JSON decoder attempts to allocate memory for the entire parsed structure, this rapidly exhausts the host's physical RAM or container limits, leading to an unrecoverable fatal error: runtime: out of memory. This vulnerability is fixed in 1.4.5.