CVE-2026-9150

What it actually does

CVE-2026-9150 is a stack-based buffer overflow in libsolv’s Debian repository metadata parser. When libsolv processes specially crafted Debian metadata containing malicious SHA384 or SHA512 checksum tags, it can overwrite stack memory and crash the consuming process. The described impact is availability loss rather than confirmed code execution: confidentiality and integrity are not currently indicated as affected, but services or package-management workflows that parse untrusted or compromised repository metadata can be disrupted.

Why it matters to the business

Organizations using affected libsolv-based package management, image build, repository synchronization, or platform update workflows may experience failed updates, crashed management processes, interrupted container or host patching, and degraded software distribution operations. The CVSS score indicates a meaningful availability risk, but current EPSS is low, the issue is not listed in CISA KEV, no ransomware use is reported, and no public exploit maturity is identified, so remediation should be prioritized according to exposure to untrusted Debian repositories or mirrors rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker needs a way to influence Debian repository metadata consumed by an affected libsolv instance. This could involve operating a malicious repository, compromising a repository mirror, intercepting repository metadata where transport protections are weak, or convincing an operator or automated system to add or synchronize an attacker-controlled repository. When the vulnerable system parses the crafted metadata, malformed SHA384 or SHA512 checksum tags trigger a stack-based buffer overflow in the parser, leading to memory corruption and likely termination of the package-management or repository-processing process. In practical terms, exploitation is most likely to cause denial of service during package resolution, repository sync, update checks, image builds, or platform lifecycle-management tasks.

How to fix it

Upgrade libsolv and affected platform packages to vendor-provided fixed releases as soon as they become available for the relevant distribution or product stream. Because no exact fixed versions were provided, track 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, and apply the corresponding errata or image updates. Until patched, restrict package managers and repository synchronization tools to trusted repositories only, enforce HTTPS and repository signature verification, remove unused or third-party Debian repository sources, limit who can add repositories, and avoid parsing repository metadata from untrusted mirrors. For automated build or CI systems, pin trusted repository configuration and fail closed on unsigned or unexpected metadata.

How to confirm the fix worked

Confirm remediation by verifying the installed libsolv package version against the vendor advisory for the operating system or product release in use. Re-run package refresh, repository synchronization, dependency resolution, and image build workflows after patching to ensure they complete successfully. Review repository configuration to confirm only approved, signed, and authenticated sources are enabled. Where vendor test cases or regression tests are available, validate that specially malformed SHA384 and SHA512 metadata no longer crashes the parser. Vulnerability scanners should be updated with the latest distribution advisories and used to confirm that affected libsolv builds are no longer present in hosts, containers, base images, repository servers, and management appliances.

Typical attack path

1. Identify systems, build pipelines, repository mirrors, or management platforms that use affected libsolv versions to parse Debian repository metadata.
2. Gain influence over repository metadata by hosting a malicious Debian repository, compromising a mirror, poisoning an internal repository source, or persuading a user or automated workflow to consume attacker-controlled metadata.
3. Craft Debian metadata containing malformed SHA384 or SHA512 checksum tags designed to overflow the stack buffer in libsolv’s parser.
4. Trigger metadata parsing through package refresh, dependency resolution, repository synchronization, image build, or update workflow execution.
5. Cause the affected process to crash or become unstable, disrupting software update and package-management operations.

How to detect it

To assess possible prior exploitation, review logs from package-management tools, repository synchronization services, CI/CD build jobs, container image build systems, Satellite/RHUI-like lifecycle-management platforms, and system crash reporting. Look for crashes, segmentation faults, aborts, or core dumps occurring during repository refresh, metadata parsing, dependency solving, or Debian repository synchronization. Correlate failures with recently added or changed repository URLs, third-party mirrors, unexpected Release/InRelease/Packages metadata downloads, or checksum-related parse errors involving SHA384 or SHA512. Inspect shell history, configuration management changes, and repository configuration files for new or suspicious Debian repository entries. Review network proxy, firewall, and DNS logs for package-management processes contacting unfamiliar repository hosts immediately before crashes. If core dumps are available, confirm whether the crashing process loaded libsolv and failed while parsing Debian metadata or checksum fields.

• Segmentation fault
• segfault
• core dumped
• stack smashing detected
• buffer overflow detected
• Aborted (core dumped)
• libsolv
• repo2solv
• deb2solv
• solv
• SHA384
• SHA512
• checksum
• InRelease
• Release
• Packages
• Packages.gz
• repodata
• repository metadata
• metadata parser
• deb metadata
• Debian metadata
• repo refresh
• repository synchronization failed
• dependency solving failed
• package metadata parse error

What your security team should do

• Inventory systems, containers, appliances, and management platforms that include libsolv, especially RHEL, OpenShift, Satellite, RHUI, openSUSE, and hardened image deployments.
• Prioritize remediation for internet-connected repository mirrors, CI/CD image builders, package cache servers, lifecycle-management platforms, and systems configured to consume third-party or externally controlled Debian repositories.
• Apply vendor fixes or updated container/base images when available; rebuild and redeploy dependent images that embed vulnerable libsolv libraries.
• Audit package repository configurations and remove untrusted, unused, unsigned, or non-HTTPS Debian repository sources.
• Enforce repository metadata signature verification and authenticated transport for package and mirror operations.
• Monitor for crashes or abnormal exits in package-management, repository synchronization, and image-build processes that coincide with parsing Debian metadata.
• Because the vulnerability is not currently in KEV and has low EPSS, handle it through normal vulnerability management unless exposure to untrusted repositories is present, in which case accelerate patching and repository hardening.