CVE-2026-9149

What it actually does

The vulnerability is a heap buffer overflow in libsolv's `repo_add_solv` parsing path. A specially crafted `.solv` repository metadata file can include negative size values that lead to an undersized heap allocation followed by an out-of-bounds write. In practical terms, software that uses libsolv to parse solver/repository metadata can crash when it processes malicious input. Based on the current disclosure, the demonstrated impact is denial of service through process termination or instability; confidentiality and integrity impact have not been established.

Why it matters to the business

Systems and platforms that rely on libsolv for package, repository, image, or update metadata handling may become unavailable if they process malicious `.solv` data. This can disrupt package management, update workflows, repository synchronization, container or image build pipelines, and management platforms that depend on affected Red Hat, openSUSE, Satellite, OpenShift, Update Infrastructure, or hardened-image components. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at 0.00312, so broad active exploitation is not indicated; however, exposed automated repository-processing workflows should still be prioritized because the flaw is low-complexity once malicious input reaches the parser.

How an attack unfolds

An attacker prepares a malformed `.solv` file containing negative size values in fields consumed by libsolv. The attacker then causes a vulnerable component to process that file, such as by supplying untrusted repository metadata, influencing a repository mirror or synchronization workflow, placing the file where package-management tooling will ingest it, or convincing an operator or automated job to consume a malicious repository source. When the vulnerable libsolv code path reaches `repo_add_solv`, the negative size value causes an allocation smaller than required. Subsequent parsing writes beyond the allocated heap buffer, corrupting process memory and typically crashing the process. The most likely operational result is denial of service of the package-management, repository-processing, or update workflow using libsolv.

How to fix it

Update libsolv and any vendor products that bundle it to versions containing the vendor fix as soon as they become available. Because no exact fixed versions were provided, track advisories from Red Hat and openSUSE for affected products including Red Hat Enterprise Linux, OpenShift Container Platform, Satellite, Update Infrastructure, hardened images, and openSUSE libsolv packages. Rebuild or redeploy containers, appliances, and images that statically include or package vulnerable libsolv libraries after updating base images. As interim mitigation, prevent untrusted `.solv` files or repository metadata from being processed; restrict repository sources to trusted, authenticated, and integrity-verified origins; disable or isolate automated synchronization from untrusted mirrors; and run repository-processing jobs with least privilege and process isolation to limit blast radius from crashes.

How to confirm the fix worked

Confirm installed libsolv package versions against the relevant vendor advisory once fixed package versions are published. Validate that all dependent products, images, and containers have been rebuilt or updated and no longer include vulnerable libsolv libraries. Exercise package-management and repository-sync workflows with trusted metadata to confirm normal operation after patching. For exposure validation, inventory systems that contain `libsolv.so`, `libsolv-tools`, package managers or repository tools linked to libsolv, and management platforms that parse repository metadata. Where possible, use vulnerability scanners, SBOMs, package manager queries, and container image scans to confirm affected versions are no longer present.

Typical attack path

1. Identify a system, service, build pipeline, repository mirror, or management platform that uses a vulnerable libsolv package to parse `.solv` metadata.
2. Create a malformed `.solv` file containing negative size values that trigger the vulnerable `repo_add_solv` parsing path.
3. Deliver the crafted file through a repository, mirror, metadata feed, uploaded artifact, local file path, or social-engineered operator action that causes parsing by vulnerable tooling.
4. Wait for package-management, synchronization, update, or image/build automation to ingest the malicious `.solv` file.
5. Trigger heap corruption and process crash, causing denial of service or disruption to the dependent workflow.

How to detect it

Look for evidence that vulnerable tooling processed unexpected or malformed `.solv` files followed by crashes or service restarts. Relevant log sources include system journals, syslog, package-manager logs, repository synchronization logs, container build logs, Satellite and OpenShift platform logs, crash dumps, core dump metadata, endpoint telemetry, and file integrity monitoring. Focus on crashes of processes linked to `libsolv.so`, especially near repository refresh, metadata import, dependency solving, mirror synchronization, or image build activity. Investigate `.solv` files from untrusted repositories, unexpected upload locations, temporary directories, package cache directories, or mirror synchronization paths. Useful artifacts include core dumps, kernel OOPS or segfault messages, repeated service restarts, logs referencing `repo_add_solv`, heap buffer overflow diagnostics from hardened runtimes or sanitizers, and suspicious repository configuration changes shortly before the crash. There are no public threat actors or known ransomware campaigns associated with this vulnerability in the provided data, so detections should be behavior- and artifact-based rather than actor-specific.

• repo_add_solv
• libsolv.so
• libsolv.so.1
• heap-buffer-overflow
• out-of-bounds write
• AddressSanitizer: heap-buffer-overflow
• Segmentation fault
• segfault
• core dumped
• .solv
• /var/cache/zypp/
• /var/cache/dnf/
• /var/cache/yum/
• /var/lib/rpm/
• /var/lib/solv/
• /var/tmp/
• /tmp/
• coredumpctl
• systemd-coredump
• libsolv-tools
• repo2solv
• testsolv

What your security team should do

• Inventory all Linux systems, containers, repository mirrors, package-management services, build systems, and management platforms that include libsolv or affected vendor products.
• Monitor Red Hat and openSUSE advisories and apply the vendor-fixed libsolv packages immediately when available; rebuild dependent images and redeploy workloads that bundle the library.
• Restrict repository metadata ingestion to trusted and authenticated sources; block ad hoc or unauthenticated `.solv` metadata from automated workflows.
• Prioritize patching systems that automatically process external repository metadata, synchronize mirrors, or support production update and build pipelines.
• Review recent crashes in package-management, repository synchronization, Satellite, OpenShift, image build, and update infrastructure components for signs of malicious `.solv` parsing.
• Add detections for abnormal process crashes involving libsolv and for unexpected `.solv` files appearing in upload, cache, repository, or temporary directories.
• Run repository-processing services with least privilege, resource limits, and isolation to reduce the operational impact of a parsing crash.