CVE-2026-48095: 7-Zip Heap Buffer Overflow Can Lead to Code Execution

CVE-2026-48095 in 7-Zip has raised fresh concerns around malicious archive handling and user-driven exploitation. According to GitHub Security Lab, the flaw is a heap buffer write overflow in 7-Zip’s NTFS archive handler that affects version 26.00 and can potentially lead to arbitrary code execution or application crashes. The issue was fixed in 7-Zip 26.01, released on April 27, 2026.

The bug is especially dangerous because the malformed file does not need to use a dedicated NTFS file extension to reach the vulnerable handler. Public reporting says 7-Zip’s signature-based fallback logic can route a crafted file with extensions such as .7z, .zip, or .rar into the NTFS parser after other handlers fail, broadening the practical attack surface for phishing and social-engineering delivery.

For defenders, the most important details for CVE-2026-48095 are the affected version, the archive-parsing trigger, and the existence of public exploit material. GitHub Security Lab says researcher Jaroslav Lobačevski privately reported the issue on April 24, 2026, while later public write-ups confirmed that a working Python generator was released alongside the advisory.

CVE-2026-48095 analysis

At the technical level, the flaw stems from an under-allocation bug in the NTFS compressed stream buffer, inside CInStream::GetCuSize(). GitHub Security Lab explains that a crafted NTFS image can force the shift expression used for buffer sizing to hit an exponent of 32, which triggers undefined behavior in C++ and leaves _inBuf allocated as just 1 byte. The next read operation then writes attacker-controlled data into that tiny buffer, creating a classic heap overflow condition.

That overflow becomes exploitable because the adjacent heap layout allows the attacker to corrupt the stream object’s vtable pointer. Public analysis says the first read can overwrite the vtable after only a few hundred bytes, while the second read dispatches execution through the corrupted pointer, making code execution feasible in favorable conditions. Security Online and Cyber Press both describe this as a path to arbitrary code execution, while also noting that lower-memory systems may see denial-of-service outcomes instead.

The public CVE-2026-48095 PoC further raises the risk profile. Security Online says the researcher released gen_ntfs_sparse.py, a Python script that generates a sparse NTFS image designed to trigger the flaw. In practice, the CVE-2026-48095 payload is a specially crafted archive image rather than a dropped executable, which fits common social-engineering scenarios where a victim is lured into opening what appears to be a harmless compressed file.

From an operational perspective, CVE-2026-48095 affects systems where users open untrusted archive files with vulnerable 7-Zip builds. The coordinated advisory specifically tested 26.00, while later reporting notes that the affected sizing logic predates that release, suggesting the bug may have existed longer than the tested version alone.

Explore Detections

CVE-2026-48095 Mitigation

The primary response is to upgrade immediately to 7-Zip 26.01 or later. GitHub Security Lab’s disclosure timeline shows that the fix shipped on April 27, 2026, and 7-Zip’s official history confirms that version 26.01 was released on that date with bug fixes.

For practical CVE-2026-48095 detection, organizations should identify endpoints running 7-Zip 26.00, review environments where users frequently unpack externally sourced archives, and prioritize systems used for email triage, downloads, malware analysis, or administrative handling of compressed files. Because the exploitation path is file-driven, the most useful first step is asset and version validation rather than network hunting.

There are no vendor-published CVE-2026-48095 IOCs in the cited materials, so teams trying to detect CVE-2026-48095 should focus on suspicious archive-opening activity, crashes involving 7-Zip around NTFS-like content, and user workflows where disguised archive extensions could reach the vulnerable handler. In the absence of stronger telemetry, patching and user caution remain the most reliable defenses.