"Underminr": a multi-tenant-CDN domain-fronting variant that blinds DNS-layer filtering
ADAMnetworks disclosed Underminr, a structural evolution of domain fronting that abuses the shared-IP, multi-tenant architecture of modern CDN edges rather than a single-CDN misconfiguration (ADAMnetworks, 2026-05-21). Classic domain fronting — overriding the HTTP Host header behind a permitted SNI — was largely closed by the major CDNs in 2021–2022 by enforcing SNI/Host consistency. Underminr instead presents the SNI and HTTP Host of a legitimate, allow-listed domain hosted on a shared edge while forcing the request to the IP of a different tenant — the attacker's origin — on the same edge, exploiting the fact that the CDN's internal tenant routing is decoupled from the network-visible Host/SNI (SecurityWeek, 2026-05-23). As SecurityWeek frames it, "the detection gap appears when DNS decisions, edge IPs, SNI, Host headers, and CDN tenant routing are not correlated." No CVE was assigned — this is an architectural property of shared-edge multi-tenancy, not a software bug. SecurityWeek reports roughly 88 million domains on shared infrastructure are potentially in scope, with US, UK and Canadian infrastructure most affected; the technique does not require compromising the legitimate domain, only co-tenancy on the same edge IP range.
Why it matters to us: this maps to ATT&CK T1090.004 (Proxy: Domain Fronting) and is squarely a C2 / exfiltration-evasion concern for the many CH/EU public-sector networks whose egress control leans on DNS-layer filtering (DNS RPZ, recursive-resolver allow-lists) or that treat a CDN's published IP range as a proxy for the actual destination — both of which Underminr defeats, because the FQDN legitimately resolves to the shared edge IP and edge-terminated TLS inspection never sees the origin-routing decision. Defenders should stop treating DNS/domain allow-listing as a sufficient egress control on its own; correlate SNI, Host, the resolved edge IP and (where available) CDN tenant identity per flow, and prefer per-flow identity verification (ZTNA) over perimeter-DNS-filter trust. Specific vulnerable CDN providers are not named in the public reporting.
ATT&CK mapping
2 techniques mapped from the cited reporting · MITRE ATT&CK v19.2
Command and Control TA0011
T1090Proxy
Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. Many tools exist that enable traffic redirection through proxies or port redirection, including HTRAN, ZXProxy, and ZXPortMap. Adversaries use these types of proxies to manage command and control communications, reduce the number of simultaneous outbound network connections, provide resiliency in the face of connection loss, or to ride over existing trusted communications paths between victims to avoid suspicion. Adversaries may chain together multiple proxies to further disguise the source of malicious traffic.
T1090.004Proxy: Domain Fronting
Adversaries may take advantage of routing schemes in Content Delivery Networks (CDNs) and other services which host multiple domains to obfuscate the intended destination of HTTPS traffic or traffic tunneled through HTTPS. Domain fronting involves using different domain names in the SNI field of the TLS header and the Host field of the HTTP header. If both domains are served from the same CDN, then the CDN may route to the address specified in the HTTP header after unwrapping the TLS header. A variation of the the technique, "domainless" fronting, utilizes a SNI field that is left blank; this may allow the fronting to work even when the CDN attempts to validate that the SNI and HTTP Host fields match (if the blank SNI fields are ignored).
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.