CVE-2025-10230: The CVSS 10.0 Vulnerability That Hid in Samba for 13 Years

By Stanislav Fort, Founder & Chief Scientist, AISLE

Published November 7, 2025

A textbook vulnerability hiding in plain sight for over a decade

Following our discovery of three OpenSSL CVEs in August 2025, AISLE's autonomous system continued its analysis of critical infrastructure software. On September 2, 2025, it identified what is now known as CVE-2025-10230, a command injection vulnerability in Samba that received the maximum possible CVSS v3.1 score of 10.0.

The flaw allowed unauthenticated remote attackers to execute arbitrary commands with the privileges of the Samba process (often root on AD DCs) on Active Directory Domain Controllers, potentially compromising entire Windows domains. It had existed in the codebase for nearly 13 years, from Samba 4.0's release in 2012 until patches were issued on October 15, 2025.

Once identified, the bug was so crystal clear that Samba developers called it "glaringly obvious." Yet it had escaped detection through more than a decade of security audits in one of the most scrutinized open-source projects in existence.

Samba is the open-source implementation of Microsoft's SMB/CIFS networking protocol and Active Directory services. It powers file sharing and domain controller functionality across millions of Linux and Unix systems worldwide, from small business servers to enterprise data centers. When organizations need to integrate Linux systems into Windows environments or build cross-platform infrastructure, Samba is often the foundation.

This discovery matters because it demonstrates a fundamental challenge in software security: legacy code paths that developers assume are unused can harbor critical vulnerabilities. The feature was mentally written off by the Samba team as obsolete, yet it remained active and exploitable in every production release.

The Discovery

In September 2025, AISLE's autonomous security analysis system identified a command injection vulnerability in Samba's Windows Internet Name Service (WINS) implementation. The flaw resided in the "wins hook" feature, a mechanism that allows administrators to specify an external program to execute whenever a WINS name registration occurs.

WINS is a legacy NetBIOS name resolution protocol from the 1990s, largely obsolete in modern networks but still supported by Samba for backward compatibility. In vulnerable releases, Samba's Active Directory Domain Controller took NetBIOS names directly from untrusted network packets and inserted them into shell commands without any sanitization or validation.

Vulnerable code (source4/nbt_server/wins/wins_hook.c):

C
1cmd = talloc_asprintf(tmp_mem, "%s %s %s %02x %ld",
2                      wins_hook_script,
3                      wins_hook_action_string(action),
4                      rec->name->name,  /* NetBIOS name from network packet — INJECTION POINT */
5                      rec->name->type,
6                      (long int) rec->expire_time);
7/* Executed via shell */
8execl("/bin/sh", "sh", "-c", cmd, NULL);
Copy

The rec->name->name field comes directly from an unauthenticated WINS registration packet. By registering a crafted WINS name, an attacker controls the string passed to /bin/sh -c, so the AD DC runs both the configured hook and the attacker’s command. Because Active Directory Domain Controller processes typically run with root privileges, the attacker achieves immediate root-level system access.

Fixed code:

C
1/* Validate NetBIOS name contains only safe characters */
2for (p = rec->name->name; *p; p++) {
3    if (!(isalnum((int)*p) || strchr_m("._-", *p))) {
4        DBG_ERR("not calling wins hook for invalid name %s\n",
5                rec->name->name);
6        return;
7    }
8}
Copy

The fix validates that NetBIOS names contain only alphanumeric characters, hyphens, underscores, and periods before passing them to shell commands. This mirrors validation that had existed in the Samba 3 nmbd implementation since 1999 but was never ported to the Samba 4 Active Directory code path when it was developed.

The fix was straightforward, just add input validation. But this raises an obvious question: how did such a simple oversight persist in production code for 13 years?

How It Hid for Over a Decade

When Samba 4 was developed as a complete rewrite to support Active Directory (with development starting around 2005-2006), the new WINS server implementation in source4/nbt_server/wins/ was written from scratch. Samba maintains separate code trees: source3 for the legacy implementation, source4 for the Active Directory-capable version. The developers likely viewed WINS as legacy functionality and didn't prioritize porting security checks from the old codebase. The critical input validation that protected the Samba 3 implementation in source3/nmbd/ simply never made it into the Active Directory version.

Samba 4.0 was released in 2012 with the vulnerable code, and it persisted through every subsequent release until the October 2025 security patches.

Why did it go unnoticed for so long? The answer lies in assumptions about usage. Developers essentially ignored this code path because they believed nobody was using it in production. The wins hook on an AD DC was considered "unlikely to be useful" and represented what the team mentally categorized as "dead code": functionality that technically exists but receives minimal scrutiny because it's assumed to be unused.

The feature required a specific configuration to be exploitable:

1. Samba server running as an Active Directory Domain Controller
2. WINS support explicitly enabled (disabled by default)
3. A wins hook script configured in smb.conf

Standard Samba installations don't meet these criteria. Most modern networks use DNS instead of WINS. The wins hook parameter is unlikely to be useful on a domain controller and may be removed in future releases.

But that assumption is precisely what allowed the vulnerability to persist for over a decade. AISLE’s system doesn’t make assumptions about which code paths matter; it systematically traces data flow from untrusted inputs to dangerous operations, examining every path regardless of its perceived usage frequency.

"LLMs without that preconception came through and pointed out the now glaringly obvious bug."

— Douglas Bagnall, Samba Developer (https://www.openwall.com/lists/oss-security/2025/10/16/2)

Exploitation and Impact

Despite its 13-year lifespan, the exploitation path for this vulnerability is remarkably straightforward, requiring only a crafted unauthenticated WINS registration request to UDP/137 to achieve root access on a domain controller.

WINS operates over UDP port 137 using the unauthenticated NetBIOS Name Service protocol. An attacker simply sends a WINS name registration packet with shell metacharacters in the NetBIOS name field. No credentials required. No user interaction needed. Just a single malicious packet.

The 15-Character Constraint

NetBIOS names are limited to 15 characters due to the original IBM NetBIOS specification from the 1980s, which reserved 16 bytes for names (15 for the hostname, 1 for the resource type). While this significantly constrains payload size, it doesn't prevent exploitation. Attackers can leverage command substitution and creative shell syntax to work within this constraint.

The Samba team assessed that while the constraint adds complexity to exploit development, it doesn't materially raise the attack barrier or affect the CVSS scoring; a skilled attacker can still reliably exploit the vulnerability.

Impact

Successful exploitation grants root access to the domain controller, allowing attackers to:

• Dump password hashes for all domain users
• Create domain administrator accounts
• Deploy malicious Group Policy Objects
• Forge Kerberos Golden Tickets for persistent access
• Compromise all domain-joined machines

In enterprise security, compromising an Active Directory domain controller is often considered "game over" because it provides the keys to the entire domain infrastructure.

CVSS v3.1 10.0 and Real-World Risk

CVE-2025-10230 received a CVSS v3.1 base score of 10.0, the maximum possible severity rating. Only a handful of vulnerabilities ever achieve this score. The CVSS v3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H reflects:

• Network exploitable via UDP port 137 with no authentication required
• Low complexity despite the 15-character constraint
• Changed scope because compromising an AD domain controller affects all domain-joined systems
• High impact to confidentiality, integrity, and availability with root access

This rating reflects the reality: a single unauthenticated network packet can compromise a domain controller and, by extension, an entire Windows domain.

Real-World Risk: Theory vs. Practice

While the CVSS score accurately represents worst-case technical severity, real-world risk depends heavily on configuration. To be exploitable, a Samba installation must meet all three conditions:

1. Run as an Active Directory Domain Controller
2. Have wins support = yes explicitly configured (disabled by default)
3. Have a wins hook script path specified in smb.conf

The Samba maintainers assessed that this configuration affects "very few, possibly zero, users" in production environments. Modern networks have migrated to DNS-based name resolution, rendering WINS largely obsolete. Reflecting this reality, Ubuntu assigned the CVE a "Medium" priority for patch deployment despite the CVSS v3.1 10.0 score.

However, any Samba AD DC with this configuration enabled is trivially compromisable by any attacker who can reach UDP port 137. This alone warrants caution and swift remediation of the vulnerability.

Affected Versions and Patches

All Samba versions from 4.0.0 through 4.23.1 contain the vulnerability. The Samba team released security patches on October 15, 2025:

• Samba 4.23.2
• Samba 4.22.5
• Samba 4.21.9

Distribution-specific updates were released concurrently through major Linux vendors, including Ubuntu Security Notice USN-7826-1 (22.04 LTS, 24.04 LTS, 25.04, 25.10), Red Hat, Debian, SUSE, and others. Given Samba's widespread deployment as the foundation for file sharing and domain services on millions of Linux servers worldwide (from enterprise data centers to embedded NAS devices), coordinated patching across distributions was critical to ensure comprehensive coverage.

Immediate Mitigation

For systems that cannot immediately apply patches, administrators can eliminate the vulnerability by disabling the wins hook or WINS support entirely in smb.conf:

C
1[global]
2server role = active directory domain controller
3wins support = no         # default and sufficient
4wins hook =               # explicitly empty disables the call site
Copy

The Samba team has indicated they may deprecate and remove the wins hook functionality entirely in future releases. Given WINS's obsolescence and the inherent security risks of executing external scripts based on untrusted network input, organizations should prioritize migrating to modern DNS-based name resolution.

Responsible Disclosure and Collaboration

AISLE followed responsible disclosure practices throughout the discovery and remediation process. In early September 2025, our security researcher Igor Morgenstern submitted a comprehensive security report to the Samba team, including a detailed vulnerability description, proof-of-concept demonstration, and proposed patch. Within 24 hours, Samba developer Douglas Bagnall confirmed the vulnerability and began developing the official fix.

Security researcher Marcos Tolosa from OWASP independently discovered the same vulnerability shortly thereafter. The Samba team coordinated disclosure via the oss-security list, acknowledging both AISLE’s Igor Morgenstern and OWASP’s Marcos Tolosa. Reflecting on the discovery, Douglas Bagnall noted that both reports likely benefited from advanced static analysis tools.

From initial report in early September to public patch release on October 15, 2025, the timeline was approximately six weeks: a remarkably efficient turnaround for coordinated vulnerability disclosure affecting multiple release branches and downstream distributions. We're grateful to the Samba team, led by Douglas Bagnall, for their exceptional professionalism and responsiveness.

What This Means

Discovering a CVSS (v3.1) 10.0 vulnerability in a codebase as mature and scrutinized as Samba demonstrates a fundamental shift in security analysis. Traditional code review relies on human judgment about which code paths deserve scrutiny. The wins hook feature was mentally categorized by developers as unused legacy code, effectively invisible to security review despite its presence in every release.

Autonomous security analysis operates differently. These systems don't make potentially biased assumptions about usage patterns or developer intent. They systematically trace data flow from every untrusted input to every dangerous operation, examining code paths regardless of perceived importance, including the ones that human reviewers, forced to prioritize finite attention, might reasonably skip. The vulnerability was obvious once examined without the mistaken assumption that it didn't matter.

The fact that two independent research teams (AISLE and OWASP) discovered the same vulnerability nearly simultaneously using advanced analysis tools is significant. This parallel discovery suggests we're at an inflection point in software security. For years, the concern has been that AI would create asymmetry favoring attackers, enabling them to find vulnerabilities faster than defenders could. That asymmetry is beginning to shift.

This discovery proves that "dead code" can kill systems. The code executed. The vulnerability was real. The CVSS (v3.1) 10.0 rating was deserved. What didn't exist were the human assumptions that prevented anyone from looking.

At AISLE, we believe that advances in AI-powered security analysis must serve the collective good. The question has never been whether legacy code harbors critical vulnerabilities. It's whether defenders or attackers find them first. With autonomous systems like AISLE, we're shifting that race, systematically securing the infrastructure that underpins modern civilization before adversaries can exploit it.

Learn More

Interested in AISLE's autonomous security platform? Visit us at aisle.com or reach out to [email protected].

For technical details about this vulnerability:

• Samba Security Advisory
• Ubuntu Security Notice USN-7826-1
• Samba Vulnerability Database

Our deep appreciation goes to Douglas Bagnall and the entire Samba Team for their exceptional collaboration and professionalism. Thanks also to Marcos Tolosa from OWASP for his independent discovery, and to the broader open-source security community for maintaining the coordinated disclosure processes that make responsible vulnerability research possible.