| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations. |
| If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3. |
| During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls. |
| If a BIND resolver is performing DNSSEC validation and encounters a maliciously crafted zone, the resolver may consume excessive CPU. Authoritative-only servers are generally unaffected, although there are circumstances where authoritative servers may make recursive queries (see: https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries).
This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.46, 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.46-S1, and 9.20.9-S1 through 9.20.20-S1. |
| Allocation of Resources Without Limits or Throttling in ASUS Armoury Crate allows a local user to cause a denial-of-service condition through system memory exhaustion by bypassing driver authentication and allocating an unrestricted amount of memory.Refer to the '
Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information. |
| 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. |
| A vulnerability was found in vllm-project vllm up to 0.29.0. Affected by this issue is some unknown functionality of the file vllm/v1/sample/thinking_budget_state.py. The manipulation results in inefficient algorithmic complexity. It is possible to launch the attack remotely. The pull request to fix this issue awaits acceptance. |
| A security issue exists in MongoDB server's JSON Pointer parser used during $jsonSchema query filter processing. When a find command includes a specially crafted $jsonSchema filter field, the parser processes the input without enforcing adequate limits on iteration count or total allocation size, resulting in significant memory amplification. Under concurrent request load, the cumulative memory consumption can exhaust available heap memory, causing the server's out-of-memory handler to terminate the mongod process and deny service to all connected clients. |
| An uncontrolled resource consumption weakness exists in the request-handling path of the MongoDB sharded-cluster router process. A client that has network access to a router port and has not authenticated can supply connection-monitoring parameters that cause the server to expend CPU resources without any rate limiting, degrading or denying service to legitimate clients. No authentication, elevated privileges, or user interaction is required. Only availability is affected; data confidentiality and integrity are not impacted. |
| Wazuh 4.0.0 before 4.14.7 and 5.0.0-beta2 contain a denial of service vulnerability that allows authenticated attackers with allow_run_as enabled to exhaust CPU resources by submitting arbitrarily deeply nested JSON structures to the POST /security/user/authenticate/run_as endpoint. Attackers can repeatedly submit malformed auth_context bodies with unlimited nesting depth to cause the API framework to consume excessive CPU, denying service to all other API consumers. |
| Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, certain NFS parser state structures were insufficiently bounded. Crafted NFS traffic may cause Suricata to consume excessive memory, potentially resulting in denial of service. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, disable NFS application-layer parsing if it is not needed. |
| Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, DNP3 reassembly could buffer data without sufficient parser-level bounds. Crafted DNP3 traffic may cause Suricata to consume excessive memory, potentially resulting in denial of service. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, disable DNP3 (which is not enabled by default) if it is not needed, and/or define a limited `stream.reassembly.depth` (0 or absent is unlimited). |
| A vulnerability was found in vllm-project vLLM 0.26.0/0.27.0. Affected is the function MoRIIOConnectorScheduler.request_finished/MoRIIOConnectorWorker.get_finished/MoRIIOWrapper._handle_release_message of the file vllm/distributed/kv_transfer/kv_connector/v1/moriio/moriio_connector.py of the component MoRIIO Acknowledgement Handler. Performing a manipulation of the argument request_id/kv_transfer_params results in resource consumption. It is possible to initiate the attack remotely. The project was informed of the problem early through a pull request but has not reacted yet. |
| Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The shared WebSocket decoder permits unbounded message buffering because defragmentation accumulates fragments without a limit and FrameTranscoder accepts declared lengths up to Int.MaxValue. A remote client that completes a WebSocket handshake against an http4s-blaze-server or http4s-ember-server endpoint can exhaust server memory with oversized frames or fragmented messages. The patched decoder applies a configurable 64 MiB default limit to individual frames and defragmented messages through EmberServerBuilder.withMaxWebSocketMessageSize. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Starting in version 8.0.0 and prior to version 8.0.5, LDAP transaction state could store an unbounded number of responses. Because LDAP can be processed over UDP, crafted traffic may cause Suricata to consume excessive memory, potentially resulting in denial of service. Version 8.0.5 contains a fix. As a workaround, disable LDAP application-layer parsing where it is not required. Alternatively, use a rule like `alert ldap any any -> any any (sid: 1; ldap.responses.count: >1024; bypass;)`. |
| Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5,IKEv2 parser state could grow without bounds while storing client transforms. Repeated crafted UDP traffic may cause Suricata to consume excessive memory, potentially resulting in denial of service. Versions 7.0.16 and 8.0.5 fix the issue. Some workarounds are available. Disable IKE application-layer parsing if it is not needed. Alternatively, use a rule to bypass ike flows after the first packets like `alert ike any any -> any any (sid: 2; flow.pkts_toserver: > 256; bypass; noalert;)`. |
| Skipper is an HTTP router and reverse proxy for service composition. Prior to 0.26.22, Handler in dataclients/kubernetes/admission/admission.go passes the body of requests to the Kubernetes admission endpoint at :9443/admission directly to io.ReadAll(r.Body) without a size limit. An attacker with in-cluster network access and a valid Kubernetes client certificate can send a very large body that causes unbounded memory allocation and an out-of-memory termination of the Skipper process. The disruption is limited to Ingress and RouteGroup admission rather than pod creation or unrelated admission controllers, and Kubernetes normally restarts the process. This issue is fixed in version 0.26.22. |
| RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Connection.openTune in connection.go accepts a server-advertised FrameMax below the AMQP frameMinSize value of 4096 bytes because the connection negotiation loop does not enforce the protocol minimum. A malicious or compromised AMQP broker can therefore advertise an extremely small FrameMax, causing later client publications to be fragmented into excessive numbers of frames and write operations. This can consume CPU and stall the client or its host. This issue is fixed in version 1.13.0. |
| RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.recvContent in channel.go preallocates the message body slice with the uint64 ch.header.Size value supplied by an AMQP content header without capping the allocation to the negotiated Connection.Config.FrameSize value. A malicious or compromised broker can send an extreme declared body size and cause the Go runtime to attempt a correspondingly large allocation before body data is received. The allocation can exhaust memory and terminate the client process. This issue is fixed in version 1.13.0. |
| Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. From 0.27.0 until 0.53.1, the uprobe library resolver can allow an unprivileged container to consume excessive CPU and block other containers from starting by supplying a crafted /etc/ld.so.cache file while an uprobe-based gadget is active. The parser in pkg/uprobetracer/ldcache_parser.go trusts EntryCount enough to perform excessive iteration, computes cache1Len with overflowing uint32 arithmetic, and repeatedly calls readStringFromBytes in pkg/uprobetracer/bytes.go, where byte-by-byte immutable string concatenation produces quadratic work. While this processing occurs, pkg/container-hook holds the fanotify container-start pause, allowing a crafted cache to delay startup for roughly a minute, prevent Docker from starting other containers, and degrade monitoring. Processing caches from already-running containers can still consume CPU but does not hold the new-container startup pause, and the advisory establishes no confidentiality or integrity impact. This issue is fixed in version 0.53.1. |
