CVE-2026-4424: 
Rocky Linux vulnerability analysis and mitigation

CVE-2026-4424 is a heap out-of-bounds read vulnerability in libarchive's RAR archive processing logic, enabling remote information disclosure without authentication or user interaction. The flaw stems from improper validation of the LZSS sliding window size after transitions between PPMd and LZSS compression methods within RAR3 archives. It affects libarchive broadly, with downstream impact confirmed in Red Hat Enterprise Linux (6–10), Red Hat OpenShift Container Platform (4.x), IBM MQ Operator, IBM Guardium Data Protection, IBM App Connect Enterprise, and other products. Disclosed on March 19, 2026, it carries a CVSS v3.1 base score of 7.5 (High) (Red Hat CVE, Red Hat Bugzilla).

The vulnerability is classified as CWE-125 (Out-of-bounds Read) and results from a chain of five interrelated bugs in archive_read_support_format_rar.c. When a PPMd-compressed block follows an LZSS block in a RAR3 archive, parse_codes() updates dictionary_size to up to 1 MB but does not reallocate the LZSS sliding window, which may have been allocated as small as 8 bytes for a prior block. The allocation guard in parse_codes() only checks whether dictionary_size is non-zero and the window pointer is non-NULL — not whether the existing window is large enough — so the undersized buffer is reused. Subsequently, copy_from_lzss_window() performs memcpy operations that read well beyond the allocated buffer (up to 249 bytes past an 8-byte allocation), leaking adjacent heap memory. The leaked data is passed through a delta filter (trivially reversible) and returned to the caller via archive_read_data() before the CRC integrity check runs, meaning the data is already delivered before any error is detected. A 170-byte crafted RAR3 archive is sufficient to trigger the leak, and a PoC was developed by the reporter (GitHub PR #2898, Red Hat Bugzilla).

Successful exploitation results in disclosure of sensitive heap memory contents — up to ~257 bytes per extraction call — with high confidentiality impact and no integrity or availability impact. In services that automatically process user-supplied archives (e.g., web upload-then-extract-then-download pipelines), the leaked heap data is returned as apparent file content to the caller before any CRC error is raised, making the leak transparent to the application. The exposed heap memory may contain sensitive runtime data such as cryptographic material, credentials, or other in-memory secrets, depending on the host process's heap layout (GitHub PR #2898, Red Hat CVE).

A functional PoC (a 170-byte crafted RAR3 archive) was developed by the reporter (ElhananHaenel) and shared privately with the libarchive maintainer; it is not known to be publicly released as of the time of this report. No in-the-wild exploitation has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.00174 (~0.17%), indicating low near-term exploitation probability. Exploitation requires no authentication or user interaction, but does require the target system to process attacker-supplied RAR archives (GitHub PR #2898, Red Hat CVE).

1. Craft the malicious archive: Construct a RAR3 archive (~170 bytes) with the following block sequence: an LZSS-compressed block using a small (e.g., 3-bit) dictionary, followed by a PPMd-compressed block (which inflates dictionary_size to ~1 MB without reallocating the LZSS window), followed by a second LZSS block that uses a delta filter and requests 256 bytes of decompressed data.
2. Deliver the archive to the target: Submit the crafted RAR file to any service or application that uses libarchive to process user-supplied archives (e.g., upload endpoints, archive extraction APIs, file managers, or automated pipeline tools).
3. Trigger extraction: Cause the target application to call archive_read_data() on the malicious archive entry. The undersized LZSS window (8 bytes) is used to satisfy a 256-byte read request, causing copy_from_lzss_window() to read ~249 bytes of adjacent heap memory into the output buffer.
4. Receive leaked heap data: The application receives 257 bytes of output (including leaked heap contents) as normal file data before any CRC error is raised. In a web service context, this data may be returned in an HTTP response body.
5. Reconstruct heap contents: Reverse the delta filter applied to the output (compute heap[i] = output[i] + heap[i-1]) to recover the original heap bytes verbatim (GitHub PR #2898, Red Hat Bugzilla).

• File System: Presence of small (~170-byte), syntactically unusual RAR3 files with mixed PPMd and LZSS compression blocks submitted to archive-processing services.
• Logs: Application or service logs showing ARCHIVE_WARN or CRC mismatch errors (e.g., "Bad RAR file data") immediately after returning data from a RAR extraction call — particularly if the data size returned exceeds the declared file size in the archive.
• Process: AddressSanitizer (ASAN) reports of heap-buffer-overflow READ errors in copy_from_lzss_window within archive_read_support_format_rar.c if the application is instrumented.
• Network: Unexpected or anomalous binary data in HTTP response bodies from archive extraction endpoints, especially responses that are followed by an error on the next read call (GitHub PR #2898).

The upstream fix was merged into libarchive master on April 12, 2026 (commit 762b300, PR #2898), adding three defensive changes: (1) parse_codes() now checks whether the existing LZSS window is undersized relative to dictionary_size and reallocates if needed; (2) copy_from_lzss_window() rejects requests exceeding the actual window size; (3) parse_filter() validates block length against the actual window allocation rather than dictionary_size. Red Hat issued patched packages for RHEL 6–10 and OpenShift 4.x starting April 16, 2026 (e.g., RHSA-2026:8492 for RHEL 10, RHSA-2026:8510 for RHEL 9, RHSA-2026:8534 for RHEL 8). Debian, Ubuntu (USN-8292-1), SUSE, and AlmaLinux have also released updates. IBM has issued advisories for affected products. Organizations should update libarchive to the patched version for their distribution as the primary remediation; no configuration-based workaround is available (Red Hat RHSA-2026:8492, Red Hat RHSA-2026:8510, GitHub PR #2898).

The vulnerability was reported by security researcher ElhananHaenel, who provided a detailed technical write-up in the libarchive GitHub pull request describing the five-bug chain and its practical exploitability in web service contexts. The fix was reviewed and merged by libarchive maintainer kientzle on April 12, 2026. Community interest was noted on platforms including Bluesky and Mastodon, with security aggregators (RedPacketSecurity, pro-linux.de, linuxsecurity.com) covering the advisory. Multiple downstream projects (e.g., RADAR-base/radar-helm-charts) opened dependency update issues referencing this CVE shortly after disclosure (GitHub PR #2898).