A critical denial-of-service flaw has been discovered in the RAR5 decompression module of 7-Zip, tracked as GHSL-2025-058 and assigned CVE-2025-53816.
In certain error-recovery scenarios, the decoder miscalculates buffer boundaries when filling corrupted data with zeroes, permitting writes beyond the allocated heap block.
The issue was responsibly reported by Jaroslav Lobačevski (JarLob) on April 24, 2025, acknowledged by the GitHub Security Lab on April 29, and remedied in the 7-Zip 25.00 release on July 5, 2025.
This vulnerability does not appear to enable arbitrary code execution, but the induced memory corruption can crash the extractor, leading to a denial of service.
Users are urged to update immediately to prevent exploitation of this heap buffer overflow in the RAR5 handler.
Discovery and Disclosure Timeline
The defect was first reported privately to the GitHub Security Lab on April 24, 2025. Within five days, the issue was acknowledged, and an investigation commenced.
Over the following weeks, the GHSL team performed an in-depth analysis and collaborated with the 7-Zip maintainers to devise a patch.
On July 5, 2025, version 25.00 of 7-Zip was released, sealing the overflow. JarLob’s coordinated disclosure adhered to best practices, allowing downstream distributions and integrators to prepare the update.
The concise timeline underscores the importance of swift vulnerability handling and transparent communication between security researchers and open-source projects.
Technical Breakdown of the RAR5 Handler Flaw
At the heart of the issue lies a miscalculation of the remaining bytes, rem, when recovering corrupted sections inside the RAR5 decoder’s sliding window.
In error-recovery mode, the code attempts to overwrite damaged data with zeroes via My_ZeroMemory. The flawed segment reads:
cppUInt64 rem = _lzEnd - lzSize;
const size_t ws = _winSize;
if (_window) {
if (rem >= ws) {
My_ZeroMemory(_window, ws);
_lzSize = ws;
_winPos = 0;
} else {
const size_t cur = ws - _winPos;
if (cur <= rem) {
rem -= cur;
My_ZeroMemory(_window + _winPos, cur);
_lzSize += _winPos;
_winPos = 0;
}
My_ZeroMemory(_window + _winPos, (size_t)rem);
_winPos += (size_t)rem;
}
}
Here, _lzEnd is computed from the attacker-controlled unpack size of the previous archive member, permitting rem to exceed the actual bounds of the heap buffer.
When 7-Zip is built with AddressSanitizer, a proof-of-concept rar-crash.rar5 archive triggers the following error:
text==2188082==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fc75fbcc844
WRITE of size 9469 at 0x7fc75fbcc844 thread T0
#1 0x5567b0167b0c in My_ZeroMemory(void*, unsigned long)
#2 0x5567b017c257 in NCompress::NRar5::CDecoder::Code(...)
This confirms that zero-writes spill past the allocated window buffer, leading to memory corruption and process termination.
Impact, Mitigation, and Fix
Although the vulnerability is unlikely to facilitate arbitrary code execution, the induced heap corruption reliably crashes the extraction process, constituting a denial of service.
Any user extracting a maliciously crafted RAR5 archive with a vulnerable 7-Zip release may experience application crashes or unexpected failures.
The GHSL team recommends immediate upgrading to 7-Zip version 25.00 or later, where boundary checks ensure that rem never exceeds the buffer’s length.
Distributors and downstream projects should integrate the patched release promptly.
Security-conscious environments may also consider enforcing stricter archive validation or sandboxing extraction operations to minimize potential disruption.
Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant updates