[<prev] [next>] [day] [month] [year] [list]
Message-ID: <65fd6c60-4aee-42e0-ad18-e66c187d7a9e@oracle.com>
Date: Thu, 28 May 2026 11:00:49 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Various memory access violations in 7-Zip
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-115_GHSL-2026-122_7-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 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.
>
> [...]
>
> 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
> 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.
>
> [...]
>
> 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”
>
>
> 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 = 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”
>
>
> 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
> 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”
>
>
> 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@...hub.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-140_7-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 ReadStream_FALSE
> 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. 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”
>
>
> 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@...hub.com, please include a
> reference to GHSL-2026-140 in any communication regarding this issue.
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
