#dos

A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where attacker-provided data are included in a filename by the ingress-nginx Admission Controller feature, resulting in directory traversal within the container. This could result in denial of service, or when combined with other vulnerabilities, limited disclosure of Secret objects from the cluster.

Use of incorrectly resolved name or reference in OpenDaylight Service Function Chaining (SFC) Subproject SFC Sodium-SR4 and below allows attackers to cause a Denial of Service (DoS).

Prior to version 0.10.3, the built-in clients of the `web-push` crate eagerly allocated memory based on the `Content-Length` header returned by the Web Push endpoint. Malicious Web Push endpoints could return a large `Content-Length` without ever having to send as much data, leading to denial of service by memory exhaustion. Services providing Web Push notifications typically allow the user to register an arbitrary endpoint, so the endpoint should not be trusted. The fixed version 0.10.3 now limits the amount of memory it will allocate for each response, limits the amount of data it will read from the endpoint, and returns an error if the endpoint sends too much data. As before, it is recommended that services add a timeout for each request to Web Push endpoints.

A vulnerability has been identified in Redlib where an attacker can cause a denial-of-service (DOS) condition by submitting a specially crafted base2048-encoded DEFLATE decompression bomb to the restore_preferences form. This leads to excessive memory consumption and potential system instability, which can be exploited to disrupt Redlib instances. This vulnerability was introduced in 2e95e1fc6e2064ccfae87964b4860bda55eddb9a and fixed in 15147cea8e42f6569a11603d661d71122f6a02dc. ### Impact _What kind of vulnerability is it? Who is impacted?_ This vulnerability allows a remote attacker with network access to exploit the preference restoration mechanism by providing a compressed payload that expands dramatically upon decompression. The issue arises because the system automatically decompresses user-supplied data without enforcing size limits, potentially leading to: - Out-of-memory (OOM) conditions - OS-level resource exhaustion, potentially leading to broader system instability or cra...

### Summary Envoy's ext_proc HTTP filter is at risk of crashing if a local reply is sent to the external server due to the filter's life time issue. A known situation is the fail of a websocket handshake will trigger a local reply leading to the crash of Envoy. ### PoC If both websocket and ext_proc are enabled, a failed handshake will trigger a local reply, thus ext_proc will crash. ### Mitigation 1. Disable websocket traffic 2. Change the websocket response from backend to always return `101 Switch protocol` based on RFC. 3. Apply the patch and the ext_proc filter will not send the local reply that is generated by Envoy to the ext_proc server for processing. 4. Apply the patch that the router will cancel the upstream requests when sending a local reply. ### Impact Denial of service ### Reporter Vasilios Syrakis Fernando Cainelli

In version 3.25.0 of aimhubio/aim, a denial of service vulnerability exists. By tracking a large number of `Text` objects and then querying them simultaneously through the web API, the Aim web server becomes unresponsive to other requests for an extended period while processing and returning these objects. This vulnerability can be exploited repeatedly, leading to a complete denial of service.

In mlflow/mlflow version 2.17.2, the `/graphql` endpoint is vulnerable to a denial of service attack. An attacker can create large batches of queries that repeatedly request all runs from a given experiment. This can tie up all the workers allocated by MLFlow, rendering the application unable to respond to other requests. This vulnerability is due to uncontrolled resource consumption.

In version 3.25.0 of aimhubio/aim, the tracking server is vulnerable to a denial of service attack. The server overrides the maximum size for websocket messages, allowing very large images to be tracked. This causes the server to become unresponsive to other requests while processing the large image, leading to a denial of service condition.

A vulnerability in ollama/ollama versions <=0.3.14 allows a malicious user to upload and create a customized GGUF model file on the Ollama server. This can lead to a division by zero error in the ggufPadding function, causing the server to crash and resulting in a Denial of Service (DoS) attack.

A vulnerability in ollama/ollama <=0.3.14 allows a malicious user to create a customized GGUF model file, upload it to the Ollama server, and create it. This can cause the server to allocate unlimited memory, leading to a Denial of Service (DoS) attack.