Vulnerability advisory: Rogue CA Injection in Samba's AD Certificate Enrollment

The DREAM Security Research Team has identified a critical security vulnerability in Samba's Group Policy certificate auto-enrollment extension. The flaw allows a machine-in-the-middle attacker to inject a rogue Certificate Authority certificate into a Linux machine's system-wide trust store during initial Group Policy application on a newly joined Active Directory host.

Vulnerability: CVE-2026-3012
Affected versions: Samba 4.16.0 and later, when certificate auto-enrollment was introduced
Persistence: Rogue CA survives reboots and standard updates

Who is Affected?

Any organization that extends Active Directory Certificate Services to Linux domain members using Samba 4.16+ is potentially affected. As enterprises increasingly adopt hybrid environments with Linux servers, containers, and cloud workloads joined to AD, the attack surface for this vulnerability grows with every domain join. Active Directory’s PKI was designed with the assumption that all members receive CA certificates through trusted Group Policy distribution, but when Linux hosts join the domain, that assumption breaks down at the protocol boundary.

The vulnerable code path runs inside samba-gpupdate, the command responsible for applying Group Policy on Linux. The CA certificate retrieval over HTTP occurs when the enrollment process needs to establish trust for the first time – specifically during the machine’s initial domain join, when the local certificate cache has been cleared, or when an administrator runs samba-gpupdate –force to re-apply policies from scratch. On a regular Group Policy refresh cycle, Samba usually skips re-downloading unless the policy is enforced or detected as changed. In practice, every new machine joining the domain gives an on-path attacker an opportunity to inject a rogue CA.

How It Works

Imagine an organization that deploys a Linux server to host an internal HR portal. The server needs an HTTPS certificate signed by the organization’s CA so that employees’ browsers trust it without security warnings. Rather than generating a certificate manually, the IT team relies on certificate auto-enrollment – the server automatically obtains a trusted certificate from AD CS. This is a common setup in enterprises that manage Linux machines alongside Windows infrastructure.

Samba is the most common way to join a Linux machine to a Windows Active Directory domain. When the administrator enables certificate auto-enrollment via Group Policy, Samba’s Group Policy update triggers the following steps:

Step 1 – Discover the CA via LDAP. Samba connects to Active Directory over LDAP using the machine’s Kerberos credentials. It queries the configuration partition to find out which CAs exist, their hostnames, and their root certificates. This connection is protected by Kerberos mutual authentication, where both sides prove their identity using shared secrets, and by SASL/GSSAPI wrapping, which provides integrity and often privacy for every message. Samba defaults to client ldap sasl wrapping = seal, so in typical deployments all LDAP traffic is both signed and encrypted. Exact enforcement depends on Domain Controller policy, but in practice this combination of mutual authentication and message-level integrity makes LDAP tampering extremely difficult for an on-path attacker. At the end of this step, Samba has a trusted copy of the CA’s root certificate.

Step 2 – Fetch the CA root certificate via SCEP over HTTP. Samba then contacts the CA’s Network Device Enrollment Service endpoint over plain HTTP using the SCEP protocol, defined in RFC 8894, to retrieve the same CA root certificate. SCEP’s sole role here is downloading the CA certificate – it is not used for the actual certificate enrollment. Samba builds the URL as http://<hostname>/CertSrv/mscep/mscep.dll/pkiclient.exe – the standard Windows NDES endpoint for SCEP certificate retrieval – and calls GetCACert, so this retrieval is not just unauthenticated – it is performed over plaintext by design. Unlike Step 1, this HTTP request has no protection – no TLS, no certificate pinning, no signature verification. Any attacker who can position themselves on-path between the Linux host and the AD CS server – via the same L2 segment, a rogue gateway, ARP spoofing, or similar techniques – can intercept the request and return a rogue certificate. The certificate received over this connection is saved into the operating system’s trusted root CA store.

Step 3 – Request a machine certificate. Using the certmonger service and the cepces plugin, Samba requests a certificate for the machine from AD CS over HTTPS with Kerberos authentication, via Microsoft’s CEP/CES web services. This HTTPS connection is only possible because the CA’s root certificate was installed into the trust store in Step 2 – without it, the Linux machine cannot establish a trusted TLS session with AD CS. The CA signs the machine’s public key and returns a trusted certificate. In our example, this is the HTTPS certificate that the HR portal will use. Windows endpoints already trust the AD CS root CA through Group Policy distribution; Step 2 is what brings the Linux machine into that same trust, allowing it to participate in the organization’s PKI and serve HTTPS without certificate warnings.

The vulnerability

During the enrollment process described above, Samba retrieves the CA’s root certificate twice – first over LDAP, which is typically integrity-protected and often sealed, making tampering extremely difficult, and then again over plain HTTP, an unauthenticated channel open to interception. In a normal, unattacked environment, these two certificates are identical. But the code never compares them. The LDAP certificate is only used as a fallback when the HTTP request fails entirely. As long asthe attacker ensures the HTTP request succeeds – which is trivial for a MITM – the trusted LDAP certificate is silently discarded, and the rogue one takes its place.

The following diagram illustrates this:

The impact

The attacker can now injected a rogue root CA into the machine’s trust store. This is not just a compromise of one machine’s TLS validation. It is a breach of the Active Directory trust model itself. AD Certificate Services exists to provide a single, centrally managed chain of trust across every domain member. Once an attacker poisons the CA store of a Linux host, that machine silently exits the organization’s PKI while appearing to remain a healthy domain member. The attacker can generate a valid-looking certificate for any domain, intercept any HTTPS connection, capture credentials and tokens, and forward traffic so the user never notices. The rogue CA persists across reboots and standard updates. Traditional AD monitoring will not detect it because the machine’s domain membership, Kerberos tickets, and Group Policy status all appear normal.

RFC Compliance Gap

While SCEP, as defined in RFC 8894, treats GetCACert as an unauthenticated HTTP operation, Section 2.2 explicitly addresses this scenario:

“After the client gets the CA certificate, it SHOULD authenticate it in some manner unless this is deemed unnecessary, for example, because the device is being provisioned inside a trusted environment. For example, the client could compare the certificate’s fingerprint with locally configured, out-of-band distributed, identifying information, or by some equivalent means such as a direct comparison with a locally stored copy of the certificate.”

Most SCEP clients have no easy way to perform this validation – they are typically network devices or standalone systems that lack an independent trusted source for the CA certificate. Samba, however, is in a uniquely strong position: because the machine is domain-joined, it already has the exact same CA certificate from a Kerberos-authenticated, integrity-signed LDAP connection. The RFC’s recommended comparison is not just possible here, it is trivial. Yet the current code never performs it.

Disclosure Timeline

‍

Remediation

• Audit trust stores on domain-joined Linux machines for unexpected CA certificates

• Perform domain joins only on trusted, segmented networks

• Verify CA fingerprints after domain join against known-good AD CS certificates

• Update Samba immediately to version 4.22.10, 4.23.8, or 4.24.3 (depending on your branch)