https://www.zerodayinitiative.com/advisories/ZDI-26-444/ advises: 7-Zip XZ Decompression Heap-based Buffer Overflow Remote Code Execution Vulnerability

July 15th, 2026 ZDI-26-444 ZDI-CAN-30169

CVE ID CVE-2026-14266

CVSS Score 7.0 AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Affected Vendors 7-Zip

Affected Products 7-Zip

Vulnerability Details

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the processing of XZ chunked data. Crafted XZ-compressed data can trigger an overflow of a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.

Additional Details

Fixed in 7-Zip 26.02

Disclosure Timeline

2026-06-05 - Vulnerability reported to vendor 2026-07-15 - Coordinated public release of advisory 2026-07-15 - Advisory Updated

Credit

Lunbun LLC (Landon Peng) -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of XZ chunked data. Crafted XZ-compressed data can trigger an overflow of a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of XZ chunked data. Crafted XZ-compressed data can trigger an overflow of a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.

7-Zip XZ Decompression Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the processing of XZ chunked data. Crafted XZ-compressed data can trigger an overflow of a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-30169.

7-Zip for Windows through 26.01 fails to preserve the Mark-of-the-Web when extracting a crafted RAR5 archive, because its guard that suppresses an archive-supplied Zone.Identifier stream matches the exact name 'Zone.Identifier' while a RAR5 STM record named ':Zone.Identifier:$DATA' is not matched and NTFS canonicalizes it to the same stream, overwriting the propagated Internet-zone marker with ZoneId=0. A second STM record named '::$DATA' overwrites the extracted file's default data stream, letting an attacker defeat SmartScreen/MotW warnings and spoof file content.

7-Zip is a file archiver with a high compression ratio. Versions 9.18 through 26.00 contain a heap out-of-bounds read in 7-Zip Ar handler BSD SYMDEF parser. A 4-byte heap out-of-bounds read exists in the Unix ar archive parser in 7-Zip. When parsing a BSD-style .SYMDEF symbol table, the ParseLibSymbols function reads a 32-bit namesSize field via Get32 at a position that can equal the buffer size, reading 4 bytes past the end of the heap allocation. This reads uninitialized heap data under the default allocator. Version 26.01 patches the issue.

7-Zip is a file archiver with a high compression ratio. Versions 9.21 through 26.00 contain an off-by-one out-of-bounds read vulnerability in the ParseDepedencyExpression function of the UEFI firmware image parser(CPP/7zip/Archive/UefiHandler.cpp). The function validates an attacker-controlled opcode byte using > instead of >= against the element count of the 10-entry kExpressionCommands static array, allowing an opcode value of 10 to read one pointer slot (8 bytes on x64) past the end of the array in .rodata. The out-of-bounds value is then dereferenced as a const char and passed through strlen and memcpy into the archive's Characts property, which may cause either a denial of service (access violation when the adjacent bytes do not form a valid readable pointer) or a minor information disclosure of an adjacent .rdata string literal into archive metadata. The vulnerability is reached automatically during IInArchive::Open() via the call path OpenFv/OpenCapsule → ParseVolume → ParseSections when processing a SECTIONDXEDEPEX (0x13) or SECTIONPEIDEPEX (0x1B) section whose first body byte is 0x0A, and the UEFI handler is enabled by default in stock 7z.dll with signature-based detection for both UEFIc and UEFIf formats. The outcome (crash vs. silent leak) is deterministic per build but linker-layout dependent, with no write primitive and no disclosure of heap data, secrets, or ASLR base addresses. Version 26.01 fixes the issue.

7-Zip is a file archiver with a high compression ratio. Versions 9.18 through 26.00 contain an uninitialized heap read in the SquashFS archive handler caused by a sparsely populated index array. In the SquashFS handler, blockToNode is allocated with capacity for every metadata block but populated only when an inode crosses a block boundary, so a crafted image with few inodes spanning many blocks leaves most slots holding raw heap contents (the underlying allocator does not zero-initialize POD storage). When OpenDir looks up an attacker-influenced blockIndex (derived from the RootInode superblock field), it reads two of these uninitialized slots and passes them as the left/right bounds of a binary search over nodesPos, which dereferences the midpoint without bounds checking; if the resulting value happens to match the search key, the returned index is used to read a full node struct from nodes whose fields feed further directory parsing, forming a chained OOB read primitive that is heap-layout-dependent and not reliably triggerable. The SquashFS handler is enabled by default in stock 7z.dll and the issue triggers during Open() with no interaction beyond opening the file; impact is denial of service from wild-pointer dereference and potential heap information disclosure, with no write primitive. Version 26.01 fixes the issue.

7-Zip is a file archiver with a high compression ratio. Versions 9.34 through 26.00 contain an off-by-one heap out-of-bounds read in the WIM (Windows Imaging) archive handler's security descriptor lookup. In CHandler::GetSecurity (CPP/7zip/Archive/Wim/WimHandler.cpp), the per-image SecurOffsets table holds numEntries + 1 cumulative offsets, but the check securityId >= SecurOffsets.Size() admits securityId == numEntries, and the function then reads SecurOffsets[securityId + 1], fetching one UInt32 past the end of the heap-allocated CRecordVector (which performs no bounds checking on operator[]). The securityId is attacker-controlled at offset +0xC of any directory entry in WIM metadata, and the handler is registered for .wim, .swm, .esd, and .ppkg and enabled by default in stock 7z.dll; the OOB triggers zero-click in the GUI because 7zFM.exe's ListView calls GetRawProp(kpidNtSecure) for every item during listing (ASan-confirmed), and is also reachable via CLI listing with 7zz l -slt. Impact is limited to denial of service under hardened allocators and minor information disclosure, since the OOB value is only consumed arithmetically as a length and is not surfaced to the attacker; there is no write primitive.

7-Zip is a file archiver with a high compression ratio. Versions 9.11 through 26.00 contain a heap out-of-bounds read of up to 3 bytes in the UDF disc image handler's File Identifier Descriptor parser. In CFileId::Parse (CPP/7zip/Archive/Udf/UdfIn.cpp), after validating size < 38 + idLen + impLen and advancing processed to 38 + impLen + idLen, the alignment-padding loop reads p[processed] while incrementing up to 3 times to reach a 4-byte boundary, and the processed <= size bounds check only runs after the loop. When (38 + impLen + idLen) % 4 != 0 and 38 + impLen + idLen == size, the loop reads 1 to 3 bytes past the end of the exact-size heap buffer allocated via buf.Alloc((sizet)item.Size). The UDF handler is registered for .iso and .udf files and auto-detected by signature, and the OOB read triggers during Open() when listing or extracting a crafted UDF image. Impact is limited to information disclosure (a 1-bit oracle per OOB byte via open/fail behavior) and denial of service (crash under hardened allocators); there is no write primitive. Version 26.01 fixes the issue.

7-Zip is a file archiver with a high compression ratio. Versions 9.21 through 26.00 contain an An uninitialized memory disclosure vulnerability in the UEFI capsule (.scap) parser in 7-Zip. The OpenCapsule function allocates a heap buffer of attacker-declared CapsuleImageSize (up to 1 GiB) without zero-initialization, then reads the file contents into it with ReadStreamFALSE whose return value is silently discarded. If the file is truncated, the unread tail of the buffer retains uninitialized heap memory, which is then exposed as extracted file content via GetStream. Version 26.0.1 fixes the issue.

7-Zip is a file archiver with a high compression ratio. Versions 26.00 and prior contain a heap buffer overflow vulnerability caused by an under-allocation in the NTFS compressed stream buffer (GetCuSize shift UB), potentially allowing attackers to cause arbitrary code execution or application crashes. CInStream::GetCuSize() in the NTFS handler computes the compression-unit buffer size as (UInt32)1 << (BlockSizeLog + CompressionUnit), and a crafted image with ClusterSizeLog >= 28 and CompressionUnit == 4 drives the exponent to 32, which is undefined behavior and collapses on x86/x64 so inBuf is allocated as 1 byte. ReadStreamFALSE then writes up to 256 MB of attacker-controlled data into that 1-byte buffer in 64 KB iterations, and because the CInStream object sits only 304 bytes after inBuf, its vtable pointer is overwritten and the next dispatched call achieves a vtable hijack. On 32-bit builds the overflow is unconditionally reached; on 64-bit it requires the parallel 8 GB outBuf allocation to succeed, otherwise failing closed to denial of service. The NTFS handler is enabled by default in stock 7z.dll and, via signature-based fallback matching "NTFS " at offset 3, will open a crafted image regardless of file extension during extraction or testing. Version 26.01 fixes the issue.

7-Zip is a file archiver with a high compression ratio. Versions 9.34 through 26.00 contain a heap memory disclosure via SquashFS fragment offset integer overflow on 32-bit builds. 32-bit integer overflow in the SquashFS ReadBlock function allows an attacker-controlled node.Offset value to bypass the fragment bounds check, causing memcpy to read heap memory preceding the cache buffer into the extracted file. The vulnerability is exploitable only on 32-bit builds of 7-Zip where sizet is 32 bits, allowing the addition offsetInBlock + blockSize to wrap modulo 2³². On 64-bit builds the addition is promoted to 64 bits and the check correctly rejects the input. Version 26.01 patches the issue.

GitHub's Security Lab has published two advisories about memory access violations in 7-Zip, which were fixed in 7-Zip 26.01.

I've omittted code analysis & proof-of-concept code chunks in the below, see the provided URL's to view those with much better formatting than plain-text email allows.

https://securitylab.github.com/advisories/GHSL-2026-115GHSL-2026-1227-zip/ says: May 22, 2026 GHSL-2026-115–GHSL-2026-122: Various memory access violations in 7-Zip

Author: Jaroslav Lobačevski

Coordinated Disclosure Timeline

2026-04-21: The report was delivered through sourceforge private issues. 2026-04-27: v26.01 with fixes was released.

Summary ------- The 7-Zip project, version 26.00, contains various memory access violations, out-of-bounds (OOB) read issues, uninitialized memory vulnerabilities, integer overflow flaws in various archive formats (e.g., 7z, SquashFS, UDF, UEFI, WIM, and Ar), and path traversal in sample app, which could potentially lead to compromising system integrity or accessing sensitive data.

Project: 7-Zip Tested Version: v26.00

Issue 1: SquashFS Fragment Offset Overflow (GHSL-2026-116) ==========================================================

Heap memory disclosure via SquashFS fragment offset integer overflow on 32-bit builds.

32-bit integer overflow in the SquashFS ReadBlock function allows an attacker-controlled node.Offset value to bypass the fragment bounds check, causing memcpy to read heap memory preceding the cache buffer into the extracted file. The vulnerability is exploitable only on 32-bit builds of 7-Zip where sizet is 32 bits, allowing the addition offsetInBlock + blockSize to wrap modulo 2³². On 64-bit builds the addition is promoted to 64 bits and the check correctly rejects the input.

[...]

Impact ------ This issue may lead to information disclosure (heap memory preceding cachedBlock written into extracted file) on 32-bit builds.

- The SquashFS handler is registered for .squashfs and .sfs files and is enabled in stock 7z.dll. - 32-bit builds of 7-Zip are shipped on the official 7-zip.org downloads page. - The vulnerability triggers during extraction — the attacker recovers heap contents by reading the extracted file. - The attacker controls the read offset via node.Offset and the read size via FileSize (up to h.BlockSize, max 8 MiB). - Heap memory preceding cachedBlock (up to BlockSize bytes) is written into the extracted file — an in-band information disclosure primitive. - On 64-bit builds, the bug is latent (bounds check is correct due to 64-bit promotion).

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — 6.5 (Medium)

Scored for 32-bit builds where the disclosure is real.

Affected versions: The SquashFS fragment ReadBlock with offsetInBlock has been present since 7-Zip 9.18. All 32-bit builds from 9.18 through 26.00 are affected. 64-bit builds are not affected.

CWEs ----- CWE-190: “Integer Overflow or Wraparound” CWE-125: “Out-of-bounds Read”

Issue 2: UEFI Capsule uninitialized heap memory disclosure (GHSL-2026-117) ==========================================================================

Uninitialized heap memory disclosure in 7-Zip UEFI capsule handler via truncated archive.

An uninitialized memory disclosure vulnerability exists in the UEFI capsule (.scap) parser in 7-Zip. The OpenCapsule function allocates a heap buffer of attacker-declared CapsuleImageSize (up to 1 GiB) without zero-initialization, then reads the file contents into it with ReadStreamFALSE whose return value is silently discarded. If the file is truncated, the unread tail of the buffer retains uninitialized heap memory, which is then exposed as extracted file content via GetStream.

[...]

Impact ------- This issue may lead to information disclosure (uninitialized heap memory written to extracted files).

- The UEFI capsule handler is registered for .scap files with signature-based detection (NArcInfoFlags::kFindSignature) and is enabled in stock 7z.dll. - The vulnerability triggers on extraction (GetStream is called when the user extracts a file from the archive). - Usual operation — the user just opens and extracts a malicious .scap file. - Up to ~1 GiB of uninitialized heap memory is written to disk as extracted file content. In a long-running 7-Zip GUI session (warm heap), this can include fragments of previously processed archives, file paths, decompressed content, or passwords from encrypted archive sessions. - On Windows, even a cold (freshly launched) process leaks non-zero heap metadata. On Linux the cold leak contains zeros, the “warm” process leaks the non-zero heap. The GUI is the primary concern because it is long-running.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — 6.5 (Medium)

Affected versions: The unchecked ReadStreamFALSE has been present since 7-Zip 9.21. All versions from 9.21 through 26.00 are affected.

CWEs ---- CWE-908: “Use of Uninitialized Resource”

Issue 3: UDF Field OOB Read (GHSL-2026-118) =========================================== Up-to-3-byte heap OOB read in UDF File Identifier padding loop.

The UDF disc image parser’s CFileId::Parse function reads up to 3 bytes past the end of the heap-allocated directory buffer in the alignment-padding scan loop. The bounds check processed <= size is performed after the OOB reads, not before.

[...]

Impact ------ This issue may lead to information disclosure (1-bit oracle per OOB byte via open/fail behavior).

- The UDF handler is registered for .iso, .udf and auto-detected by signature. - Triggers during Open() — listing or extracting a crafted UDF image. - OOB read of up to 3 bytes per FID parse.

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N — 3.1 (Low)

Affected versions: The UDF handler has been present since 7-Zip 9.11. All versions through 26.00 are affected.

CWEs ----- CWE-125: “Out-of-bounds Read”

Issue 4: WIM SecurityId OOB read (GHSL-2026-119) ================================================ Off-by-one heap out-of-bounds read in 7-Zip WIM security descriptor handler.

An off-by-one heap out-of-bounds read exists in the WIM (Windows Imaging) archive handler in 7-Zip. The CHandler::GetSecurity function validates a securityId against SecurOffsets.Size() but then accesses SecurOffsets[securityId + 1], reading 4 bytes past the end of the heap allocation when securityId equals the maximum allowed value. The OOB is triggered on viewing (double-click or File -> Open) a crafted WIM in the 7-Zip File Manager GUI.

[...]

Impact ------ This issue may lead to limited information disclosure (OOB bytes used arithmetically but not surfaced to attacker).

- The WIM handler is registered for .wim, .swm, .esd, .ppkg files and is enabled in stock 7z.dll. - GetSecurity is called when any frontend queries kpidNtSecure via IArchiveGetRawProps::GetRawProp. - The file manager’s ListView calls GetRawProp(kpidNtSecure) for every item during listing — the OOB triggers immediately upon opening the WIM, with no extraction or user interaction. - CLI: The console tool triggers the OOB when listing with technical info (7zz l -slt). - The attacker controls securityId via the SecurityId field at offset +0xC of any directory entry in the WIM metadata. - The OOB value is used arithmetically (len = OOBvalue - offs) to compute a metadata buffer slice length. If the garbage len fails the subsequent bounds check, the function returns SOK with no data.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L — 3.5 (Low)

Affected versions: The WIM security descriptor support (GetSecurity with SecurOffsets) was introduced in 7-Zip 9.34. The off-by-one has been present since introduction. All versions from 9.34 through 26.00 are affected.

CWEs ---- CWE-125: “Out-of-bounds Read”

Issue 5: SquashFS BlockToNode uninitialized heap read (GHSL-2026-120) =====================================================================

Uninitialized heap read via sparse blockToNode index in SquashFS handler.

The SquashFS handler’s OpenDir function indexes the blockToNode array using attacker-controlled blockIndex values. The array is allocated with ClearAndReserve(GetNumBlocks() + 1) but only partially populated during inode parsing — when few inodes span many metadata blocks, most slots remain uninitialized. Reading these uninitialized UInt32 values provides attacker-influenced bounds to FindInSorted, which then performs an unbounded heap read via nodesPos[mid]. If the OOB-read value coincidentally matches unpackPos, the returned nodeIndex chains into a wild-pointer read of nodes[nodeIndex] — though this amplification is heap-layout-dependent and not reliably triggerable.

Impact ------ This issue may lead to information disclosure (heap content leakage via chained OOB reads) and denial of service (crash from wild-pointer dereference). The SquashFS handler is enabled in stock 7z.dll and triggers during Open() before any user interaction beyond opening the file.

- The attacker controls RootInode in the superblock and the metadata block layout. - Uninitialized heap values feed into indexed reads, creating an attacker-influenced OOB read chain. - No write primitive.

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L — 4.2 (Medium)

AC:H because exploiting the uninitialized values for controlled reads requires heap layout manipulation.

Affected versions: The blockToNode optimization has been present since 7-Zip 9.18. All versions through 26.00 are affected.

CWEs ---- CWE-908: “Use of Uninitialized Resource” CWE-125: “Out-of-bounds Read”

Issue 6: UEFI DEPEX OOB Read (GHSL-2026-121) ============================================

Off-by-one out-of-bounds read in 7-Zip UEFI dependency expression parser.

An off-by-one out-of-bounds read exists in the UEFI firmware image parser in 7-Zip. The ParseDepedencyExpression function uses > instead of >= when validating an attacker-controlled opcode byte against the bounds of a static array of const char pointers. When command == 10, the function reads one pointer past the end of the 10-element kExpressionCommands array, then dereferences that pointer as a C string, causing either a crash or a leak of adjacent .rodata content into archive metadata.

Impact ------ This issue may lead to denial of service (crash from dereferencing an invalid pointer) or minor information disclosure (adjacent .rdata string leaked into archive metadata).

- Static array OOB read: kExpressionCommands[10] reads 8 bytes (one pointer slot) past the end of a 10-element static .rdata array. Because adjacent .rdata is always readable (same PE section), this does not typically crash. On the tested build, the adjacent bytes form a valid pointer to another string literal, so strlen + memcpy succeed silently. - No meaningful information disclosure: The content at the dereferenced OOB pointer is a static string from the binary’s own .rdata — identical to what anyone can extract with a hex editor. No user secrets, no heap data, no ASLR base address is leaked. - Linker-dependent crash: If a different build places non-pointer data adjacent to kExpressionCommands, the strlen dereference would fault with ACCESSVIOLATION (DoS). This is linker-layout dependent, not deterministic across builds.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L — 3.5 (Low)

Affected versions: The off-by-one has been present since 7-Zip 9.21, the first version to include the UEFI handler. All versions through 26.00 are affected.

CWEs ---- CWE-125: “Out-of-bounds Read”

Issue 7: Ar SYMDEF OOB Read (GHSL-2026-122) =========================================== Heap out-of-bounds read in 7-Zip Ar handler BSD SYMDEF parser.

A 4-byte heap out-of-bounds read exists in the Unix ar archive parser in 7-Zip. When parsing a BSD-style .SYMDEF symbol table, the ParseLibSymbols function reads a 32-bit namesSize field via Get32 at a position that can equal the buffer size, reading 4 bytes past the end of the heap allocation. This reads uninitialized heap data under the default allocator.

Impact ------ This issue may lead to limited information disclosure (OOB bytes used in bounds check but not surfaced to output).

- The Ar handler is registered for .a, .ar, .lib, and .deb file extensions. The handler IS enabled in stock 7z.dll. - ParseLibSymbols is called from Open at line 627, triggered whenever the first or second archive member is named .SYMDEF or .SYMDEF SORTED. - The vulnerability triggers during IInArchive::Open(), before any extraction. - Limited information disclosure: The OOB bytes are stored in namesSize (local variable) but are only used in the subsequent bounds check at line 478, which always fails (causing continue). The leaked bytes do not flow into any output stream visible to the attacker.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L — 3.5 (Low)

Affected versions: The SYMDEF parsing was introduced in 7-Zip 9.34. The off-by-4 OOB has been present in all versions from 9.34 through 26.00.

CWEs ---- CWE-125: “Out-of-bounds Read”

Issue 8: Missing path validation in extraction loop (GHSL-2026-115) =================================================================== Path traversal in 7zDec SDK sample extractor allows arbitrary file write.

The 7zDec standalone LZMA SDK sample extractor (C/Util/7z/7zMain.c) does not validate archive entry paths for directory traversal sequences (..), absolute paths, or other unsafe path components when extracting in x (full paths) mode. An attacker-controlled 7z archive can write files to arbitrary locations on the filesystem, enabling code execution via overwriting startup scripts, SSH keys, or system configuration files.

Impact ------ It is a sample extractor which may be used as example. This issue may lead to arbitrary file write and remote code execution (overwrite shell rc files, cron jobs, SSH keys). 7zDec is built from the LZMA SDK and is a working binary that users invoke on untrusted archives. The attack requires only delivering a crafted 7z archive — no special privileges, no race conditions.

CWEs ----- CWE-22: “Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)”

CVE --- GHSL-2026-115: Sample app GHSL-2026-116: CVE-2026-48092 GHSL-2026-117: CVE-2026-48101 GHSL-2026-118: CVE-2026-48102 GHSL-2026-119: CVE-2026-48103 GHSL-2026-120: CVE-2026-48104 GHSL-2026-121: CVE-2026-48111 GHSL-2026-122: CVE-2026-48112

Credit ------ These issues were discovered and reported by GHSL team member @JarLob (Jaroslav Lobačevski).

Contact ------- You can contact the GHSL team at securitylab () github com, please include a reference to GHSL-2026-115, GHSL-2026-116, GHSL-2026-117, GHSL-2026-118, GHSL-2026-119, GHSL-2026-120, GHSL-2026-121, or GHSL-2026-122 in any communication regarding these issues. https://securitylab.github.com/advisories/GHSL-2026-1407-Zip/ says: May 22, 2026 GHSL-2026-140: Heap Buffer Write Overflow in 7-Zip

Author: Jaroslav Lobačevski

Coordinated Disclosure Timeline

2026-04-24: The report was delivered as a sourceforge private issue. 2026-04-27: v26.01 with a fix was released.

Summary ------- A heap buffer overflow vulnerability (GHSL-2026-140) exists in 7-Zip version 26.00, caused by an under-allocation in the NTFS compressed stream buffer (GetCuSize shift UB), potentially allowing attackers to exploit this issue for arbitrary code execution or application crashes.

Project: 7-Zip Tested Version: v26.00

Details ------- Heap buffer overflow via NTFS compressed stream buffer under-allocation (GetCuSize shift UB) (GHSL-2026-140)

A heap buffer overflow vulnerability exists in the NTFS archive handler in 7-Zip that can lead to code execution via vtable hijack. The CInStream::GetCuSize() function computes the NTFS compression-unit buffer size using a 32-bit shift (UInt32)1 << (BlockSizeLog + CompressionUnit). When an attacker-crafted NTFS image sets ClusterSizeLog >= 28 (accepted by the parser) and a compressed data attribute with CompressionUnit == 4, the shift exponent reaches 32 — undefined behavior in C++. On both x86 and x64, the UB causes inBuf to be allocated as 1 byte. The subsequent ReadStreamFALSE writes 256 MB of attacker-controlled data into this 1-byte buffer.

[...]

Impact

Heap buffer overflow leading to vtable hijack (potential code execution) — 256 MB written into a 1-byte heap buffer. ReadStreamFALSE calls stream->Read() in a loop (64 KB per iteration via kBlockSize). Debugger analysis on a release /O1 build (identical codegen to official binary) shows the stream object (CInStream) is allocated only 304 bytes (0x130) after inBuf on the heap. The first Read() iteration writes 64 KB of attacker-controlled data starting at inBuf, overwriting the stream object’s vtable pointer after just 304 bytes. The second Read() iteration dispatches through the corrupted vtable — a classic vtable hijack. The attacker controls the written data (NTFS cluster content from the crafted image), so they control the overwritten vtable pointer.

- Both x86 and x64 builds are affected. On x64, the overflow is reached on any system where the 8 GB outBuf allocation succeeds (common on modern systems with >= 16 GB RAM). - On Windows, ReadFile fails if it detects an unmapped or guard page in the destination range before copying the controlled bytes. Attackers may need Heap Feng Shui to place inBuf so the overwrite reaches adjacent objects without immediately faulting. - The NTFS handler is enabled in stock 7z.dll and is registered for .ntfs and .img extensions. However, 7-Zip uses signature-based fallback detection: when the format matching the file extension fails to open, all remaining handlers are tried in signature-priority order. Because the NTFS handler matches on the "NTFS " signature at byte offset 3 (REGISTERARCI in NtfsHandler.cpp:2889), a crafted NTFS image with any file extension — including .7z, .zip, .rar, or no extension at all — will be opened by the NTFS handler after the extension-matched handler rejects it. This means the attack surface is not limited to files with NTFS-associated extensions. - Triggers during extraction/testing of a compressed file from the crafted image. - No user interaction beyond opening the crafted image.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — 8.8 (High)

Affected versions: The GetCuSize() computation has been present since NTFS compressed stream support was introduced. All versions through 26.00 are affected.

CWEs ---- CWE-787: “Out-of-bounds Write” CWE-190: “Integer Overflow or Wraparound”

CVE --- CVE-2026-48095

Credit ------ This issue was discovered and reported by GHSL team member @JarLob (Jaroslav Lobačevski).

Contact ------- You can contact the GHSL team at securitylab () github com, please include a reference to GHSL-2026-140 in any communication regarding this issue. -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

A new 7-Zip vulnerability, CVE-2026-48095, affects 7-Zip 26.00 and earlier and is fixed in 26.01. The attack surface: The malicious file does not necessarily need to look like an NTFS image. A crafted NTFS disk image can be renamed as something like invoice.pdf or report.zip, and when opened through 7-Zip, the NTFS handler can still be reached through content-based detection. Detected first by GitHub Security Lab

A heap buffer overflow vulnerability (GHSL-2026-140) exists in 7-Zip version 26.00, caused by an under-allocation in the NTFS compressed stream buffer (GetCuSize shift UB), potentially allowing attackers to exploit this issue for arbitrary code execution.

The 7-Zip project, version 26.00, contains various memory access violations, out-of-bounds (OOB) read issues, uninitialized memory vulnerabilities, integer overflow flaws in various archive formats (e.g., 7z, SquashFS, UDF, UEFI, WIM, and Ar), and path traversal in sample app, which could potentially lead to compromising system integrity or accessing sensitive data.

The 7-Zip project, version 26.00, contains various memory access violations, out-of-bounds (OOB) read issues, uninitialized memory vulnerabilities, integer overflow flaws in various archive formats (e.g., 7z, SquashFS, UDF, UEFI, WIM, and Ar), and path traversal in sample app, which could potentially lead to compromising system integrity or accessing sensitive data.

7-Zip ZIP File Parsing Directory Traversal Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation.

The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account. Was ZDI-CAN-26743.

7-Zip ZIP File Parsing Directory Traversal Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation.

The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account. Was ZDI-CAN-26753.

Hi,

It's another case where I was hoping someone else would reply, but since no one did, I do.

On Sun, Oct 12, 2025 at 03:59:27PM -0700, lunbun wrote: Does anyone know how might I get the CVSS score of this vulnerability (CVE-2025-55188) increased? CVSS scores don't exist on their own - they're computed from CVSS vectors. So you need to suggest and justify a certain CVSS vector. Please refer to CVSS specification documents and examples from FIRST:

https://www.first.org/cvss/v3-1/ I recently saw an advisory for CVE-2025-11001, a very similar arbitrary file write in 7-Zip due to symbolic links (https://www.zerodayinitiative.com/advisories/ZDI-25-949/). I actually care more about bringing vulnerability detail in here than about CVSS scores, so let me quote the above as if you did: October 7th, 2025 7-Zip ZIP File Parsing Directory Traversal Remote Code Execution Vulnerability ZDI-25-949 ZDI-CAN-26753 CVE ID CVE-2025-11001 CVSS SCORE 7.0, AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H AFFECTED VENDORS 7-Zip AFFECTED PRODUCTS 7-Zip VULNERABILITY DETAILS

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation.

The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account. ADDITIONAL DETAILS

Fixed in 7-Zip 25.00

DISCLOSURE TIMELINE

2025-05-02 - Vulnerability reported to vendor 2025-10-07 - Coordinated public release of advisory 2025-10-07 - Advisory Updated

CREDIT Ryota Shiga (GMO Flatt Security Inc.) with takumi-san.ai

However, CVE-2025-11001 is clearly different from CVE-2025-55188, as the advisory states that CVE-2025-11001 was patched in 25.00. My proof-of-concept symbolic link attack for CVE-2025-55188 works in version 25.00.

I am concerned that due to the low CVSS score of CVE-2025-55188, most users do not realize that 25.00 is still vulnerable to symbolic link attacks.

I've already tried contacting MITRE 8 times to update the description and CVSS score. I've only received one response, and that was that not enough public information was available.

I then published a proof-of-concept and vulnerability explanation (https://github.com/lunbun/CVE-2025-55188 and https://lunbun.dev/blog/cve-2025-55188/), but MITRE is still unresponsive to my update requests.

I suspect that MITRE is just busy with a huge backlog of CVE requests, but I am not sure what to do here. If anyone could offer any advice, I'd greatly appreciate it. Yes, I suspect they're just busy.

There isn't any one authoritative source for CVSS scores. In fact, there are often different/conflicting CVSS scores (and their corresponding different CVSS vectors) coming from different sources.

In this case, for CVE-2025-55188 the only score published by NVD is in fact coming from MITRE, and it is:

3.6, CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N

As to CVE-2025-11001, it is "reserved by a CNA" and not yet published, so the higher score of 7.0 (which I've confirmed does match the vector) remains ZDI's suggestion. You can also make your suggestion e.g. in this thread and in your blog - and it'd have similar (lack of) effect.

I hope this helps.

Alexander

Hi all,

Does anyone know how might I get the CVSS score of this vulnerability (CVE-2025-55188) increased?

I recently saw an advisory for CVE-2025-11001, a very similar arbitrary file write in 7-Zip due to symbolic links (https://www.zerodayinitiative.com/advisories/ZDI-25-949/).

However, CVE-2025-11001 is clearly different from CVE-2025-55188, as the advisory states that CVE-2025-11001 was patched in 25.00. My proof-of-concept symbolic link attack for CVE-2025-55188 works in version 25.00.

I am concerned that due to the low CVSS score of CVE-2025-55188, most users do not realize that 25.00 is still vulnerable to symbolic link attacks.

I've already tried contacting MITRE 8 times to update the description and CVSS score. I've only received one response, and that was that not enough public information was available.

I then published a proof-of-concept and vulnerability explanation (https://github.com/lunbun/CVE-2025-55188 and https://lunbun.dev/blog/cve-2025-55188/), but MITRE is still unresponsive to my update requests.

I suspect that MITRE is just busy with a huge backlog of CVE requests, but I am not sure what to do here. If anyone could offer any advice, I'd greatly appreciate it.

Thanks, lunbun

On Wed, Aug 13, 2025 at 3:00 AM Jens-Wolfhard Schicke-Uffmann < drahflow () gmx de> wrote: On Sun, Aug 10, 2025 at 05:04:24PM -0700, lunbun wrote: If a symlink targets a nonexistent directory, the write will fail. 7-Zip by default will print an error message, like: ERROR: Cannot open output file : errno=2 : No such file or directory : ./ maliciouslink/file.txt

This applies similarly to other filesystem errors, like insufficient permissions or unwritable directory.

However, 7-Zip by default continues with extraction regardless of the error, which is why an attacker can use this "shotgun" strategy. These errors, though, would hopefully help notify the user that something suspicious is happening. Never forget terminal escape codes. At least the 7-Zip my debian has dumps the raw filename in those error messages. This allows an attacker to clean the specific error lines after they have been output (with another, later filename containing the required escapes).

With some fantasy, it might also be possible to massage the overwrite prompts (they're also unescaped) into suggesting to choose "(A)lways", e.g. by good cursor movement and setting a scroll region far above for the real prompt.

Regards, Drahflow

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account.

On Sun, Aug 10, 2025 at 05:04:24PM -0700, lunbun wrote: If a symlink targets a nonexistent directory, the write will fail. 7-Zip by default will print an error message, like: ERROR: Cannot open output file : errno=2 : No such file or directory : ./ maliciouslink/file.txt

This applies similarly to other filesystem errors, like insufficient permissions or unwritable directory.

However, 7-Zip by default continues with extraction regardless of the error, which is why an attacker can use this "shotgun" strategy. These errors, though, would hopefully help notify the user that something suspicious is happening. Never forget terminal escape codes. At least the 7-Zip my debian has dumps the raw filename in those error messages. This allows an attacker to clean the specific error lines after they have been output (with another, later filename containing the required escapes).

With some fantasy, it might also be possible to massage the overwrite prompts (they're also unescaped) into suggesting to choose "(A)lways", e.g. by good cursor movement and setting a scroll region far above for the real prompt.

Regards, Drahflow

This at least prevents this from being a "silent" attack in all but the most targeted scenarios---and in those cases, the attacker probably already has another way in. I disagree that users are only at risk in the "most targeted scenarios." I do agree that these error messages, in most cases, prevent a total brute force. However, I believe that an attacker may reasonably guess that a user will extract either one or two directories deep into their home directory (e.g. ~/extract or ~/Downloads/extract) and be correct a decent amount of the time.

I do not believe the overwrite Y/n prompts can entirely mitigate this either. I looked at three Linux distros (Ubuntu Desktop, Debian, and Rocky Linux), and found at least one potential target file for each of these distros under the user's home directory that both leads directly to RCE and does not exist by default. If the link cannot be overwritten (another entry in the fake archive with the same name?), then there are immediate indications pointing to everything the attacker planted. Adding another entry with the same name could be used to overwrite the link, but 7-Zip will display the overwrite Y/n prompt.

On Sun, Aug 10, 2025 at 6:16 PM Jacob Bachmeyer <jcb62281 () gmail com> wrote: On 8/10/25 19:04, lunbun wrote: What does 7-Zip do if the symlink implies a nonexistent directory? (Example: attack targeting ~/.ssh/authorizedkeys is unpacked in ~/Downloads/foo/bar and unpacks a symlink to /proc/self/cwd/../../.ssh which maps to ~/Downloads/.ssh which probably does not exist.) If a symlink targets a nonexistent directory, the write will fail. 7-Zip by default will print an error message, like: ERROR: Cannot open output file : errno=2 : No such file or directory : ./maliciouslink/file.txt

This applies similarly to other filesystem errors, like insufficient permissions or unwritable directory.

However, 7-Zip by default continues with extraction regardless of the error, which is why an attacker can use this "shotgun" strategy. These errors, though, would hopefully help notify the user that something suspicious is happening. This at least prevents this from being a "silent" attack in all but the most targeted scenarios---and in those cases, the attacker probably already has another way in. [...] Can the malicious link be silently replaced or does extracting a malicious archive leave links to every directory that the attack hit? (That could at least make cleaning out the attack relatively straightforward.) I could be wrong, but I don't think there is any way for an attacker to silently remove or replace a malicious link. If the link cannot be overwritten (another entry in the fake archive with the same name?), then there are immediate indications pointing to everything the attacker planted.

Thank you for answering all of my questions. I don't know what the general policy is for releasing exploit PoCs after a patch is released. If it is okay, I can post one on this thread (publicly) so you can play around with it. At the original announcement, you had basically released a PoC, there would be only a matter of programming to generate malicious fake archives.

-- Jacob

On 2025-08-09 22:55:14 -0700, lunbun wrote: If, say, the archive is extracted to /tmp and the CWD is /tmp, then yes, the best an attacker can do is guess the user's login name. There are other issues with /tmp. If I understand correctly, the attacker could create /tmp/config.guess and /tmp/install-sh executable files. Then if the user compiles a libtool-based library under a subdirectory of /tmp, one of these files could be executed:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21951

And what about the /run/user/1000 directory? (In Debian, the UID of the main user always seems to be 1000.)

-- Vincent Lefèvre <vincent () vinc17 net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

On 8/10/25 19:04, lunbun wrote: What does 7-Zip do if the symlink implies a nonexistent directory? (Example:  attack targeting ~/.ssh/authorizedkeys is unpacked in ~/Downloads/foo/bar and unpacks a symlink to /proc/self/cwd/../../.ssh which maps to ~/Downloads/.ssh which probably does not exist.)

[...]

Can the malicious link be silently replaced or does extracting a malicious archive leave links to every directory that the attack hit? (That could at least make cleaning out the attack relatively straightforward.)

Thank you for answering all of my questions.

-- Jacob