CVE-2026-48864

What it actually does

This vulnerability is a heap buffer overflow in libsolv triggered while decompressing attacker-controlled compressed data embedded in `.solv` repository metadata files. A vulnerable application that parses a malicious `.solv` file can read or write beyond the bounds of an allocated heap buffer. Depending on memory layout and build-time protections, this can cause process crashes, disclosure of process memory, corruption of application state, or potentially arbitrary code execution in the context of the process using libsolv. The CVSS vector indicates local attack surface with required user interaction: exploitation generally requires a user, service, package-management workflow, or automation component to process a crafted `.solv` file.

Why it matters to the business

Organizations using affected Linux distributions, container platforms, update infrastructure, or management tooling may face disruption or compromise if package-management components process malicious repository metadata. Successful exploitation could interrupt patching and software deployment workflows, expose sensitive data held by the affected process, or allow attacker-controlled execution within trusted administrative tooling. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity, which lowers immediate internet-scale urgency; however, the affected ecosystem includes widely deployed enterprise Linux and platform-management products, so remediation should be incorporated into regular security update cycles.

How an attack unfolds

An attacker first creates a malformed `.solv` file containing compressed data structured to trigger the heap overflow during decompression. They then need to get a vulnerable libsolv-consuming application to process that file, such as by convincing an administrator or automation workflow to use untrusted repository metadata, importing crafted metadata into a package-management workflow, or placing the file where a vulnerable tool will parse it. When the file is processed, libsolv performs insufficient validation during decompression and accesses memory outside the intended heap buffer. In a simple case, the application crashes, causing denial of service. With reliable heap manipulation and favorable target conditions, the attacker may be able to disclose memory or influence control flow, potentially executing code with the privileges of the affected process.

How to fix it

Upgrade libsolv and any affected vendor products to versions containing the vendor fix as soon as packages are available. Because no exact fixed versions were provided, follow the relevant security advisories for openSUSE libsolv, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, Red Hat Satellite, Red Hat Update Infrastructure, and Red Hat hardened images. Apply distribution security updates rather than manually replacing shared libraries where possible, because dependent package-management components should remain version-compatible. As interim mitigation, avoid processing `.solv` files or repository metadata from untrusted sources; restrict who can add or modify package repositories; enforce repository signing and trusted mirrors; disable or quarantine untrusted third-party repositories; and run package-management or metadata-processing workflows with least privilege and appropriate sandboxing where feasible. For container and image environments, rebuild affected images after base image updates are available and redeploy workloads using the refreshed images.

How to confirm the fix worked

Confirm exposure by inventorying installed libsolv packages and vendor products that embed or depend on libsolv. On RPM-based systems, check installed versions with commands such as `rpm -q libsolv` and review vendor errata status using the platform package manager. On openSUSE systems, use `zypper info libsolv` or equivalent package inventory tooling. Validate that all affected hosts, containers, appliances, and management platforms have received the relevant vendor security update. Confirm that package managers and repository-processing tools continue to function after updating. To validate mitigation, review configured repositories and ensure only trusted, signed repositories are enabled; attempt to locate unexpected `.solv` files in cache or import paths; and verify that container images have been rebuilt from patched base images rather than only patching running instances.

Typical attack path

1. Identify a target system or workflow that uses a vulnerable version of libsolv to parse `.solv` files or repository metadata.
2. Craft a malicious `.solv` file with compressed data designed to trigger out-of-bounds heap access during decompression.
3. Deliver the crafted file through social engineering, an untrusted repository, a compromised metadata source, a supply-chain workflow, removable media, or another file-ingestion path.
4. Wait for a vulnerable package-management, update, build, or repository-processing component to parse the crafted `.solv` file.
5. Trigger heap corruption during decompression, causing a crash, memory disclosure, program state corruption, or possible code execution.
6. Use any achieved execution or information disclosure to further compromise the host, disrupt update workflows, or pivot to additional systems.

How to detect it

Look for evidence that vulnerable package-management or repository-processing tools handled suspicious `.solv` files before crashing or behaving abnormally. Relevant log sources include system logs, package-manager logs, repository synchronization logs, build pipeline logs, container image build logs, OpenShift or Satellite task logs, and crash reporting systems such as systemd-coredump, ABRT, apport, or core dump directories. Investigate segmentation faults, aborts, heap corruption messages, or unexpected restarts involving libsolv consumers such as package managers, dependency solvers, repository sync tools, and image build processes. Review filesystem timelines for newly created or modified `.solv` files from untrusted locations, especially in package-manager caches, repository metadata directories, CI/CD workspaces, and temporary import locations. If crashes occurred, collect core dumps and process command lines to determine which `.solv` file was being parsed. Also review repository configuration changes, recently added third-party repositories, failed repository refresh operations, and unusual metadata downloads preceding the crash. No public exploit-specific payload signature is available from the provided data, so detection should focus on anomalous `.solv` ingestion, crash artifacts, and repository provenance.

• .solv
• libsolv
• systemd-coredump
• segfault
• Segmentation fault
• 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
• zypper
• dnf
• yum
• repo2solv
• rpmmd2solv
• susetags2solv
• /var/cache/zypp/solv/
• /var/cache/dnf/
• /var/cache/yum/
• /var/cache/libsolv/
• /var/lib/rpm/
• /var/crash/
• /var/lib/systemd/coredump/

What your security team should do

• Inventory systems, containers, appliances, and management platforms that include libsolv or affected vendor products.
• Prioritize updates for systems where package-management, repository synchronization, build, or image-generation workflows process externally supplied repository metadata.
• Apply vendor security updates for affected distributions and products when available, then rebuild and redeploy dependent container images.
• Restrict repository configuration changes to trusted administrators and enforce signed, trusted package repositories only.
• Review third-party and temporary repositories; disable any that are unnecessary or not cryptographically trusted.
• Monitor for crashes or abnormal behavior in package-management and repository-processing tools, especially after processing new metadata.
• Search for unexpected or recently introduced `.solv` files in package-manager caches, repository mirrors, build workspaces, and update infrastructure staging areas.
• Because this issue is not in KEV, has low EPSS, and has no known mature exploit, handle as important but not emergency unless untrusted repository metadata is routinely processed.