Total
1946 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-61870 | 1 Imagemagick | 1 Imagemagick | 2026-07-11 | 2.9 Low |
| ImageMagick before 7.1.2-26 contains a memory leak vulnerability in the VIFF encoder when memory allocation fails. Attackers can trigger allocation failures by processing specially crafted VIFF images to exhaust available memory and cause denial of service. | ||||
| CVE-2026-56366 | 1 Imagemagick | 1 Imagemagick | 2026-07-10 | 3.3 Low |
| ImageMagick before 7.1.2-18 contains a memory leak vulnerability in the META reader when processing APP1JPEG input paths. Attackers can trigger this memory leak by providing specially crafted APP1JPEG image files, causing denial of service through resource exhaustion. | ||||
| CVE-2026-57027 | 1 Juniper Networks | 1 Junos Os | 2026-07-10 | 6.5 Medium |
| A Missing Release of Memory after Effective Lifetime vulnerability in the packet forwarding engine (pfe) of Juniper Networks Junos OS on specific EX Series devices allows an unauthenticated adjacent attacker to cause a Denial-of-Service (DoS).When sFlow is configured in a Virtual Chassis (VC) scenario with EX4100 Series or EX4400 Series devices, multicast traffic which is received on one VC member and sent out on another member leads to a memory leak and ultimately an FPC crash and restart. The leak can be monitored by watching the continuous increase of the buffer values in the output of: user@host> show chassis fpc This issue affects Junos OS on EX4100 Series and EX4400: * all versions before 23.2R2-S7, * 23.4 versions before 23.4R2-S7, * 24.2 versions before 24.2R2-S4, * 24.4 versions before 24.4R2. | ||||
| CVE-2026-13698 | 1 Openvpn | 1 Openvpn | 2026-07-08 | 4.9 Medium |
| A memory leak in OpenVPN version 2.5.0 through 2.5.11, 2.6.0 through 2.6.20 and 2.7_alpha1 through 2.7.4 allows remote attackers with a valid tls-crypt-v2 client key to potentially cause a denial of service | ||||
| CVE-2026-10699 | 1 Progress | 1 Moveit Transfer | 2026-07-08 | 7.5 High |
| Missing release of memory after effective lifetime vulnerability in Progress MOVEit Transfer (Custom Reports modules). This issue affects MOVEit Transfer: from 2025.0.0 before 2025.0.8, from 2025.1.0 before 2025.1.4, from 2026.0.0 before 2026.0.1. | ||||
| CVE-2026-13708 | 1 Tonyc | 1 Imager::file::jpeg | 2026-07-06 | 7.5 High |
| Imager::File::JPEG versions before 1.003 for Perl leak heap memory when reading a JPEG with repeated APP13 markers in i_readjpeg_wiol. i_readjpeg_wiol walks the marker list libjpeg returns and, for each APP13 marker, allocates a new buffer with *iptc_itext = mymalloc(...) and overwrites the previous pointer without freeing it. Only the final payload is later turned into a Perl scalar and freed, so a JPEG with N such markers leaks the first N-1 payloads on every read. In a long-lived process, such as an upload or thumbnailing service, repeated reads accumulate these leaks and exhaust available memory, a denial of service. The same handler ships bundled in the Imager distribution, where versions before 1.032 are affected and the fix ships in 1.032. | ||||
| CVE-2026-43355 | 1 Linux | 1 Linux Kernel | 2026-07-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails. | ||||
| CVE-2026-31732 | 1 Linux | 1 Linux Kernel | 2026-07-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: Fix resource leaks on errors in gpiochip_add_data_with_key() Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"), `gdev->dev.release` is unset. As a result, the reference count to `gdev->dev` isn't dropped on the error handling paths. Drop the reference on errors. Also reorder the instructions to make the error handling simpler. Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 1. | ||||
| CVE-2022-49803 | 1 Linux | 1 Linux Kernel | 2026-07-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove(). | ||||
| 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-35505 | 1 Offis Dicom | 1 Dcmtk Toolkit | 2026-07-01 | 7.5 High |
| An unauthenticated remote attacker can repeatedly send crafted connection requests to leak memory. In single-process deployments the memory grows until the service is killed and the port stops responding until restart. | ||||
| CVE-2026-50254 | 1 Offis Dicom | 1 Dcmtk Toolkit | 2026-07-01 | 7.5 High |
| An unauthenticated remote attacker can repeatedly send a single crafted connection request to leak memory. Against storescp in its default single-process mode, memory grows quickly and the service is eventually killed, after which it stops accepting connections until an operator restarts it. | ||||
| CVE-2026-56364 | 1 Imagemagick | 1 Imagemagick | 2026-07-01 | 1.9 Low |
| ImageMagick before 7.1.2-13 contains a memory leak vulnerability in LoadOpenCLDeviceBenchmark() function when parsing malformed OpenCL device profile XML files with unclosed device elements. Attackers with write access to the OpenCL cache directory can place malicious XML files to exhaust memory and cause denial of service. | ||||
| CVE-2026-56365 | 1 Imagemagick | 1 Imagemagick | 2026-07-01 | 3.7 Low |
| ImageMagick before 7.1.2-19 contains a memory leak vulnerability in the PNG encoder when writing MNG images. Attackers can trigger the encoder failure condition to exhaust memory resources and cause denial of service. | ||||
| CVE-2026-13593 | 1 Gtermars | 1 Css::minifier::xs | 2026-07-01 | 6.5 Medium |
| CSS::Minifier::XS versions before 0.14 for Perl have a memory leak when the entire document is minified away. The minify function has a memory leak when processing a document containing only characters to be removed, such as comments and whitespace. | ||||
| CVE-2026-56018 | 1 Gtermars | 1 Javascript::minifier::xs | 2026-07-01 | 7.5 High |
| JavaScript::Minifier::XS versions before 0.16 for Perl leak memory on every call to minify(), allowing unbounded memory growth. In JsMinify (XS.xs) the cleanup frees only the NodeSet structures and never the per-token contents buffers allocated in JsSetNodeContents; JsDiscardNode unlinks nodes without freeing their contents. Each token's contents buffer is therefore leaked on every call, and the two early returns taken when the node list is empty leak the whole NodeSet. A long-lived process that minifies repeatedly, such as an asset pipeline or a server-side minifier endpoint, grows in memory without bound until it exhausts available memory and is killed, causing denial of service. | ||||
| CVE-2026-13474 | 1 Netscaler | 2 Adc, Gateway | 2026-06-30 | N/A |
| Denial of service via malformed HTTP/2 requests in NetScaler ADC and NetScaler Gateway if HTTP/2 is enabled in HTTP Profile and associated with the virtual server (of type LB, CS, VPN) or the service configured on NetScaler | ||||
| CVE-2025-8277 | 1 Redhat | 2 Enterprise Linux, Openshift | 2026-06-30 | 3.1 Low |
| A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability. | ||||
| CVE-2026-53258 | 1 Linux | 1 Linux Kernel | 2026-06-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: fix leak if split 6 GHz scanning fails rdev->int_scan_req is leaked if cfg80211_scan() fails. Note that it's supposed to be released at ___cfg80211_scan_done() but this doesn't happen as rdev->scan_req is NULL at that point, too, leading to the early return from the freeing function. unreferenced object 0xffff8881161d0800 (size 512): comm "wpa_supplicant", pid 379, jiffies 4294749765 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................ backtrace (crc c867fdb6): kmemleak_alloc+0x89/0x90 __kmalloc_noprof+0x2fd/0x410 cfg80211_scan+0x133/0x730 nl80211_trigger_scan+0xc69/0x1cc0 genl_family_rcv_msg_doit+0x204/0x2f0 genl_rcv_msg+0x431/0x6b0 netlink_rcv_skb+0x143/0x3f0 genl_rcv+0x27/0x40 netlink_unicast+0x4f6/0x820 netlink_sendmsg+0x797/0xce0 __sock_sendmsg+0xc4/0x160 ____sys_sendmsg+0x5e4/0x890 ___sys_sendmsg+0xf8/0x180 __sys_sendmsg+0x136/0x1e0 __x64_sys_sendmsg+0x76/0xc0 x64_sys_call+0x13f0/0x17d0 Found by Linux Verification Center (linuxtesting.org). | ||||
| CVE-2026-53190 | 1 Linux | 1 Linux Kernel | 2026-06-30 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return. | ||||