Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-107692exploit | 4.8 medium | 0.00% | no CPE yet | The War Thunder game client transmits its authentication bearer token (auth_jwt) in the very first data packet after the TCP handshake, using only LZ4 compression rather than encryption. An attacker positioned on the network path can passively intercept and decompress this packet to reveal the plaintext JSON payload. This vulnerability allows for temporary authenticated impersonation, enabling an attacker to access game services and certain user data (such as email address and displayed phone number) as the affected user. While this allows for unauthorized access to gameplay, it does not facilitate full account takeover, as it cannot be used to modify account security settings, change passwords, bypass two-factor authentication for account management, or access financial information. | Thu 22 Oct |
| CVE-2019-17543 | 8.1 high | 10.0% | lz4_project, lz4 | LZ4 before 1.9.2 has a heap-based buffer overflow in LZ4_write32 (related to LZ4_compress_destSize), affecting applications that call LZ4_compress_fast with a large input. (This issue can also lead to data corruption.) NOTE: the vendor states "only a few specific / uncommon usages of the API are at risk." | 14 Oct |
| CVE-2021-3520 | 9.8 critical | 3.0% | lz4_project, netapp, lz4, active_iq_unified_manager, cloud_backup | There's a flaw in lz4. An attacker who submits a crafted file to an application linked with lz4 may be able to trigger an integer overflow, leading to calling of memmove() on a negative size argument, causing an out-of-bounds write and/or a crash. The greatest impact of this flaw is to availability, with some potential impact to confidentiality and integrity as well. | 14 Oct |
| CVE-2026-42583 | 7.5 high | 0.00% | netty | Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final. | Mon 26 Oct |
| CVE-2026-54616 | 7.1 high | 0.00% | no CPE yet | NanaZip is the 7-Zip derivative intended for the modern Windows experience. From version 1.0.88.0 until stable version 6.0.1698.0 and preview version 6.5.1742.0, the Lz4Decode function in NanaZip.Core/SevenZip/CPP/7zip/Archive/SquashfsHandler.cpp rejects only a zero return from LZ4_decompress_safe even though malformed input produces a negative error value. The negative int is converted to the unsigned SizeT destLen and then truncated into outBufWasWrittenSize, causing ReadBlock to trust an attacker-inflated _cachedUnpackBlockSize. During fragment extraction, an attacker-controlled inode Offset can make memcpy read beyond the _cachedBlock heap allocation and place adjacent heap contents in the extracted file, or crash the process. This issue is fixed in stable version 6.0.1698.0 and preview version 6.5.1742.0. | 18 Oct |
| CVE-2026-59949 | 6.5 medium | 0.00% | no CPE yet | yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1. | Thu 22 Oct |
| CVE-2026-106450 | 5.3 medium | 0.00% | no CPE yet | yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4. | 9 Oct |
| CVE-2026-98067 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: erofs: disable LZ4 rolling decompression for now LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages: For many cases, it is needed for users to read small data within a compressed extent (pcluster), either due to random small read, or since uptodate folios (typically order-0) cannot be reused for decompression again since decompression algorithm refills already-uptodate folios. Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed data, so in theory only a bounded rolling window of temporary pages is needed when decompressing. It can save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k LZ4 compressed extent, which means it needs 146 extra pages per request in the worst case if rolling decompression is disabled. However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when the source and destination ranges do not overlap (IOWs, inline decompression doesn't need to be considered here). That breaks the rolling assumption and makes the optimization broken. Disable it for now to make sure the data correctness first since EROFS is used everywhere now: The rolling window approach can be revived once we either ensure that the official LZ4 code always copies forward for non-overlapping ranges or maintain our own LZ4 implementation in EROFS. The main impact is a higher runtime memory footprint; However, recent commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4 decompression") helps mitigate this when enabled but it's still not perfect. [1] https://www.usenix.org/conference/atc19/presentation/gao § 3.3 Decompression | 21 Oct |
| CVE-2026-89598 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: fbdev: ssd1307fb: defer I2C transfers from damage callbacks The fbdev damage callbacks may run from fbcon while printk has disabled preemption. They currently update the display synchronously, which enters the sleeping I2C transfer path from atomic context. A complete report from an RK3566 system follows: [ 258.129004] watchdog: watchdog0: watchdog did not stop! [ 258.129067] BUG: scheduling while atomic: systemd/1/0x00000003 [ 258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.129215] Preemption disabled at: [ 258.129216] [<ffff80008012f96c>] vprintk_emit+0x11c/0x340 [ 258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G C 6.6.0-rc5-rockchip-rk356x #4 [ 258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT) [ 258.129243] Call trace: [ 258.129245] dump_backtrace+0xa0/0x128 [ 258.129252] show_stack+0x20/0x38 [ 258.129256] dump_stack_lvl+0x60/0xb0 [ 258.129265] dump_stack+0x18/0x28 [ 258.129269] __schedule_bug+0xa0/0xc8 [ 258.129274] __schedule+0x9ac/0xd30 [ 258.129279] schedule+0x60/0x100 [ 258.129282] schedule_timeout+0x194/0x338 [ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498 [ 258.129296] rk3x_i2c_xfer+0x20/0x60 [ 258.129300] __i2c_transfer+0x194/0x648 [ 258.129308] i2c_transfer+0x9c/0x130 [ 258.129313] i2c_transfer_buffer_flags+0x64/0x98 [ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb] [ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb] [ 258.129343] soft_cursor+0x13c/0x210 [ 258.129350] bit_cursor+0x2dc/0x550 [ 258.129354] fbcon_cursor+0xec/0x108 [ 258.129359] hide_cursor+0x44/0xc8 [ 258.129365] vt_console_print+0x398/0x3b0 [ 258.129370] console_flush_all.isra.0+0x17c/0x410 [ 258.129377] console_unlock+0x4c/0x100 [ 258.129382] vprintk_emit+0x1c8/0x340 [ 258.129386] vprintk_default+0x40/0x58 [ 258.129389] vprintk+0xb8/0xd0 [ 258.129392] _printk+0x68/0x98 [ 258.129398] watchdog_release+0x170/0x230 [ 258.129404] __fput+0xbc/0x288 [ 258.129409] __fput_sync+0x58/0x70 [ 258.129413] __arm64_sys_close+0x40/0x90 [ 258.129419] invoke_syscall+0x4c/0x118 [ 258.129426] el0_svc_common.constprop.0+0x48/0xf0 [ 258.129432] do_el0_svc+0x24/0x38 [ 258.129437] el0_svc+0x48/0x100 [ 258.129443] el0t_64_sync_handler+0xc0/0xc8 [ 258.129448] el0t_64_sync+0x190/0x198 [ 258.573087] ------------[ cut here ]------------ [ 258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count()) [ 258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871 preempt_count_sub+0x9c/0x148 [ 258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp ---truncated--- | 19 Oct |
9 of 9
Download these 9 as CSV · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.