Total
1927 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-69781 | 1 Microsoft | 4 Windows 11 24h2, Windows 11 25h2, Windows 11 26h1 and 1 more | 2026-09-10 | N/A | 6.5 MEDIUM |
| Missing release of memory after effective lifetime in Windows DHCP Client allows an unauthorized attacker to deny service over an adjacent network. | |||||
| CVE-2026-70065 | 1 Microsoft | 7 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 4 more | 2026-09-10 | N/A | 7.5 HIGH |
| Missing release of memory after effective lifetime in Windows DHCP Server allows an unauthorized attacker to deny service over a network. | |||||
| CVE-2026-18076 | 1 Ibm | 1 I | 2026-09-10 | N/A | 4.3 MEDIUM |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to cause a denial of service due to a memory leak. | |||||
| CVE-2026-47888 | 1 Vmware | 1 Spring Framework | 2026-09-10 | N/A | 7.5 HIGH |
| A Spring RSocket application is exposed to a memory leak via a malformed SETUP frame. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.0.RELEASE - 5.2.25.RELEASE | |||||
| CVE-2026-52734 | 2026-09-09 | N/A | 5.3 MEDIUM | ||
| ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, an unauthenticated P2P peer can cause the mempool download pipeline to retain transactions after verification reaches the outer RATE_LIMIT_DELAY timeout. In zebrad/src/components/mempool/downloads.rs, Downloads::poll_next removed cancel_handles entries after success and ordinary verification errors, but tokio::time::error::Elapsed did not carry the UnminedTxId needed to remove the timed-out entry. Each retained cancel_handles entry could hold a full Gossip::Tx(UnminedTx), while normal mined-transaction cleanup could not match attacker transactions and no periodic garbage collection or count cap existed. Sustained traffic therefore caused monotonic memory growth until swap pressure degraded the node or the operating system terminated the zebrad process for exhausting memory. This issue is fixed in version 4.5.0. | |||||
| CVE-2026-38819 | 2026-09-09 | N/A | 5.3 MEDIUM | ||
| Multiple memory leaks in openNDS before 11.0.0 allow an unauthenticated attacker on the captive portal network to exhaust all available memory on the device within minutes. | |||||
| CVE-2026-13148 | 2026-09-09 | N/A | N/A | ||
| Missing release of memory after effective lifetime vulnerability in Softing smartLink allows resource leak exposure. This issue affects smartLink HW-PN: from 1.04 before 1.10. | |||||
| CVE-2026-69405 | 1 Microsoft | 7 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 4 more | 2026-09-09 | N/A | 5.7 MEDIUM |
| Missing release of memory after effective lifetime in Windows DHCP Server allows an authorized attacker to deny service over an adjacent network. | |||||
| CVE-2026-69497 | 1 Microsoft | 7 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 4 more | 2026-09-09 | N/A | 6.5 MEDIUM |
| Missing release of memory after effective lifetime in Windows DHCP Server allows an authorized attacker to deny service over a network. | |||||
| CVE-2026-48006 | 1 Netty | 1 Netty | 2026-09-09 | N/A | 7.5 HIGH |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process. Versions 4.1.135.Final and 4.2.15.Final patch the issue. | |||||
| CVE-2024-3653 | 2026-09-08 | N/A | 5.3 MEDIUM | ||
| A vulnerability was found in Undertow. This issue requires enabling the learning-push handler in the server's config, which is disabled by default, leaving the maxAge config in the handler unconfigured. The default is -1, which makes the handler vulnerable. If someone overwrites that config, the server is not subject to the attack. The attacker needs to be able to reach the server with a normal HTTP request. | |||||
| CVE-2026-69809 | 2026-09-08 | N/A | 7.5 HIGH | ||
| Missing release of memory after effective lifetime in Active Directory Domain Services allows an unauthorized attacker to deny service over a network. | |||||
| CVE-2026-69588 | 2026-09-08 | N/A | 7.5 HIGH | ||
| Missing release of memory after effective lifetime in Windows TCP/IP allows an unauthorized attacker to deny service over a network. | |||||
| CVE-2026-18313 | 2026-09-08 | N/A | 4.3 MEDIUM | ||
| rpcapd can allocate up to 65536 bytes per each RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message received from the client, but it never frees the memory, so it leaks memory even under normal use. A malicious client can cause the server to leak memory substantially faster. | |||||
| CVE-2026-16028 | 2026-09-08 | N/A | 7.5 HIGH | ||
| Protocol::HTTP2 versions before 1.14 for Perl allow memory exhaustion via closed streams that stream_state never removes from the connection stream table. When a stream reaches the CLOSED state, stream_state returns the concurrency slot and clears most of the stream's keys, but the entry itself stays in the connection stream table and nothing in the distribution removes it. Stream identifiers increase monotonically, so a peer can open and close streams on one connection indefinitely, each close leaving a residual entry that is retained for the life of the connection. SETTINGS_MAX_CONCURRENT_STREAMS does not bound this. That setting caps how many streams are live at once and is enforced, while the growth is made of streams the cap has already released, so it accumulates with concurrency never exceeding one. The client keeps the same table and grows the same way against a hostile server. Measured against a server built on this module, roughly 920 bytes are retained per closed stream for about 19 bytes on the wire, so 100,000 sequential streams on one connection grow server resident memory by about 88 MiB. The streams are ordinary requests that the application accepts and completes. | |||||
| CVE-2026-53134 | 1 Linux | 1 Linux Kernel | 2026-09-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes. | |||||
| CVE-2026-46303 | 1 Linux | 1 Linux Kernel | 2026-09-08 | N/A | 8.2 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice. | |||||
| CVE-2026-46021 | 1 Linux | 1 Linux Kernel | 2026-09-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration. | |||||
| CVE-2026-43089 | 1 Linux | 1 Linux Kernel | 2026-09-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables. | |||||
| CVE-2026-23399 | 1 Linux | 1 Linux Kernel | 2026-09-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nf_tables: nft_dynset: fix possible stateful expression memleak in error path If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released. unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330 | |||||