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