Export limit exceeded: 424090 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3375 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-58058 | 2026-09-26 | 5.3 Medium | ||
| xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14. | ||||
| CVE-2026-50276 | 2026-09-25 | 7.5 High | ||
| 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. | ||||
| CVE-2026-95845 | 2 Moquette, Moquette-io | 2 Moquette, Moquette | 2026-09-25 | 7.5 High |
| Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, the broker does not enforce a maximum length for pending per-session message queues. When a fast publisher sends messages to a slow subscriber whose in-flight window is full, queued messages can accumulate without bound in memory or persistent storage. Remote clients can use this condition to exhaust broker resources and cause a denial of service. This issue is fixed in version 0.18.1. | ||||
| CVE-2026-91864 | 1 Apache | 1 Neethi | 2026-09-25 | 7.5 High |
| A specially crafted WS-Policy document can pack unlimited content inside a policy assertion, which Neethi copies into memory without counting it against its size limits, exhausting the heap (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. | ||||
| CVE-2026-91865 | 1 Apache | 1 Neethi | 2026-09-25 | 7.5 High |
| A small WS-Policy document using repeated policy references can force Neethi to re-expand the same references exponentially during normalization, consuming huge amounts of CPU and memory (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. | ||||
| CVE-2026-91866 | 1 Apache | 1 Neethi | 2026-09-25 | 7.5 High |
| A specially crafted pair of WS-Policy documents can force Neethi's policy-intersection to do exponential amounts of work, pinning the CPU for a long time (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. | ||||
| CVE-2026-65827 | 1 Docmost | 1 Docmost | 2026-09-25 | 6.5 Medium |
| Docmost is open-source collaborative wiki and documentation software. From 0.21.0 until 0.95.0, any authenticated workspace member with edit rights to a space can upload an archive to the page-import feature whose ZIP extraction routine does not limit total uncompressed size, per-entry size, or entry count. The extractor writes entries to the server temp directory and automatically extracts one nested ZIP, allowing an outer upload within the default 200 MB limit to expand by multiple GB. The resulting disk exhaustion can crash the import worker and degrade or take down the instance for all tenants. This issue is fixed in version 0.95.0. | ||||
| CVE-2026-61629 | 1 Lucasdillmann | 1 Nginx-ignition | 2026-09-24 | 7.5 High |
| nginx ignition is a user interface for the nginx web server. In versions 2.29.0 through 2.40.0, the gin i18n middleware in nginx-ignition's API server runs in front of every HTTP request and calls `golang.org/x/text/language.ParseAcceptLanguage` on the raw `Accept-Language` header without imposing any size or shape filter. The underlying parser has quadratic-time behaviour on long lists of malformed language tags. The CVE-2022-32149 guard that golang.org/x/text added in v0.3.8 caps the number of `-` characters in the input at 1000, but it does not cap `_` characters even though the parser's internal scanner aliases `_` to `-` before parsing. A single unauthenticated GET request with an `Accept-Language` header built out of `_` separators burns about 2.4 seconds of server CPU on the host running nginx-ignition; ten concurrent attackers saturate a ten-core box for the duration of the attack while consuming ~10 MiB/s of upstream bandwidth. Version 2.40.1 fixes this issue. | ||||
| CVE-2026-56814 | 1 Elixir-plug | 1 Plug | 2026-09-24 | N/A |
| Plug.Parsers.MULTIPART, the multipart request-body parser used to handle file uploads and multipart forms, does not enforce its :length budget against all consumed resources, allowing an unauthenticated remote attacker to cause denial of service. The parser charges the :length limit only for part body bytes; part header bytes are never counted, and a part with an empty body costs zero. Because every part whose Content-Disposition carries a non-empty filename creates a fresh temporary file (via Plug.Upload) and retains a Plug.Upload struct for the duration of the request, an attacker can send a single request composed of many empty-body file parts. Such a request stays well under the configured :length limit (8,000,000 bytes by default) while creating one temporary file per part, leading to inode and disk exhaustion and unbounded memory growth. Any application using Plug.Parsers with the :multipart parser is affected, and no authentication is required, only reachability of a multipart endpoint over HTTP. This vulnerability is associated with program files lib/plug/parsers/multipart.ex and program routines Plug.Parsers.MULTIPART.parse_multipart/2, Plug.Parsers.MULTIPART.parse_multipart_headers/5, Plug.Parsers.MULTIPART.parse_multipart_body/4, and Plug.Parsers.MULTIPART.parse_multipart_file/4. This issue affects plug: from 1.4.0-rc.0 before 1.16.6, from 1.17.0 before 1.17.4, from 1.18.0 before 1.18.5, from 1.19.1 before 1.19.5, and from 1.20.0 before 1.20.3. | ||||
| CVE-2026-56811 | 1 Phoenixframework | 1 Phoenix | 2026-09-24 | 7.5 High |
| Allocation of Resources Without Limits or Throttling vulnerability in phoenixframework phoenix (Phoenix.Socket module) allows an unauthenticated attacker to cause a denial of service against any endpoint that mounts a Phoenix socket with a reachable channel transport (WebSocket or LongPoll). This vulnerability is associated with program files lib/phoenix/socket.ex and program routine 'Elixir.Phoenix.Socket':handle_in/4. Phoenix transports do not limit the number of channels that a single transport process may join. Every phx_join message a client sends over one connection starts a persistent channel process, and the socket process accepts an unbounded number of them. A single unauthenticated client can therefore open one WebSocket or LongPoll connection and stream a large number of phx_join messages, spawning hundreds of thousands of channel processes over that one connection and eventually reaching the BEAM maximum process limit. Once the process table is exhausted the virtual machine can no longer start new processes, denying service to legitimate traffic across the whole node. Because the amplification happens inside a single connection, network-layer connection caps and rate limiting do not mitigate it. The fix adds a :max_channels_per_transport option (default 100) that bounds the number of channels a single transport process can join, forcing abusive clients to open many connections instead, where external load balancers and reverse proxies can throttle them. This issue affects phoenix: from 0.11.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9. | ||||
| CVE-2026-77619 | 1 Vectordotdev | 1 Vector | 2026-09-24 | 7.5 High |
| Vector is a high-performance observability data pipeline. From 0.15.0 until 0.57.0, the logstash source reads a 32-bit compressed-frame length from the network and uses it to size an in-memory buffer without an upper bound. An unauthenticated remote peer that can reach the default 0.0.0.0:5044 listener can send a minimal frame declaring a multi-gigabyte payload, causing an excessive allocation that can abort Vector or invoke the host OOM killer. Because the allocation follows the declared length rather than bytes transmitted, the attacker has low resource cost, and process termination can halt log ingestion for every tenant on a shared pipeline. This issue is fixed in version 0.57.0. | ||||
| CVE-2026-86040 | 1 Libp2p | 1 Libp2p | 2026-09-24 | 7.5 High |
| libp2p is a JavaScript implementation of the libp2p networking stack. Prior to 11.0.26, @libp2p/floodsub accepts unauthenticated RPC frames on /floodsub/1.0.0 through PeerStreams.attachInboundStream in packages/floodsub/src/peer-streams.ts without protobuf element limits, then processRpc and processRpcSubOpt in packages/floodsub/src/floodsub.ts synchronously process the subscriptions array without a per-frame cap. A single bounded-size frame can decode into millions of empty subscription entries that block the event loop, while hundreds of thousands of unique-topic SUBSCRIBE entries allocate PeerSet objects in this.topics that are not removed after peer removal or stop. Empty entries cause CPU exhaustion but do not grow this.topics; persistent memory growth requires unique topics. The subscription path bypasses message signature validation and the message-only processing queue, allowing a remote peer to cause sustained CPU denial of service, memory exhaustion, out-of-memory termination, and node unavailability. The issue is fixed in version 11.0.26. | ||||
| CVE-2026-48854 | 1 Elixir-grpc | 1 Grpc | 2026-09-24 | N/A |
| Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc allows unauthenticated attackers to exhaust the BEAM's memory and crash the server by streaming a large or slow-trickle unary request body. 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':read_full_body/3 (lib/grpc/server/adapters/cowboy/handler.ex) accumulates every received chunk into a single growing binary with no size cap. Additionally, when the client omits the grpc-timeout header, the per-chunk read timeout resolves to :infinity, allowing a slow-trickle client to keep the connection alive indefinitely while memory grows. A single connection is sufficient to exhaust server memory and crash the node. This issue affects grpc: from 0.3.0-alpha.2 before 1.0.0. | ||||
| CVE-2026-48853 | 1 Elixir-grpc | 1 Grpc | 2026-09-24 | 9.8 Critical |
| Deserialization of Untrusted Data and Allocation of Resources Without Limits or Throttling vulnerabilities in elixir-grpc grpc allow unauthenticated attackers to crash the BEAM node via atom table exhaustion and, when a decoded term flows into a call site that invokes it, achieve remote code execution on the server. 'Elixir.GRPC.Codec.Erlpack':decode/2 (lib/grpc/codec/erlpack.ex) calls :erlang.binary_to_term/1 on the raw gRPC message body without the :safe option, no size bound, and no type guard. Any unauthenticated peer that sends a request with Content-Type: application/grpc+erlpack can send a crafted payload that mints arbitrary new atoms (which are never garbage-collected, exhausting the bounded atom table and crashing the VM) or that encodes a fun term which, if applied anywhere downstream, executes attacker-controlled code inside the server process. This issue affects grpc: from 0.4.0 before 1.0.0. | ||||
| CVE-2026-48597 | 1 Elixir-tesla | 1 Tesla | 2026-09-24 | 5.9 Medium |
| Allocation of Resources Without Limits or Throttling vulnerability in elixir-tesla tesla allows denial of service via atom table exhaustion in Tesla.Adapter.Mint. Tesla.Adapter.Mint.open_conn/2 converts the URL scheme of every outgoing request to a BEAM atom via String.to_atom(uri.scheme) with no allow-list validation. BEAM atoms are never garbage-collected and the atom table is bounded (approximately 1,048,576 entries by default). An attacker who can influence the URL of a Tesla request — either via an application-level URL-forwarding feature (webhook, proxy, importer) or via a Location header returned by a server when Tesla.Middleware.FollowRedirects is in the pipeline — can mint one fresh permanent atom per request by varying the scheme string. After enough requests the atom table fills and the VM crashes, taking down the entire application. This issue affects tesla: from 1.3.0 before 1.18.3. | ||||
| CVE-2026-96764 | 1 Kvcache-ai | 1 Mooncake | 2026-09-24 | 4.3 Medium |
| A weakness has been identified in kvcache-ai mooncake up to 0.3.12/0.3.14-rc1. Impacted is the function MasterService::GetReplicaListByRegex of the component Regular Expression Handler. Executing a manipulation can lead to allocation of resources. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-59980 | 1 Python-hyper | 1 Hpack | 2026-09-24 | 7.5 High |
| hpack is an HTTP/2 Header Encoding for Python. Prior to version 4.2.0, unbounded variable integer decoding can cause run-away computation on malformed input leading to O(n^2) runtime, effectively blocking further processing with large enough unsanitized input. A fix is available in python-hyper/hpack v4.2.0 to restricted variable integer decoding to uint32 to prevent run-away computation. As a workaround, sanitize input to hpack decoder for long sequences of `0xFF` values to prevent malicious use. | ||||
| CVE-2026-96609 | 1 Robur | 1 Albatross | 2026-09-24 | N/A |
| Robur Albatross 1.0.0 through 2.x before 2.7.2 does not limit use of the ring buffer, leading to an albatross-console loop with no recognized termination condition. This is only exploitable by users who can send console subscription commands to unikernels that produce sufficient log output to fill the ring buffer (1024 lines). It is not exploitable by unauthorized clients. | ||||
| CVE-2026-59990 | 1 Typelevel | 1 Jawn | 2026-09-23 | 7.5 High |
| Jawn is an open source JSON parser. Prior to 1.7.0, Jawn parse methods accept arbitrarily deep JSON array and object nesting without a depth limit, allowing a remote attacker who can submit untrusted JSON to grow parser contexts until the JVM heap is exhausted. The resulting java.lang.OutOfMemoryError is a fatal Scala error that is not ordinarily handled by scala.util.Try or cats.effect.IO, causing denial of service. This issue is fixed in version 1.7.0. | ||||
| CVE-2026-92284 | 1 Caddyserver | 1 Caddy | 2026-09-23 | N/A |
| Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, in modules/caddyhttp/replacer.go, resolving http.request.body reads the complete request body with an unbounded io.Copy before request-body middleware limits apply, allowing memory exhaustion and process termination. | ||||