Underminr Just Made Domain Fronting Work Again on 88 Million Domains—Researchers Showed Attackers Can Route Command and Control Traffic Through Trusted CDN Tenants Without Setting Off Any Protective DNS Filter

Key Takeaways

• Underminr is a domain fronting variant disclosed by ADAMnetworks on May 23, 2026 that exploits shared CDN infrastructure to hide command and control traffic behind trusted domains.
• Roughly 88 million domains—concentrated in the US, UK, and Canada—are potentially impacted because they sit on shared CDN edges where Underminr's SNI/Host mismatch trick succeeds.
• The endpoint observes an allowed DNS lookup; the TLS handshake presents an allowed Server Name Indication; the actual TCP connection terminates against a different tenant's IP on the same shared edge.
• ADAMnetworks describes four distinct methods to bypass Protective DNS (PDNS), the defense most enterprises built after the APT29 domain fronting campaigns of the late 2010s.
• "Once Underminr becomes parametric information for AI generated malware, we could expect to see it in every attack," ADAMnetworks CEO David Redekop told SecurityWeek.

What Is Underminr?

Underminr is a variant of domain fronting—the technique APT29, Iranian operators, and a long list of others used roughly a decade ago to hide command and control traffic behind major cloud providers. The original version worked by terminating a TLS connection to one domain on a CDN while specifying a different domain in the inner HTTP Host header. Cloudflare, AWS, Google Cloud, and Microsoft Azure all closed that gap during 2018 to 2020 by enforcing alignment between SNI and the HTTP request.

Underminr abuses a different layer. Shared CDN edges route requests to tenants based on a combination of SNI and tenant routing metadata. ADAMnetworks's research showed that an attacker controlling a tenant on the same edge as a trusted domain can craft TCP connections that present the trusted SNI in the outer TLS handshake but force the request to terminate against the attacker's IP through manipulation of the underlying routing decisions.

From the endpoint's perspective, every visible signal is benign: DNS resolves to an allowed hostname, the certificate is valid for that hostname, the network destination is a CDN IP. From the network's perspective, the egress traffic looks like any other call to a major CDN.

Why Does Protective DNS Miss It?

Protective DNS (PDNS) is the standard enterprise defense against domain fronting and command and control beaconing. It works by routing all corporate DNS resolution through a service that scores hostnames against threat intelligence and blocks lookups to known bad domains. The American CISA, the UK NCSC, and Canada's CSE have all formally endorsed PDNS as a baseline control over the past five years.

PDNS makes its decision at the DNS layer. The lookup arrives, the service decides allow or block, and the endpoint either gets an IP or gets a sinkhole. Underminr passes that decision cleanly: the hostname being looked up is on the allow list. The exploitation happens in the routing decision that the CDN makes after the connection is established, which PDNS never sees and has no way to evaluate.

ADAMnetworks describes four specific Protective DNS bypass variants in the disclosure. Each uses a different combination of SNI specification, HTTP Host header values, and CDN tenant routing parameters. The variants exist because different CDN platforms make routing decisions differently. Cloudflare, Fastly, Amazon CloudFront, and Microsoft Azure Front Door each have their own routing semantics, and Underminr finds a viable seam in each of the major ones.

Why Do 88 Million Domains Matter?

The 88 million figure is not an exploited count. It is the population of domains that sit on shared CDN edges where the routing seam exists. The number matters because it represents the universe of "trusted hosts" the attacker can pick from to mask command and control traffic. A defender's allow list of well known business domains—office.com, slack.com, github.com, every major SaaS platform, every news site, every CDN hosted JavaScript library—is the attacker's menu.

The concentration in the US, UK, and Canada reflects where CDN customer bases are densest, not where the technique is most useful. Geographically, Underminr works wherever a vulnerable CDN routes traffic. The geography matters in practice because the trusted domain a target endpoint will not block is one it already uses, and that is highly correlated with the country the target is in.

From the attacker's side, the practical workflow is: register a tenant on a shared edge, pick a high reputation trusted domain on the same edge, configure the routing trick, and channel command and control traffic through the resulting tunnel. The mechanics are straightforward enough that Redekop's worry about AI generated malware is plausible. A language model that can read the ADAMnetworks paper can generate the malware loader code without further human input.

What Do CDN Operators Need to Do?

The mitigation has to live at the CDN edge. Endpoints and protective DNS services cannot see the routing decision; they can only see DNS and the outer handshake. CDN operators need to tighten the correlation between DNS resolution, SNI, the inner HTTP Host header, and the tenant the request actually reaches. That is essentially the same fix the post APT29 era applied, extended one layer down.

ADAMnetworks's disclosure is coordinated with several major CDN providers, but the response varies. Some operators have shipped tenant isolation patches; others treat shared edge multi tenancy as a feature and are weighing how aggressively to enforce alignment. Until that work is uniformly complete, the exposure persists across the same 88 million domains.

There is no individual user action that helps here. Browsers cannot see the routing decision either, and the certificate validation succeeds because the trusted domain genuinely sits on the same edge. The defense has to be infrastructural.

How Does Underminr Compare to the Old Domain Fronting Era?

The original domain fronting era ended for two reasons: the major CDNs closed the technical gap, and Google in particular publicly disabled the ability for Tor and Signal projects to use Google App Engine as a fronting host. The deprecation removed a legitimate cover from a class of privacy preserving applications and forced the malicious users into other paths.

Underminr re opens the door for the malicious users without re opening it for the legitimate ones. The technique requires controlling a tenant on the shared edge—something a legitimate privacy preserving service is unlikely to do at scale, but that a small criminal operator can manage trivially. The asymmetry is unfortunate. The privacy preserving use cases are still gone. The attacker use cases are back.

The broader implication, echoed in the recent Verizon 2026 DBIR finding that exploited vulnerabilities have nearly caught credentials as the top breach vector, is that defenders are losing infrastructural ground. A defense built in 2019 against APT29 is no longer enough in 2026. The next eighteen months of CDN engineering work will decide whether Underminr stays a published research result or becomes the default command and control channel.