Monthly
Denial of service in OpenStack Swift's s3api middleware allows an authenticated S3 API user to permanently hang proxy-server workers by sending a truncated aws-chunked PUT request body. Versions 2.36.0 through 2.36.1 and 2.37.0 through 2.37.1 are affected; the defect was introduced in 2.36.0 and fixed in 2.36.2 and 2.37.2. There is no public exploit identified at time of analysis, and EPSS is very low (0.04%, 12th percentile), but the high availability impact and low attack complexity make this a credible operational threat to S3-compatible Swift deployments.
Denial of service in dasel (Go data selector library) versions 3.0.0 through 3.10.0 allows attackers who control selector query strings to pin a CPU core at 100% indefinitely via a 2-byte payload (`r/`). The selector lexer's `matchRegexPattern` closure lacks an end-of-input bounds check, causing an infinite loop when tokenizing unterminated regex literals. No public exploit identified at time of analysis beyond the reporter's PoC, and the issue is not listed in CISA KEV.
Denial of service in OpenMcdf versions up to and including 3.1.3 allows an attacker to permanently hang any thread that processes a crafted Compound File Binary (CFB) file by exploiting an unguarded infinite loop in the BST name-lookup path of DirectoryTree.TryGetDirectoryEntry. The flaw is distinct from - and unaddressed by - the Brent's-algorithm cycle detection added to DirectoryTreeEnumerator in commit 24f445a: while EnumerateEntries() now safely throws a FileFormatException on cyclic input, any subsequent call to OpenStorage(), TryOpenStorage(), OpenStream(), or TryOpenStream() enters the unprotected while-loop and spins at 100% CPU indefinitely. Publicly available proof-of-concept CFB files (5,632 and 7,936 bytes) demonstrate the hang via two distinct API paths; no public exploit identified at time of analysis that escalates beyond DoS, and the vulnerability is not listed in the CISA KEV catalog.
Infinite CPU loop denial-of-service in libheif 1.21.2 and below allows a remote unauthenticated attacker to permanently exhaust a victim application's CPU by delivering a crafted 800-byte HEIF sequence file. The vulnerability triggers during file parsing in Box_stts::get_sample_duration() before any image decoding occurs, meaning any application that opens user-supplied HEIF files is exposed at the moment of file open. No KEV listing and no public exploit have been identified at time of analysis, but the low attack complexity and high availability impact make this a meaningful risk for deployments that process untrusted HEIF content. Vendor-released patch version 1.22.0 resolves the issue.
Traffic Management Microkernel (TMM) in F5 BIG-IP terminates when processing specific traffic against UDP virtual servers configured with Client SSL profiles having Allow Dynamic Record Sizing enabled. Remote unauthenticated attackers can trigger complete service denial by sending crafted traffic, causing TMM process crashes. F5 has released patches per advisory K000160901.
Denial of service in F5 BIG-IP when Packet Velocity Acceleration (ePVA) is enabled allows local network attackers to exhaust ePVA and Traffic Management Microkernel (TMM) resources through crafted ethernet traffic, causing service degradation or unavailability. CVSS 6.5 (medium severity) reflects adjacent network access requirement and high availability impact. Patch availability confirmed via vendor advisory.
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in mtrudel bandit allows unauthenticated remote denial of service via worker process exhaustion. 'Elixir.Bandit.HTTP1.Socket':do_read_chunked_data!/5 in lib/bandit/http1/socket.ex terminates only when the last-chunk line 0\r\n is followed immediately by the empty trailer line \r\n. RFC 9112 §7.1.2 permits zero or more trailer fields between them. When trailers are present, none of the match clauses fit: the catch-all arm computes a negative to_read, calls read_available!/2, receives <<>> on timeout, and tail-recurses with unchanged state. The worker process is pinned for the lifetime of the TCP connection. A handful of concurrent connections sending RFC-conformant chunked requests with trailer fields is sufficient to exhaust the Bandit worker pool and render the server unresponsive to all further traffic. No authentication, special headers, or large payload is required. Proxies such as NGINX and HAProxy legitimately forward trailer-bearing requests, so servers behind such proxies may be affected without any malicious client involvement. This issue affects bandit: from 1.6.1 before 1.11.1.
Loop with unreachable exit condition ('infinite loop') in ASP.NET Core allows an unauthorized attacker to deny service over a network.
barebox version prior to 2026.04.0 contains a denial-of-service vulnerability in ext4 directory parsing in fs/ext4/ext4_common.c where the ext4fs_iterate_dir() function fails to validate that directory entry length values are non-zero. Attackers can supply a malicious ext4 filesystem image with a crafted directory entry containing a direntlen value of 0 to cause an infinite loop during directory listing or path resolution, resulting in the boot process hanging indefinitely.
Mermaid v11.14.0 and earlier are vulnerable to a denial-of-service attack when rendering gantt charts, if they use the [`excludes` attribute](https://mermaid.js.org/syntax/gantt.html?#excludes) to exclude all dates. Example: ``` gantt excludes monday,tuesday,wednesday,thursday,friday,saturday,sunday DoS :2025-01-01, 1d ``` `mermaid.parse` is unaffected, unless you then call the `ganttDb.getTasks()` (which is called when rendering a diagram). This has been patched in: - [v11.15.0](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.15.0) (see [faafb5d49106dd32c367f3882505f2dd625aa30e](https://github.com/mermaid-js/mermaid/commit/faafb5d49106dd32c367f3882505f2dd625aa30e)) - [v10.9.6](https://github.com/mermaid-js/mermaid/releases/tag/v10.9.6) (see [a59ea56174712ee5430dfd5bc877cb5151f501a6](https://github.com/mermaid-js/mermaid/commit/a59ea56174712ee5430dfd5bc877cb5151f501a6)) There are no workarounds available without updating to a newer version of mermaid.
Denial of service in OpenStack Swift's s3api middleware allows an authenticated S3 API user to permanently hang proxy-server workers by sending a truncated aws-chunked PUT request body. Versions 2.36.0 through 2.36.1 and 2.37.0 through 2.37.1 are affected; the defect was introduced in 2.36.0 and fixed in 2.36.2 and 2.37.2. There is no public exploit identified at time of analysis, and EPSS is very low (0.04%, 12th percentile), but the high availability impact and low attack complexity make this a credible operational threat to S3-compatible Swift deployments.
Denial of service in dasel (Go data selector library) versions 3.0.0 through 3.10.0 allows attackers who control selector query strings to pin a CPU core at 100% indefinitely via a 2-byte payload (`r/`). The selector lexer's `matchRegexPattern` closure lacks an end-of-input bounds check, causing an infinite loop when tokenizing unterminated regex literals. No public exploit identified at time of analysis beyond the reporter's PoC, and the issue is not listed in CISA KEV.
Denial of service in OpenMcdf versions up to and including 3.1.3 allows an attacker to permanently hang any thread that processes a crafted Compound File Binary (CFB) file by exploiting an unguarded infinite loop in the BST name-lookup path of DirectoryTree.TryGetDirectoryEntry. The flaw is distinct from - and unaddressed by - the Brent's-algorithm cycle detection added to DirectoryTreeEnumerator in commit 24f445a: while EnumerateEntries() now safely throws a FileFormatException on cyclic input, any subsequent call to OpenStorage(), TryOpenStorage(), OpenStream(), or TryOpenStream() enters the unprotected while-loop and spins at 100% CPU indefinitely. Publicly available proof-of-concept CFB files (5,632 and 7,936 bytes) demonstrate the hang via two distinct API paths; no public exploit identified at time of analysis that escalates beyond DoS, and the vulnerability is not listed in the CISA KEV catalog.
Infinite CPU loop denial-of-service in libheif 1.21.2 and below allows a remote unauthenticated attacker to permanently exhaust a victim application's CPU by delivering a crafted 800-byte HEIF sequence file. The vulnerability triggers during file parsing in Box_stts::get_sample_duration() before any image decoding occurs, meaning any application that opens user-supplied HEIF files is exposed at the moment of file open. No KEV listing and no public exploit have been identified at time of analysis, but the low attack complexity and high availability impact make this a meaningful risk for deployments that process untrusted HEIF content. Vendor-released patch version 1.22.0 resolves the issue.
Traffic Management Microkernel (TMM) in F5 BIG-IP terminates when processing specific traffic against UDP virtual servers configured with Client SSL profiles having Allow Dynamic Record Sizing enabled. Remote unauthenticated attackers can trigger complete service denial by sending crafted traffic, causing TMM process crashes. F5 has released patches per advisory K000160901.
Denial of service in F5 BIG-IP when Packet Velocity Acceleration (ePVA) is enabled allows local network attackers to exhaust ePVA and Traffic Management Microkernel (TMM) resources through crafted ethernet traffic, causing service degradation or unavailability. CVSS 6.5 (medium severity) reflects adjacent network access requirement and high availability impact. Patch availability confirmed via vendor advisory.
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in mtrudel bandit allows unauthenticated remote denial of service via worker process exhaustion. 'Elixir.Bandit.HTTP1.Socket':do_read_chunked_data!/5 in lib/bandit/http1/socket.ex terminates only when the last-chunk line 0\r\n is followed immediately by the empty trailer line \r\n. RFC 9112 §7.1.2 permits zero or more trailer fields between them. When trailers are present, none of the match clauses fit: the catch-all arm computes a negative to_read, calls read_available!/2, receives <<>> on timeout, and tail-recurses with unchanged state. The worker process is pinned for the lifetime of the TCP connection. A handful of concurrent connections sending RFC-conformant chunked requests with trailer fields is sufficient to exhaust the Bandit worker pool and render the server unresponsive to all further traffic. No authentication, special headers, or large payload is required. Proxies such as NGINX and HAProxy legitimately forward trailer-bearing requests, so servers behind such proxies may be affected without any malicious client involvement. This issue affects bandit: from 1.6.1 before 1.11.1.
Loop with unreachable exit condition ('infinite loop') in ASP.NET Core allows an unauthorized attacker to deny service over a network.
barebox version prior to 2026.04.0 contains a denial-of-service vulnerability in ext4 directory parsing in fs/ext4/ext4_common.c where the ext4fs_iterate_dir() function fails to validate that directory entry length values are non-zero. Attackers can supply a malicious ext4 filesystem image with a crafted directory entry containing a direntlen value of 0 to cause an infinite loop during directory listing or path resolution, resulting in the boot process hanging indefinitely.
Mermaid v11.14.0 and earlier are vulnerable to a denial-of-service attack when rendering gantt charts, if they use the [`excludes` attribute](https://mermaid.js.org/syntax/gantt.html?#excludes) to exclude all dates. Example: ``` gantt excludes monday,tuesday,wednesday,thursday,friday,saturday,sunday DoS :2025-01-01, 1d ``` `mermaid.parse` is unaffected, unless you then call the `ganttDb.getTasks()` (which is called when rendering a diagram). This has been patched in: - [v11.15.0](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.15.0) (see [faafb5d49106dd32c367f3882505f2dd625aa30e](https://github.com/mermaid-js/mermaid/commit/faafb5d49106dd32c367f3882505f2dd625aa30e)) - [v10.9.6](https://github.com/mermaid-js/mermaid/releases/tag/v10.9.6) (see [a59ea56174712ee5430dfd5bc877cb5151f501a6](https://github.com/mermaid-js/mermaid/commit/a59ea56174712ee5430dfd5bc877cb5151f501a6)) There are no workarounds available without updating to a newer version of mermaid.