Export limit exceeded: 362480 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (6748 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-56371 | 1 Imagemagick | 1 Imagemagick | 2026-07-02 | 5.3 Medium |
| ImageMagick before 7.1.2-15 and 6.9.13-40 contains a memory leak in coders/txt.c when processing TXT files with texture attributes: the texture object allocated via ReadImage is not released when GetTypeMetrics fails, leaking memory each time a crafted TXT file with a texture attribute is processed. | ||||
| CVE-2026-54786 | 1 Bytecodealliance | 1 Wasmtime | 2026-07-02 | N/A |
| Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. In a loop, guests can use fd_renumber to cause hosts to exhaust both resources and file descriptors. This bug only affects the native implementation of WASIp1, meaning that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. This issue has been fixed in versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2. | ||||
| CVE-2026-32280 | 2 Go Standard Library, Golang | 2 Crypto/x509, Go | 2026-07-02 | 7.5 High |
| 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. | ||||
| CVE-2026-53345 | 1 Linux | 1 Linux Kernel | 2026-07-01 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant. | ||||
| CVE-2026-56149 | 1 Elastic | 1 Elasticsearch | 2026-07-01 | 4.9 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). A user with elevated privileges can submit a specially crafted machine learning request that causes excessive memory consumption, which may render the affected node unavailable. | ||||
| CVE-2026-56150 | 1 Elastic | 1 Fleet Server | 2026-07-01 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Fleet Server can lead to a denial of service via Excessive Allocation (CAPEC-130). An attacker can submit a specially crafted request to an upload endpoint that causes excessive memory consumption, which may render Fleet Server unavailable. | ||||
| CVE-2026-49087 | 1 Elastic | 1 Kibana | 2026-07-01 | 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 bulk deletion request that causes excessive resource consumption, which may render Kibana unavailable. | ||||
| CVE-2026-54428 | 2026-07-01 | 7.5 High | ||
| Allocation of resources without limits or throttling in the HTTP/2 HPACK decoder in Apache HttpComponents Core (5.4.2 and earlier, 5.5-beta1 and earlier) allows an remote attacker to cause a denial of service through memory exhaustion by sending oversized compressed header blocks before the HTTP/2 SETTINGS acknowledgement causes the configured header list size limit to be applied. | ||||
| CVE-2026-14330 | 1 Redhat | 1 Enterprise Linux | 2026-07-01 | 5.5 Medium |
| Multiple unbounded alloca() calls in the PulseAudio protocol server. | ||||
| CVE-2026-57204 | 1 Py-pdf | 1 Pypdf | 2026-07-01 | 6.5 Medium |
| pypdf is a free and open-source pure-python PDF library. Prior to 6.13.3, a maliciously crafted PDF can cause DoS. An attacker who uses this vulnerability can craft a PDF which leads to large memory usage, as MAX_DECLARED_STREAM_LENGTH is sometimes ignored. This requires parsing a content stream without a /Length value. This issue has been fixed in version 6.13.3. | ||||
| CVE-2026-50750 | 1 Apache | 3 Activemq, Activemq All, Activemq Broker | 2026-07-01 | 7.5 High |
| Denial of Service via Out of Memory vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ, Apache ActiveMQ All. Following the fix for CVE-2026-49270 an unauthenticated attacker can now cause broker OOM by sending an repeated BrokerInfo commands without sending a ConnectionInfo, until the broker will crash with OOM. This issue affects Apache ActiveMQ Broker: from 5.19.7 before 5.19.8, from 6.2.6 before 6.2.7; Apache ActiveMQ: from 5.19.7 before 5.19.8, from 6.2.6 before 6.2.7; Apache ActiveMQ All: from 5.19.7 before 5.19.8, from 6.2.6 before 6.2.7. Users are recommended to upgrade to version 6.2.7, which fixes the issue. | ||||
| CVE-2026-50734 | 1 Apache | 2 Activemq, Activemq All | 2026-07-01 | 7.5 High |
| Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ Client, Apache ActiveMQ, Apache ActiveMQ All. An unauthenticated network attacker can cause a broker DoS by sending a crafted WireFormatInfo frame with a malicious large size value. The value is not validate and causes the broker to attempt allocation during pre-auth negotiation which can trigger OOM and crash the broker. This issue affects Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7. Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue. | ||||
| CVE-2026-53917 | 1 Apache | 3 Activemq, Activemq All, Activemq Broker | 2026-06-30 | 7.5 High |
| Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Client, Apache ActiveMQ Broker. An authenticated user can cause a broker DoS by sending a crafted OpenWire Message with a large encoded size value for the map. OpenWire message property maps are unmarshaled without size validation which can trigger OOM and crash the broker. This issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Broker: before 5.19.8, from 6.0.0 before 6.2.7. Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue. | ||||
| CVE-2026-55276 | 1 Apache | 1 Tomcat | 2026-06-30 | 9.1 Critical |
| Always-Incorrect Control Flow Implementation vulnerability in Apache Tomcat meant that special roles and empty authorisation constraints were not included when the effective web.xml was logged. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.22, from 10.1.0-M1 through 10.1.55, from 9.0.0.M1 through 9.0.118, from 8.5.0 through 8.5.100. Other versions that have reached end of support may also be affected. Users are recommended to upgrade to version 11.0.23, 10.1.56 or 9.0.119 which fixes the issue. | ||||
| CVE-2026-8037 | 1 Progress | 4 Ecs Connection Manager, Loadmaster, Moveit Waf and 1 more | 2026-06-30 | 9.6 Critical |
| OS Command Injection Remote Code Execution Vulnerability in API in Progress ADC Products allows an un-authenticated attacker to execute arbitrary commands on the LoadMaster appliance by exploiting unsanitized input in multiple command endpoints | ||||
| CVE-2025-32049 | 1 Redhat | 6 Enterprise Linux, Rhel Aus, Rhel E4s and 3 more | 2026-06-30 | 7.5 High |
| A flaw was found in libsoup. The SoupWebsocketConnection may accept a large WebSocket message, which may cause libsoup to allocate memory and lead to a denial of service (DoS). | ||||
| CVE-2023-32255 | 1 Redhat | 1 Enterprise Linux | 2026-06-29 | 5.3 Medium |
| A flaw was found in the Linux kernel's ksmbd component. A memory leak can occur if a client sends a session setup request with an unknown NTLMSSP message type, potentially leading to resource exhaustion. | ||||
| CVE-2026-42440 | 1 Apache | 1 Opennlp | 2026-06-29 | 7.5 High |
| OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader Versions Affected: before 1.9.5 before 2.5.9 before 3.0.0-M3 Description: The AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUM_PREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source. A crafted .bin model file in which any of these count fields is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load. The practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins. Mitigation: * 2.x users should upgrade to 2.5.9. * 3.x users should upgrade to 3.0.0-M3. Note: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Users who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks. | ||||
| CVE-2026-13545 | 1 D-link | 1 Dcs-935l | 2026-06-29 | 8.8 High |
| A vulnerability has been found in D-Link DCS-935L 1.10.01. This affects the function sub_400E40 of the file setconf.cgi of the component POST Parameter Handler. Such manipulation of the argument UID leads to os command injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2026-48042 | 1 Envoyproxy | 1 Envoy | 2026-06-29 | 7.5 High |
| Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.35.11, 1.36.7, 1.37.3, and 1.38.1, destructor of JSON Object results in stack overflow when deeply O(100K) nested objects are present. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1. | ||||