CVE-2026-5121

What it actually does

CVE-2026-5121 is an integer overflow in libarchive’s zisofs block pointer allocation logic on 32-bit systems. When parsing a specially crafted ISO9660 image that uses zisofs compression metadata, arithmetic used to size or index heap allocations can wrap, causing libarchive to allocate an undersized buffer and then write beyond its bounds. The direct consequence is a heap buffer overflow in a process that reads the malicious archive or disk image. Depending on compiler hardening, allocator behavior, process privileges, and how libarchive is embedded, exploitation may cause process crashes or potentially arbitrary code execution. The CVSS vector indicates network-reachable, unauthenticated, low-complexity exploitation without user interaction where an affected service automatically processes attacker-supplied ISO images, with primary impact to confidentiality.

Why it matters to the business

Organizations that use libarchive on 32-bit platforms, or products built from affected Red Hat images, OpenShift components, or Red Hat Enterprise Linux packages that process untrusted ISO9660 images, could face data exposure or compromise of the service account running the parser. The greatest business risk is in automated ingestion pipelines, file scanning gateways, container/image processing systems, backup/indexing tools, helpdesk upload portals, or any service that accepts archive or disk-image content from external parties and processes it without manual review. Although this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low current EPSS, the bug class is memory corruption and should be treated seriously where vulnerable 32-bit processing paths exist.

How an attack unfolds

An attacker creates a malformed ISO9660 image containing zisofs metadata designed to trigger integer overflow during block pointer allocation. The attacker then delivers the image to an application, service, or workflow that uses a vulnerable 32-bit build of libarchive to inspect, extract, index, validate, scan, or convert the image. When libarchive parses the crafted structure, the overflow causes incorrect heap allocation sizing, followed by an out-of-bounds heap write. In less successful attempts, the target process may crash. In more advanced exploitation scenarios, the attacker shapes heap memory and archive contents to gain code execution in the context of the parsing process or to read sensitive memory, depending on the vulnerable application’s exposure and runtime mitigations.

How to fix it

Upgrade libarchive and vendor-provided packages as soon as fixed builds are available for the affected distribution or product. No exact fixed versions were provided in the input, so remediation should use the latest security advisory packages from the relevant vendor channels for libarchive, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images. Prioritize systems that are 32-bit or that run 32-bit libarchive components and that process untrusted ISO9660 or archive content. Where immediate patching is not possible, mitigate by disabling processing of ISO9660/zisofs images from untrusted sources, routing such files through isolated sandboxes, enforcing strict file-type allowlists, limiting automatic extraction or preview features, running parsing services with least privilege, and applying seccomp/AppArmor/SELinux confinement and memory-hardening compiler/runtime options where available.

How to confirm the fix worked

Confirm exposure by inventorying installed libarchive packages and embedded copies, then verifying whether they are 32-bit builds or include 32-bit compatibility libraries. Check vendor package metadata and advisories to ensure the installed version includes the fix once released. Validate application exposure by identifying services, jobs, and container images that call libarchive, bsdtar, archive_read APIs, or language bindings to process ISO9660 images. Test mitigations by submitting benign ISO9660 and zisofs samples to confirm expected blocking, sandboxing, or safe handling behavior. After patching, confirm that package managers report no outstanding libarchive security updates and rebuild or redeploy dependent containers and appliances so they no longer include vulnerable base image layers.

Typical attack path

1. Identify an externally reachable or automated workflow that processes uploaded or remotely supplied ISO9660 images using libarchive on a 32-bit system.
2. Craft an ISO9660 image with malicious zisofs block pointer metadata that causes integer arithmetic to wrap during allocation.
3. Submit, upload, email, or otherwise cause the target workflow to process the crafted ISO image.
4. Trigger libarchive parsing through extraction, preview generation, content inspection, malware scanning, indexing, or conversion.
5. Exploit the resulting heap buffer overflow to crash the process, disclose memory, or attempt code execution under the privileges of the affected service.
6. If code execution is achieved, pivot to local credential access, data collection, persistence, or lateral movement depending on the surrounding application context.

How to detect it

To determine whether exploitation may have occurred, review logs from applications and services that process archives or ISO images, including upload portals, mail/file gateways, malware scanning tools, indexing services, CI/CD artifact processors, backup tools, content management systems, and container/image build pipelines. Look for processing of unexpected ISO9660, .iso, or zisofs-compressed files followed by crashes, segmentation faults, heap corruption messages, service restarts, core dumps, or anomalous child processes spawned by archive-handling services. On Linux systems, inspect systemd journal, /var/log/messages, /var/log/syslog, auditd logs, kernel logs, application upload logs, web access logs, object storage access logs, and EDR telemetry for libarchive consumers such as bsdtar or custom services linked against libarchive. Because there are no public exploit-specific indicators in the provided data, detection should focus on behavioral evidence: malformed ISO ingestion, parser crashes, memory corruption diagnostics, unexpected outbound network activity from archive-processing workers, and new files or processes created by those workers shortly after processing an ISO image.

• ISO9660
• zisofs
• .iso
• bsdtar
• libarchive
• archive_read
• Segmentation fault
• segfault
• heap buffer overflow
• heap-buffer-overflow
• buffer overflow
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid pointer
• double free or corruption
• corrupted double-linked list
• core dumped
• systemd-coredump
• AddressSanitizer: heap-buffer-overflow
• archive_read_support_format_iso9660
• archive_read_open
• /usr/bin/bsdtar
• /usr/lib/libarchive.so
• /usr/lib32/libarchive.so
• /lib/libarchive.so
• /var/lib/systemd/coredump

What your security team should do

• Prioritize patch tracking for libarchive packages across Red Hat Enterprise Linux, OpenShift Container Platform, Red Hat hardened images, and any internally built 32-bit images or appliances.
• Inventory all systems and containers that process uploaded, emailed, downloaded, or externally supplied ISO9660/archive files, with special attention to automated ingestion and scanning workflows.
• Temporarily block or quarantine ISO9660 images, especially zisofs-compressed images, from untrusted sources until affected systems are patched or isolated.
• Run archive parsing workloads in hardened sandboxes with least privilege, no unnecessary network access, and enforced SELinux/AppArmor/seccomp profiles.
• Search historical logs for crashes or abnormal failures in services that use libarchive, bsdtar, archive extraction, preview generation, or file scanning near the time ISO images were processed.
• Ensure container images are rebuilt from patched base images rather than only patching running hosts.
• Monitor vendor advisories for exact fixed package versions and update vulnerability management records when fixed builds become available.
• Because KEV and ransomware flags are currently negative and EPSS is low, prioritize based on actual exposure to untrusted ISO processing rather than broad emergency response.