Total
2712 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-19474 | 1 Fastify | 1 Fastify-multipart | 2026-09-02 | N/A | 7.5 HIGH |
| @fastify/multipart is a multipart form-data parser for Fastify. In versions from 3.0.0 up to but not including 10.1.1, request.saveRequestFiles() can leave completed temporary files on disk when a client disconnects while the parser is advancing between multipart parts. The iterator rejection that occurs between parts falls outside the per-file cleanup path, so an earlier completed file is never removed. An unauthenticated client can repeat this to cause persistent, linear disk consumption, leading to denial of service. This is an incomplete-fix variant of CVE-2025-24033. The issue is fixed in @fastify/multipart 10.1.1. Users should upgrade to 10.1.1. | |||||
| CVE-2026-58063 | 1 Bouncycastle | 3 Bc-java, Bouncy Castle For Java Lts, Fips Java Api | 2026-09-02 | N/A | 5.3 MEDIUM |
| In Bouncy Castle for Java before 1.85, BCFKS keystore load honours unbounded KDF cost from untrusted file. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series). | |||||
| CVE-2026-72682 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user holding only low, read-level Agent Builder privileges could submit a specially crafted request that causes Kibana to consume an unbounded amount of memory, terminating the process and denying service to all users of the instance. | |||||
| CVE-2026-72652 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted request that causes excessive resource consumption, which may render Kibana unavailable. | |||||
| CVE-2026-72659 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A specially crafted, malformed payload submitted to a Kibana visualization feature by an authenticated user holding only low-privileged access is not correctly validated before use. Processing the request causes unbounded memory growth in the Kibana process, which is terminated by the host once available memory is exhausted. Kibana then becomes unavailable to all users until the service is restarted. | |||||
| CVE-2026-72651 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with read-only privileges to the alerting feature could submit a specially crafted, malformed payload that causes the Kibana process to consume excessive resources. A single request is sufficient to leave Kibana unable to serve requests for all users until the process is restarted. | |||||
| CVE-2026-49089 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A query expression accepted by a connector reporting operation was processed without any limit on its size, and an oversized expression caused the Kibana process to spend an unbounded amount of time evaluating it. An authenticated user with read-only privileges was able to send a single request that left Kibana unable to serve any user until the process was restarted. | |||||
| CVE-2026-72667 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A specially crafted request submitted by an authenticated user with minimal privileges to a validation capability of the Observability log analysis feature causes Kibana to perform an unbounded amount of concurrent work. This can exhaust the memory available to the Kibana process and make Kibana unavailable to all users until it is restarted. The severity of the outcome depends on the resources allocated to the deployment; on well-provisioned deployments a single request may cause degraded performance and elevated memory pressure rather than a full outage, but the request is inexpensive to repeat. | |||||
| CVE-2026-33465 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user with low-level permissions could submit a specially crafted request that causes excessive resource consumption, which may render Kibana unavailable. | |||||
| CVE-2026-72674 | 1 Elastic | 1 Kibana | 2026-09-02 | N/A | 6.5 MEDIUM |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A user-supplied list of document fields accepted by the Kibana Playground for RAG feature was neither bounded in length nor de-duplicated before it was used to assemble the response for each matching document. A single crafted request could therefore make Kibana build a response far larger than the data it was derived from, and the resulting processing and memory pressure exhausts the resources of the Kibana instance. | |||||
| CVE-2026-84775 | 2026-09-02 | N/A | 5.3 MEDIUM | ||
| Unauthenticated Denial of Service Attack in Really Simple SSL <= 9.8.0 versions. | |||||
| CVE-2026-26445 | 2026-09-02 | N/A | 7.5 HIGH | ||
| stomper 5e2741e is vulnerable to Denial of Service. A malicious client can send partial STOMP frames and keep the TCP connections open, which, combined with the broker s use of edge-triggered epoll (EPOLLET) and MSG_PEEK in recv(), causes sockets to enter a permanent half-read state. When enough such connections accumulate, the broker stops receiving any further epoll events for those sockets and eventually hangs in epoll_wait, effectively refusing to process new messages. | |||||
| CVE-2024-39478 | 1 Linux | 1 Linux Kernel | 2026-09-02 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Do not free stack buffer RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. | |||||
| CVE-2023-39533 | 1 Libp2p | 1 Go-libp2p | 2026-09-01 | N/A | 7.5 HIGH |
| go-libp2p is the Go implementation of the libp2p Networking Stack. Prior to versions 0.27.8, 0.28.2, and 0.29.1 malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p versions 0.27.8, 0.28.2, and 0.29.1 restrict RSA keys to <= 8192 bits. To protect one's application, it is necessary to update to these patch releases and to use the updated Go compiler in 1.20.7 or 1.19.12. There are no known workarounds for this issue. | |||||
| CVE-2026-59848 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Hardened Images | 2026-09-01 | N/A | 5.3 MEDIUM |
| A flaw was found in libssh. A malicious SFTP server can send responses for unknown request IDs that libssh clients keep queued indefinitely, causing unbounded memory growth and client-side denial of service. | |||||
| CVE-2026-74837 | 2026-09-01 | N/A | N/A | ||
| Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_typescript allows an unauthenticated attacker to exhaust the BEAM atom table and abort the node via client-supplied RPC field names. AshTypescript.FieldFormatter.convert_to_field_atom/2 in lib/ash_typescript/field_formatter.ex converts a client-supplied field name to an atom with String.to_atom/1 when no matching atom already exists. It delegates first to parse_input_field/2, which resolves the name with String.to_existing_atom/1 and falls back to returning the plain string; convert_to_field_atom/2 then mints an atom from that string rather than treating the name as unknown. RPC field selection reaches it for every requested field name through AshTypescript.Rpc.FieldProcessing.FieldSelector, which resolves each name before checking that the field exists, with no allowlist, length bound, or rate limit. Atoms are never garbage collected, so each distinct name mints a permanent one and the VM aborts once the atom table limit is reached. A field name over 255 characters additionally raises an uncaught SystemLimitError. This issue affects ash_typescript: from 0.1.0 before 0.18.0. | |||||
| CVE-2026-82722 | 2026-09-01 | N/A | N/A | ||
| Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_admin lets any client that can reach the admin LiveView exhaust the BEAM atom table and crash the entire node. Two LiveView event handlers interned atoms from unvalidated client input: AshAdmin.PageLive's set_actor built modules from the resource/domain payload with Module.concat/1, and AshAdmin.Components.Resource.Show's calculate converted every submitted form key with String.to_atom/1. Atoms are never garbage collected and the table is capped, so flooding either event with random names mints a new atom per request until the VM aborts, taking down every application on the node. The fix resolves the submitted resource/domain against the known shown resources and maps calculation keys to declared arguments, so no client-supplied string is interned. This issue affects ash_admin: from 0.1.0 before 1.3.1. | |||||
| CVE-2026-77856 | 2026-09-01 | N/A | N/A | ||
| Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_typescript allows an unauthenticated attacker to exhaust the BEAM atom table and abort the node via client-supplied typed struct field names. resolve_typed_struct_field/2 in lib/ash_typescript/rpc/field_processing/field_selector.ex looks a client-supplied field name up in the typed struct's reverse map and, when it finds no match, falls back to String.to_atom/1. Because this runs before any field-existence check, an unresolvable name mints a permanent atom rather than being rejected as unknown. Atoms are never garbage collected, so a request carrying many distinct names on a typed struct field grows the atom table until the VM aborts at its limit. This issue affects ash_typescript: from 0.11.0 before 0.18.0. | |||||
| CVE-2026-81636 | 2026-09-01 | N/A | N/A | ||
| Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_graphql allows an unauthenticated client to bypass the configured GraphQL query-complexity limit and force an unbounded database read. AshGraphql.Graphql.Resolver.query_complexity/3 multiplies child complexity by the requested page size only when the argument map contains :limit (offset pagination). Relay connections and keyset pagination use first and last, which never match that clause and fall through to the catch-all that returns child_complexity + 1. A nested relay query such as posts(first: 500) { edges { node { comments(first: 500) { ... } } } } therefore scores as trivially cheap while materializing the full fan-out, passing an Absinthe max_complexity cap that rejects the equivalent limit-based query. The fix adds first and last clauses clamped to the action's page size. This issue affects ash_graphql: from 0.16.23 before 1.11.0. | |||||
| CVE-2026-58107 | 2026-09-01 | N/A | N/A | ||
| CodeChecker's massStoreRun processing path performs one-shot decompression of attacker-controlled, Base64-encoded zlib data without enforcing a maximum decompressed size. An authenticated user with permission to store analysis runs can submit a highly compressed payload that expands to a significantly larger byte sequence. Because the entire decompressed output is materialized in memory before being written to a temporary file, a sufficiently large payload may exhaust process or host memory and consume substantial disk space, resulting in denial of service. | |||||