CVE-2026-4426

What it actually does

The flaw is an undefined-behavior condition in libarchive's zisofs decompression handling for ISO9660 Rock Ridge extensions. A crafted ISO image can provide an invalid pz_log2_bs field value that is not properly validated before use. When an application using libarchive parses or extracts the ISO, the malformed value can drive incorrect block-size calculations and memory allocation behavior, potentially causing process crashes. The demonstrated impact is denial of service: availability loss for the application or service that processes the archive. The CVSS vector indicates network-deliverable content, low attack complexity, no privileges required, and required user or application interaction to process the malicious ISO; it does not indicate confidentiality or integrity impact.

Why it matters to the business

Organizations that process untrusted ISO images with libarchive-backed tooling may experience crashes or service interruptions if malicious or malformed ISO files are ingested. This can affect file upload pipelines, malware scanning/sandboxing systems, backup or extraction workflows, CI/CD artifact processing, container/image workflows, and Linux systems or products that include libarchive. Because the vulnerability is not currently in CISA KEV, has low EPSS, and has no known mature public exploit based on the provided data, immediate mass exploitation is less likely; however, the issue still matters for internet-facing or automated file-processing services where a single crafted file can repeatedly disrupt operations.

How an attack unfolds

An attacker creates an ISO9660 image with Rock Ridge zisofs metadata containing a malicious or invalid pz_log2_bs value. The attacker then delivers that ISO to a target workflow that uses libarchive to inspect, list, extract, scan, convert, or otherwise parse archive contents. Delivery may occur through a web upload, email attachment, support portal, artifact repository, package ingestion pipeline, container or image-processing workflow, or any network-accessible service that accepts user-supplied archives. When the vulnerable libarchive code processes the crafted zisofs metadata, improper validation causes undefined behavior in decompression-related calculations and memory allocation. The affected process may terminate or become unstable, producing a denial-of-service condition for the calling application. Exploitation requires the target to process the attacker-controlled ISO; it does not require attacker authentication if the processing path accepts unauthenticated submissions.

How to fix it

Upgrade libarchive and any operating system, container base image, or product package that embeds libarchive to a vendor-fixed release as soon as one is available. No exact fixed versions were provided in the input, so remediation should follow the relevant vendor advisories for libarchive, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images. Rebuild and redeploy container images after updating the underlying package; updating a base image alone is not sufficient until dependent images and workloads are rebuilt. Where immediate patching is not possible, reduce exposure by blocking or quarantining untrusted ISO uploads, disabling automated extraction of ISO9660/zisofs content where feasible, enforcing file-type and size restrictions, processing untrusted archives in isolated sandboxes with CPU/memory/time limits, and ensuring supervisor processes restart crashed workers without causing broader service outages.

How to confirm the fix worked

Confirm installed libarchive package versions against the latest vendor advisory or package changelog for this vulnerability. On Linux systems, inventory packages using distribution-native tooling such as rpm, dnf, yum, dpkg, apt, or container image scanners, and verify that rebuilt images no longer contain vulnerable libarchive builds. Validate that applications using bundled or statically linked libarchive have also been updated, not only the system package. For exposure testing, identify workflows that accept ISO images and confirm they either run patched libarchive code or reject/quarantine untrusted ISO9660/zisofs content. In non-production environments, security teams may use a controlled malformed ISO test case from a trusted vendor or internal reproducer to confirm that parsing no longer crashes the process. Monitor service stability after deployment and verify that archive-processing services remain healthy when handling malformed archive input.

Typical attack path

1. Identify an application, service, or workflow that accepts ISO files or archive uploads and processes them with libarchive.
2. Craft an ISO9660 image using Rock Ridge zisofs extensions with an invalid pz_log2_bs field.
3. Submit or deliver the crafted ISO through an upload endpoint, email, artifact repository, scanning pipeline, or other ingestion path.
4. Trigger libarchive-based listing, extraction, scanning, or conversion of the ISO file.
5. Cause incorrect memory allocation or undefined behavior in zisofs decompression handling.
6. Crash or destabilize the processing service, resulting in denial of service.

How to detect it

To determine whether this was already exploited, focus on systems that process user-supplied ISO files with libarchive. Review application upload logs, reverse proxy logs, mail gateway logs, artifact repository logs, CI/CD job logs, malware-scanning/sandbox logs, and file-processing worker logs for ISO submissions followed by process crashes, abnormal exits, segmentation faults, core dumps, container restarts, or health-check failures. Correlate timestamps of uploaded .iso files or ISO MIME types with service restarts and libarchive-related error messages. On Linux, review journald, syslog, audit logs, kernel logs, container runtime events, Kubernetes/OpenShift pod restart history, and application supervisor logs for crashes of bsdtar, archive extraction utilities, scanners, or custom services linked against libarchive. Preserve suspicious ISO samples, generated core dumps, and surrounding logs for forensic analysis. Indicators are likely to be behavioral rather than actor-specific because the provided intelligence does not identify known exploitation campaigns, threat actors, or public exploit artifacts.

• pz_log2_bs
• zisofs
• ISO9660
• Rock Ridge
• libarchive
• bsdtar
• Segmentation fault
• core dumped
• SIGSEGV
• SIGABRT
• malloc():
• invalid malloc
• corrupted size
• double free or corruption
• .iso
• application/x-iso9660-image
• CrashLoopBackOff
• OOMKilled

What your security team should do

• Inventory all systems, containers, appliances, and applications that include libarchive or process ISO files, prioritizing internet-facing upload and automated ingestion workflows.
• Track vendor advisories for libarchive, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, and Red Hat hardened images, then upgrade to the first fixed package version available for each platform.
• Rebuild, rescan, and redeploy container images and application artifacts that inherit vulnerable libarchive packages from base images.
• Temporarily restrict or sandbox processing of untrusted ISO files until patched versions are deployed.
• Apply resource limits, crash isolation, queue controls, and worker restart safeguards to archive-processing services to reduce operational impact from malformed files.
• Search historical logs for archive-processing crashes correlated with ISO uploads or zisofs/ISO9660 parsing errors.
• Add SIEM detections for repeated crashes of services that process uploaded archives, especially immediately after ISO file submissions.
• Because current EPSS is low, there is no KEV listing, and no mature exploit is reported, prioritize remediation based on exposure: internet-facing and automated ingestion paths first, then internal systems.