#dos

### Summary With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. ### Details `BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. Tested on 4.1.118, but there were no changes to the decoder since. ### PoC Run this test case with `-Xmx1G`: ```java import io.netty.buffer.Unpooled; import io.netty.channel.embedded.EmbeddedChannel; import java.util.Base64; public class T { public static void main(String[] args) { EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1...

Cloudflare mitigated the largest DDoS attack ever recorded, an 11.5 Tbps flood that lasted 35 seconds without disrupting…

Google has shipped security updates to address 120 security flaws in its Android operating system as part of its monthly fixes for September 2025, including two issues that it said have been exploited in targeted attacks. The vulnerabilities are listed below - CVE-2025-38352 (CVSS score: 7.4) - A privilege escalation flaw in the Linux Kernel component  CVE-2025-48543 (CVSS score: N/A) - A

Cloudflare on Tuesday said it automatically mitigated a record-setting volumetric distributed denial-of-service (DDoS) attack that peaked at 11.5 terabits per second (Tbps). "Over the past few weeks, we've autonomously blocked hundreds of hyper-volumetric DDoS attacks, with the largest reaching peaks of 5.1 Bpps and 11.5 Tbps," the web infrastructure and security company said in a post on X. "

### Summary A denial-of-service / out-of-memory vulnerability exists in the `STATUS_SEND_PACKS` handling of `ResourcePackClientResponsePacket`. PocketMine-MP processes the `packIds` array without verifying that all entries are unique. A malicious (non-standard) Bedrock client can send multiple duplicate valid pack UUIDs in the same `STATUS_SEND_PACKS` packet, causing the server to send the same pack multiple times. This can quickly exhaust memory and crash the server. Severity: **High** — Remote DoS from an authenticated client. --- ### Details Relevant code (simplified): ```php case ResourcePackClientResponsePacket::STATUS_SEND_PACKS: foreach($packet->packIds as $uuid){ $splitPos = strpos($uuid, "_"); if($splitPos !== false){ $uuid = substr($uuid, 0, $splitPos); } $pack = $this->getPackById($uuid); if(!($pack instanceof ResourcePack)){ $this->disconnectWithError("Unknown pack $uuid requested..."); ret...

A flaw was found in Undertow where malformed client requests can trigger server-side stream resets without triggering abuse counters. This issue, referred to as the "MadeYouReset" attack, allows malicious clients to induce excessive server workload by repeatedly causing server-side stream aborts. While not a protocol bug, this highlights a common implementation weakness that can be exploited to cause a denial of service (DoS).

### Impact For optimizing the scalar multiplication algorithm in circuit for some curves, gnark uses fake-GLV algorithm in case the curve doesn't support true-GLV. For this to work, we need to compute the scalar decomposition using the Half GCD method in gnark-crypto. However, for some of the inputs the algorithm didn't converge quickly enough. In case the prover accepts untrusted witness, it could lead to denial of service as the prover gets stuck in a very slowly converging loop. Thanks to @feltroidprime for reporting the issue and proposing a fix. ### Patches The issue has been patched in gnark-crypto commit https://github.com/Consensys/gnark-crypto/commit/56600883e0e9f9b159e9c7000b94e76185ec3d0d. The dependency update is implemented in gnark commit https://github.com/Consensys/gnark/commit/68be6cede36e387ab760725beabd3c96cc94e6dc. ### Workarounds This update doesn't require recompiling the circuits as the issue is in the hint function. The users can update the gnark-crypto d...

# Summary A denial of service vulnerability was discovered in ntpd-rs where an attacker can induce a message storm between two NTP servers running ntpd-rs. # Details Since ntpd-rs version 1.2.0, when configured as a server, incorrectly responded to all NTP messages sent to the server's port with a time reply, including to responses from other servers. As a consequence, a message with a spoofed IP address of another server could cause two servers running ntpd-rs to continually respond to each other, consuming significant amounts of resources. # Impact Any time server running ntpd-rs with version between 1.2.0 and 1.6.1 inclusive which allows non-NTS traffic is affected. Client-only configurations are not affected. Affected users are recommended to upgrade to version 1.6.2 as soon as possible. # Workarounds Should upgrading not be possible, the impact of the issue can be mitigated by: - Whitelisting access to only IP addresses of clients using the server, using the ignore filter ...

### Impact A vulnerability has been identified within Rancher Manager in which it did not enforce request body size limits on certain public (unauthenticated) and authenticated API endpoints. This allows a malicious user to exploit this by sending excessively large payloads, which are fully loaded into memory during processing. This could result in: - Denial of Service (DoS): The server process may crash or become unresponsive when memory consumption exceeds available resources. - Unauthenticated and authenticated exploitation: While the issue was initially observed in unauthenticated `/v3-public/*` endpoints, the absence of request body size limits also affected several authenticated APIs, broadening the potential attack surface. It's worth noting that other areas in Rancher do implement safeguards: requests proxied to Kubernetes APIs are subject to built-in size limits enforced by the [Kubernetes API server itself](https://github.com/kubernetes/kubernetes/blob/v1.33.4/staging/src/k8s...

### Impact A denial-of-service was found in Exiv2 version v0.28.5: a quadratic algorithm in the ICC profile parsing code in `jpegBase::readMetadata()` can cause Exiv2 to run for a long time. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted jpg image file. ### Patches The bug is fixed in version v0.28.6. ### References Issue: https://github.com/Exiv2/exiv2/issues/3333 Fixes: https://github.com/Exiv2/exiv2/pull/3335 (main branch), https://github.com/Exiv2/exiv2/pull/3345 (0.28.x branch) ### For more information Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.