What is CVE-2026-6949?
CVE-2026-6949 is an out-of-bounds write in the internal DNS server that ships with Samba’s Active Directory Domain Controller. It is reached by sending a DNS packet whose TSIG record uses DNS name compression. The vulnerability carries a CVSS v3.1 base score of 7.5 (High).
The flaw sits in a size calculation. TSIG signs a defined region of a DNS packet, and to determine the size of that region Samba subtracted the presumed size of the TSIG record from the length of the packet. When the record uses name compression, that presumed size can be computed incorrectly. In most cases the result is nothing more than a signing failure. In the extreme case, Samba treats the TSIG record as larger than the entire packet, and the subtraction wraps the size of the signed portion to a very large integer. The copy that follows runs past the end of the allocation and into unallocated memory, and the DNS process crashes.
Exploitation happens before authentication. Per the vendor’s own scoring, the issue is reachable over the network and requires no privileges and no user interaction. A single crafted packet is enough, which means an attacker needs nothing beyond the ability to send DNS traffic to the affected service.
The fix arrived as part of a coordinated Samba release on July 28, 2026 that addressed six vulnerabilities in total. Two of those, both scored 8.8, allow an authenticated low-privilege user to bypass LDAP access controls and take over an Active Directory domain. The same release also fixed CVE-2026-58218, an unauthenticated TKEY name cache exhaustion issue that can block DNS TSIG signing outright. Defenders triaging CVE-2026-6949 are almost certainly triaging that set as a whole, and the DNS signing path is implicated in more than one of them.
What assets are affected by CVE-2026-6949?
Every Samba version since 4.0 is affected. The exposure is narrower than that range suggests, because the vulnerable code is the internal DNS server used by a Samba Active Directory Domain Controller. Samba deployments that delegate DNS to BIND9 through the DLZ module are not affected, and the vendor states this explicitly. Samba running purely as a file or print server does not present this particular surface either, so the practical question for defenders is which of their Samba hosts are domain controllers answering DNS.
In deployment terms, an affected asset is usually a Linux host doing several jobs at once. Samba AD is a common choice where a full Windows domain controller is not warranted or not affordable: distributed sites, manufacturing and facilities networks, remote branches, hosting and managed service environments, lab and test domains. One host provides authentication, file and print services, and DNS, listening on UDP/53 and TCP/53 alongside everything else. That consolidation is what makes a DNS crash consequential rather than cosmetic. When the DNS process on a domain controller goes down, name resolution and domain logon for everything that depends on it goes with it.
These hosts also tend to be overlooked. A domain controller is rarely meant to answer queries from the public internet, yet it ends up doing so through flat network designs, firewall rules that outlived their purpose, cloud-hosted domain controllers with permissive security groups, and infrastructure inherited through acquisition. Version data reinforces the pattern. Across the assets identified in this set, most Samba fingerprints resolved only to a major version, but where a specific release was identifiable, several pointed to builds that are years behind current. Because the vulnerable code has been present since 4.0, age offers no protection here. Distribution maintainers have moved on this: Ubuntu shipped fixes in USN-8621-1 covering 22.04, 24.04, and 26.04, with older releases addressed through Pro ESM, and Debian published DSA-6401-1.
What does our data show about exposure patterns?
Among the assets in this set carrying an industry classification, exposure is led decisively by Utilities at 79.7% of observed assets, with Consumer Discretionary and Financials each contributing 9.4%.
The Utilities concentration fits the operational profile of the sector. Utilities run geographically distributed estates: generation sites, substations, district facilities, and control rooms that each need local authentication, file services, and name resolution, often without a local IT presence to manage a full Windows domain.
Samba AD is a natural fit for that shape of problem, and once it is deployed it tends to persist. Equipment lifecycles in the sector are measured in decades rather than refresh cycles, holding-company and acquisition structures leave networks stitched together from multiple inherited designs, and change control on anything adjacent to operational technology is deliberately slow. Each of those characteristics extends the window during which a service stays reachable and unpatched.
The broader pattern across sectors points less at Samba itself and more at what happens to infrastructure that works. A domain controller providing DNS is not the kind of asset that gets revisited: it was configured once, it resolves names correctly, and nothing in day-to-day operations prompts anyone to ask whether it is answering from public address space.
Exposure of this kind accumulates quietly, through perimeter rules that were correct when written and network topologies that changed around a host nobody reassessed. The vulnerability is what makes it urgent. The visibility gap is what made it possible.
Are fixes available?
Yes. The Samba Team released 4.24.5, 4.23.10, and 4.22.11 on July 28, 2026, correcting this issue along with five others across all active maintenance branches. Administrators running a supported upstream branch should move to one of those releases.
Because Samba is packaged downstream by many distributions, availability does not land everywhere at the same moment. Ubuntu addressed the issue in USN-8621-1, with fixed packages for 26.04, 24.04, and 22.04 and coverage for older releases through Pro ESM. Debian published DSA-6401-1, and Slackware issued SSA:2026-209-03 with Samba 4.22.11 and 4.24.5. A fixed upstream release is not the same thing as a fixed package on every platform in an estate.
There is one meaningful architectural note. The vendor confirms that the BIND9 DLZ backend is not affected, which gives organizations that already run that configuration a documented reason to deprioritize. For everyone else, patch status should be confirmed directly with the relevant vendor or distribution rather than inferred from the upstream release date.
Are there any other recommended actions to take?
Recommended mitigations:
- Identify which Samba domain controllers run the internal DNS server
- Restrict
UDP/53andTCP/53on domain controllers to trusted networks - Review which domain controllers answer DNS queries from public address space
- Monitor Samba DNS process logs for unexpected restarts or crash loops
- Evaluate the BIND9 DLZ backend, which the vendor lists as unaffected
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-6949 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
