A denial of service vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user to cause service disruption by supplying a repository release notes configuration file containing deeply nested YAML. When release notes were generated, the configuration file was parsed without a nesting depth limit, causing excessive resource consumption that could render the instance unresponsive. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.18, 3.18.12, 3.19.9, 3.20.5, and 3.21.3. This vulnerability was reported via the GitHub Bug Bounty program.
Quicly is an IETF QUIC protocol implementation intended primarily for use within the H2O HTTP server. Prior to commit 8b178e6, an adversarial peer could send a STREAM frame carrying just one byte at the largest offset being permitted to obtain additional flow control credit, which under certain circumstances could lead to a Denial of Service. Assuming the application prepares a receive buffer for storing all data that arrive out-of-order, up to the largest offset being received, this behavior could lead to the application allocating large amount of memory with the peer sending only a handful of packets, resulting in memory exhaustion. In addition to the receive buffer allocation strategy, the severity of this vulnerability depends on how the application controls the stream concurrency. In case of the H2O HTTP server, under its default setting, this bug increases the maximum amount of memory allocated per connection by about 4 times. This issue has been fixed by commit 8b178e6.
Buffa is a pure-Rust Protocol Buffers implementation with first-class protobuf editions support. Prior to 0.8.0, the decode_unknown_field function in buffa's protobuf decoder allocated heap memory in proportion to untrusted input (unknown fields in the serialized protobuf) without enforcing an allocation budget, affecting any message decoded from untrusted input using code generated with preserve_unknown_fields=true (the default); a small, well-formed payload of nested unknown fields inside a StartGroup could trigger roughly 22x memory amplification (for example a 64 MiB input forcing about 1.4 GB of heap allocation), and length-delimited unknown fields could be sized arbitrarily, so an unauthenticated attacker could crash a process through memory exhaustion because the top-level message size cap did not account for in-decode amplification. This issue is fixed in version 0.8.0.
dd-trace-java is a Datadog APM client for Java. Prior to 1.62.0, W3C baggage extraction does not enforce DD_TRACE_BAGGAGE_MAX_ITEMS, which defaults to 64, or DD_TRACE_BAGGAGE_MAX_BYTES, which defaults to 8192, although those limits apply during baggage injection. A remote unauthenticated attacker can send a baggage HTTP header containing many comma-separated key-value pairs or a single very large value. The extraction path allocates map entries while parsing the attacker-controlled header on every request, causing unbounded CPU and memory consumption in an HTTP service where the baggage propagation style is enabled, which is the default for most affected tracers. This can cause denial of service. This issue is fixed in version 1.62.0.
dd-trace-rb is Datadog's client library for Ruby. Prior to 2.32.0, W3C baggage extraction does not enforce DD_TRACE_BAGGAGE_MAX_ITEMS, which defaults to 64, or DD_TRACE_BAGGAGE_MAX_BYTES, which defaults to 8192, although those limits apply during baggage injection. A remote unauthenticated attacker can send a baggage HTTP header containing many comma-separated key-value pairs or a single very large value. The extraction path allocates entries while parsing the attacker-controlled header on every request, causing unbounded CPU and memory consumption in an HTTP service where the baggage propagation style is enabled, which is the default for most affected tracers. This can cause denial of service. This issue is fixed in version 2.32.0.
### Impact
If this library is used to implement a WebSocket server on top of a TCP server (rather than an HTTP server or framework) using the `WebSocket::Driver.server()` method, or, if it is used to complement a WebSocket client, then a peer can make a single connection consume an unbounded amount of memory by sending an HTTP request or response with a never-ending list of headers. This can lead to the receiving process running out of memory.
### Patches
The issue has been patched in version 0.8.1, by limiting the total size of HTTP request/response lines and headers accepted by the parser to 32 kB. All users should upgrade to this version.
### Workarounds
No known workarounds exist.
### Acknowledgements
This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.
### Impact
The frame format in draft versions of the WebSocket protocol includes a length header that allows an arbitrarily large integer to be encoded as a sequence of bytes with the high bit set. By sending an indefinite sequence of bytes with values `0x80` or above, a server or client can make the other peer parse these bytes into an ever-growing integer. Since Ruby integers are arbitrary precision, this can be used to make a WebSocket connection consume an unbounded amount of memory and lead to the host process running out of memory.
### Patches
The issue has been patched in version 0.8.1. All users should upgrade to this version.
### Workarounds
No known workarounds exist.
### Acknowledgements
This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.
When an HTTP/2 profile is configured on a virtual server, undisclosed requests can cause an increase in memory resource utilization.
Impact:
System performance can degrade until the TMM process is either forced to restart or is manually restarted. This vulnerability allows a remote, unauthenticated attacker to cause a degradation of service that can lead to a denial-of-service (DoS) on the BIG-IP system. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang.
Allocation of Resources Without Limits and Throttling and Sensitive Information in Resource Not Removed Before Reuse in the ASUS System Control Interface driver and ASUS Business Manager allow a local administrator to disclose sensitive information via crafted IOCTL requests, which, in severe cases, may lead to a Denial of Service (DoS) on the system.
Refer to the '
Security Update for ASUS System Control Interface ' section on the ASUS Security Advisory for more information.
Twig versions prior to 3.26.0 contain a vulnerability where IntlDateFormatter and NumberFormatter instances are memoized without limits based on template-controlled arguments. This can lead to excessive resource allocation that persists for the lifetime of the Twig environment. The issue is addressed in version 3.26.0.
### Summary
The CSS selector parser in soupsieve (the CSS selector engine for Beautiful Soup 4) allocates unbounded memory when compiling large comma-separated selector lists. An attacker who can supply a crafted CSS selector string to `soupsieve.compile()` or Beautiful Soup's `.select()` / `.select_one()` can cause the application to allocate hundreds of megabytes of heap memory from a relatively small input, leading to memory exhaustion and denial of service.
To be completely transparent, AI tools helped surface this issue. However, it was independently reproduced and carefully validated. Researchers follow responsible disclosure practices and originally shared this report privately.
A **500 KB** selector string triggers allocation of approximately **244 MB** of heap memory - a 488x— amplification ratio**.
### Details
**Affected code:** `soupsieve/css_parser.py`, lines ~204, 925, 1106
The soupsieve CSS parser splits comma-separated selector lists and creates one `CSSSelector` object per list item. Each `CSSSelector` object contains parsed selector data structures including `SelectorList`, `Selector`, and associated tag/attribute/pseudo-class metadata.
When a selector string such as `a,a,a,...` (with 250,000 comma-separated items) is passed to `sv.compile()`, the parser:
1. Tokenises the entire string and identifies each comma-delimited segment (line ~1106)
2. Parses each segment into a full `Selector` object with all associated metadata (line ~925)
3. Stores all parsed selectors in a `SelectorList` (line ~204)
**Root cause:** No limit is enforced on the number of selectors in a comma-separated list. The parser will attempt to parse and store an arbitrary number of selectors, with each selector object consuming approximately **976 bytes** of heap memory. The total allocation scales linearly with the number of list items, but the amplification ratio (output memory / input bytes) is extremely high because each single-character selector like `a` expands into a complex object graph.
**Attack surface:** Any application that passes user-supplied CSS selectors to `soupsieve.compile()` or Beautiful Soup's `.select()` / `.select_one()`.
### Proof of Concept
```python
import tracemalloc
import soupsieve as sv
tracemalloc.start()
# Build a 500 KB selector string: "a,a,a,...,a" (250,000 items)
count = 250_000
selector = ",".join("a" for _ in range(count))
print(f"Selector string size: {len(selector):,} bytes ({len(selector) / 1024:.0f} KB)")
# Compile the selector — this allocates ~244 MB
compiled = sv.compile(selector)
current, peak = tracemalloc.get_traced_memory()
tracemalloc.stop()
print(f"Compiled selector count: {len(compiled.selectors):,}")
print(f"Current memory: {current / 1024 / 1024:.1f} MB")
print(f"Peak memory: {peak / 1024 / 1024:.1f} MB")
print(f"Amplification ratio: {peak / len(selector):.0f}x")
# Expected output:
# Selector string size: 499,999 bytes (488 KB)
# Compiled selector count: 250,000
# Current memory: ~244 MB
# Peak memory: ~244 MB
# Amplification ratio: ~488x
```
### Impact
**Severity: High**
An attacker can exhaust available memory on any server-side Python application that compiles user-supplied CSS selectors via soupsieve. This can cause:
- **OOM kills** in containerised deployments (Kubernetes pods, Docker containers) with memory limits
- **Swap thrashing** on bare-metal servers, degrading performance for all co-located processes
- **Process termination** via Python's `MemoryError` exception if the system runs out of addressable memory
| Parameter | Value |
|---|---|
| Input size | ~500 KB selector string |
| Memory allocated | ~244 MB |
| Amplification ratio | ~488× |
| Per-object overhead | ~976 bytes per selector |
| Authentication required | None |
| User interaction required | None |
**Scalability of attack:** The memory allocation scales linearly - doubling the selector count doubles memory usage. An attacker can tune the payload to exactly exhaust a target's memory limits. Multiple concurrent requests multiply the effect.
**Downstream exposure:** soupsieve is an automatic dependency of `beautifulsoup4`, one of the most widely installed Python packages. Any web application accepting CSS selectors from users (e.g., web scraping APIs, content filtering tools, CMS preview features) is potentially affected.
---
### Credit
Discovered by a security research team from the University of Sydney, focused on detecting open source software vulnerabilities.
Liyi Zhou: https://lzhou1110.github.io/
Ziyue Wang: https://zyy0530.github.io/
Strick: https://str1ckl4nd.github.io/
Maurice: https://maurice.busystar.org/
Chenchen Yu: https://7thparkk.github.io/
NVIDIA TensorRT-LLM has a vulnerability in its OpenAI-compatible inference API that allows an attacker to cause allocation of GPU resources without any limits or throttling. This can lead to denial of service conditions. The vulnerability is identified as CWE-770 and has a CVSS score of 6.2, indicating medium severity. No official patch or remediation guidance has been provided yet.