Path Traversal in libzypp, the openSUSE/SUSE Updater (CVE-2026-25707, CVSS up to 8.8) — Update Now

A vulnerability has been found in "libzypp," the core component that installs and updates software on the "openSUSE" Linux distribution and the enterprise "SUSE Linux Enterprise." With only a small tweak to the data received from a software source (a repository), an attacker can overwrite important files that should never be changed on your PC or server. The identifier is CVE-2026-25707, with a severity of up to CVSS 8.8 out of 10 (NVD rating). The U.S. National Vulnerability Database (NVD) published the details on June 29, 2026.

It may sound contradictory, but this is a hole in the very mechanism that exists "to apply security updates." On Linux, it is routine to automatically fetch and replace software from a trusted source, and that work usually runs with the system's highest privileges (administrator rights). That is exactly why a compromise here spreads damage quickly. SUSE, the developer, has begun shipping fixed versions for each product, and users are urged to update without delay.

*Severity scores differ by rating body. NVD rates it 8.8, while the developer SUSE rates it 7.4. The reason for the gap is explained below.

Who is at risk, and what is the damage

This hole can be exploited by an attacker who can set up — or hijack — a software source (repository) that the user has added and trusts. Examples include the operator of a non-official add-on repository acting maliciously, such a repository being taken over, or an attacker intercepting an unencrypted delivery path and swapping traffic. For an organization running its own internal mirror (a replica delivery server), that mirror could be turned into the entry point of an attack.

The attacker embeds "../" (the symbol that moves up one directory level) into the metadata listing the software a repository serves, causing files to be written outside the designated storage area when software is fetched. libzypp temporarily stores fetched data in a local cache folder (under /var/cache/zypp/), but it validated the path value poorly. Allowing a path such as ../../../../etc/passwd lets even files at the heart of the system be overwritten.

The essence of the damage is that "the update process meant for safety" becomes the doorway to a takeover. Because the update work runs with administrator privileges, overwriting configuration files or auto-run mechanisms can hand over full control of a server or PC (privilege escalation) or break boot-critical files so the machine stops working (denial of service). The blast radius is widest not for individuals updating one machine by hand, but for organizations distributing the same add-on repository to hundreds of servers. A hole in a foundational piece of software rippling across the whole system is a textbook supply-chain risk. Our OSS supply-chain scanner also covers why it matters to inspect such "foundational software you depend on" all at once.

What libzypp is, and whether you are affected

libzypp is the "heart of software management" on openSUSE and SUSE Linux Enterprise, handling search, fetch, install, update, and removal of software. The familiar zypper command and the YaST configuration tool both call libzypp internally. It is the unsung workhorse that resolves software dependencies and verifies that sources are legitimate.

What matters is "whether your PC or server is affected." libzypp is specific to SUSE-family Linux; other Linux families use different mechanisms. A rough guide:

In short, if you use Ubuntu, Debian, or a Red Hat-family distribution, you are not subject to this vulnerability itself. Conversely, if you run openSUSE or SUSE servers in production, the safest assumption is that you are affected, and you should proceed with remediation.

How files get overwritten

The mechanism is simple. A repository serves a catalog (metadata) of "which software is where, under what name." libzypp reads this catalog, fetches files from the listed locations, and lays them out in the same structure in a local cache folder. The problem: even when the storage location (the location value) in the catalog contained a relative path stacked with ../, it was trusted and processed as-is.

The developer's bug report (bsc#1259802) states the attack idea plainly. Knowing the cache base is /var/cache/zypp/(repo name), planting an entry like <location href="../../../../etc/passwd"> in the catalog lets an attacker walk back up from the intended storage area and overwrite files such as /etc/passwd (the user account list). Moreover, if the repository's signature is already trusted and the data checksum matches, arbitrary data could be written without going through the RPM signature check that normally guards against tampering of the software itself.

The classification is "relative path traversal" (CWE-23), where the storage path escapes the intended range. The fix was made in the two components that parse the catalog (in the relevant commit, ContentFileReader.cc and RepomdFileReader.cc): entries pointing outside the repository (those containing ../) are now detected, warned about, and discarded rather than imported.

Why the severity splits between "8.8" and "7.4"

For the same vulnerability, the numbers differ by rating body. NVD rates it up to 8.8 (low attack complexity, and it counts an impact on availability — keeping the service running), while the developer SUSE rates it 7.4 (the attack requires several conditions to line up, making it high-complexity, with no availability impact). The gap reflects a difference in how easily an attacker is judged able to assemble the preconditions.

The practical point is that, under either rating, the premise is a state where "a malicious or hijacked repository is being trusted." If you only use the standard official repositories and your traffic is encrypted, this is not something that gets exploited instantly. That said, environments that add non-official repositories are common, and if one of them is breached, it becomes a real threat. Rather than the size of the number, it is more useful to check "whether you are carrying any untrusted sources."

Affected versions and the fix

Upstream libzypp was fixed in the 17.38 series, and update packages are being rolled out per product (for example SUSE-SU-2026:2590-1). Because exact package version numbers differ by product due to packaging, the most reliable way to confirm the precise affected and fixed versions is to check your own product on the SUSE CVE page.

*Updates from the same period also bundle other repository-handling fixes, including another path traversal via configuration (.repo) files (CVE-2026-44942). It is safest to apply them together.

What to do now

The top priority is updating to the fixed version. On openSUSE and SUSE Linux, applying the distributed updates also refreshes libzypp. If you run from the command line, the basics are to refresh the catalog with zypper refresh and then apply updates with zypper update (or zypper patch). Organizations with many servers should list which hosts still run an old libzypp and update those using external add-on repositories first.

If you cannot update right away, reducing the "untrusted sources" that are the precondition for damage is your interim defense. Specifically: review your non-official add-on repositories and keep only the ones you truly need; switch unencrypted (http://) repositories to encrypted (https://); and, if you use an internal mirror, reassess the security of that server itself. Taking one look at "where your software actually comes from" prepares you for similar threats beyond this one.

Timeline

This vulnerability was found internally not by an outside attacker but by a libzypp developer (Michael Andres), who prepared the fix and shipped updates before disclosure. The fact that a fix was ready before the details became widely known is a positive for users. The main flow:

Summary

CVE-2026-25707 is a path traversal flaw in libzypp, the component that installs and updates software on openSUSE and SUSE Linux. Simply planting ../ in the catalog served by a malicious (or hijacked) repository can overwrite critical system files through the update process that runs with administrator rights, leading to takeover or denial of service. Fixed versions are already shipping, so applying updates is the key step.

This is the kind of risk unique to foundational software: the "mechanism for applying updates" itself becomes the hole. Take this chance to inspect where your software comes from and to avoid carrying untrusted sources.

FAQ

References

• ・NVD — CVE-2026-25707
• ・SUSE — CVE-2026-25707 (per-product impact and fixes)
• ・SUSE Bugzilla — bsc#1259802
• ・openSUSE/libzypp — fix commit
• ・SUSE — Security update SUSE-SU-2026:2590-1
• ・MITRE — CWE-23 (Relative Path Traversal)
• ・openSUSE/libzypp — project