high

CVE

CVE-2026-48864

CWE

CWE-787, CWE-20

Affected Surface

libsolv repopagestore .solv parser, openSUSE/libsolv before downstream hardening where untrusted .solv files are parsed, Linux package-management tools and scanners linked against libsolv, Repository mirroring, analysis, or CI jobs that process attacker-supplied .solv cache files

CVE-2026-48864 is a high-severity memory-corruption issue in libsolv, the dependency solver library used by Linux package-management tooling. The flaw is in .solv cache parsing, specifically page decompression inside the repository page store.

NVD published the CVE on 26 May. Red Hat’s Bugzilla entry and the openSUSE pull request show the core issue: repopagestore_load_page_range() and repopagestore_read_or_setup_pages() call unchecked_decompress_buf() on compressed data loaded from a .solv file without first validating it with check_decompress_buf().

Affected project

Affected project:

  • openSUSE/libsolv and downstream packages using the .solv repository cache parser

Exposure is highest in applications that process .solv files from outside their trust boundary: repository-analysis tools, mirror validators, CI jobs, malware scanners, package-index importers, or support tooling that accepts uploaded package-manager cache artifacts.

The upstream maintainer response matters for risk modeling. The proposed PR was closed after discussion because .solv is designed as a high-speed cache format and not as an untrusted interchange format. That means defenders should not assume every upstream build will treat malicious .solv input as in-scope. Downstream distributions and security products may still need hardening if their workflows parse untrusted cache files.

Vulnerable decompression path

The proposed patch describes two vulnerable paths:

repopagestore_load_page_range()
  -> unchecked_decompress_buf(compressed_page, outbuf)

repopagestore_read_or_setup_pages()
  -> unchecked_decompress_buf(compressed_page, outbuf)

The unsafe call is a performance shortcut. Other libsolv code uses a checked helper:

if (!check_decompress_buf(in, inlen, out, outlen))
  return error;
unchecked_decompress_buf(in, inlen, out, outlen);

The vulnerable page-loading path skips the check and assumes the compressed page is structurally valid. With a crafted .solv file, the decompressor can be driven past the output buffer boundary. The PR notes two example shapes:

  • compressed data that expands beyond the REPOPAGE_BLOBSIZE output buffer
  • a backreference at the beginning of the output stream whose offset points before the start of the output buffer

In both cases, the parser is doing work on attacker-controlled compressed data before proving that the decompressed stream fits the page buffer.

Why package-cache parsers are supply-chain surface

.solv files are local cache artifacts, not source packages. That can make the bug easy to dismiss. The security-relevant question is not whether a normal package manager downloads arbitrary .solv files from the public internet by design. It is whether any application in your environment parses .solv files supplied by users, mirrors, test fixtures, support bundles, or CI inputs.

A modern supply-chain workflow often includes package metadata ingestion outside the package manager itself:

external repository or support bundle
  -> mirror/import job
  -> dependency resolver or SBOM tool linked with libsolv
  -> .solv cache parsed for speed
  -> memory corruption inside parser process

If that parser runs in a privileged build image, artifact-ingestion service, repository mirror, or security scanner, memory corruption can become a foothold in the software supply chain.

Relationship to adjacent hardening

The same area of code had adjacent hardening in openSUSE/libsolv PR #617, which handled integer overflow in repo_add_solv() data-size arithmetic. That PR was merged in April after an ASAN reproduction showed a heap-buffer overflow while reading crafted .solv data.

The pattern across both issues is the same: the .solv parser is optimized for trusted cache speed, but security tools and automation may accidentally promote that parser to an untrusted input boundary. Once that happens, assumptions that are reasonable for local cache files become dangerous.

Detection and inventory

Inventory packages and linked tools:

rpm -qa | grep -i libsolv
dpkg -l | grep -i libsolv
ldd /usr/bin/* 2>/dev/null | grep libsolv

Then identify workflows that parse .solv files from outside the host:

repository mirror importers
package metadata converters
SBOM and dependency-resolution jobs
CI fixtures containing solver caches
support-bundle analysis tools
security scanners that unpack package-manager state

Search logs for crashes in tooling that calls repo_add_solv, repopagestore_load_page_range, repopagestore_read_or_setup_pages, or unchecked_decompress_buf, especially after processing externally supplied repository metadata.

Remediation

Apply distribution updates when available. Where upstream or downstream packages do not treat untrusted .solv parsing as a supported threat model, isolate the parser instead:

  • do not accept .solv files as user-controlled input
  • regenerate solver caches from trusted repository metadata instead of importing cache files
  • run metadata-import jobs in low-privilege sandboxes
  • disable network and credential access for package-cache parsing jobs
  • treat crashes in .solv parsing as potential exploit attempts, not routine malformed input

If your product is a scanner, repository service, or CI platform that accepts package-manager state from users, add explicit validation or conversion before handing .solv data to libsolv. The safe boundary is structured repository metadata, not opaque compressed cache pages from an untrusted source.

References