# Underminr: How Attackers Hide Malicious Traffic Behind Trusted Domains Using Shared CDN Infrastructure


## The Threat


A newly discovered vulnerability dubbed Underminr is allowing threat actors to hide malicious command-and-control traffic and other unauthorized connections behind legitimate, trusted domains—bypassing DNS-based security controls that organizations rely on to detect and block threats.


Underminr exploits a fundamental weakness in how shared content delivery network (CDN) infrastructure routes traffic. Rather than using the traditional domain fronting technique (which most CDNs have already mitigated), attackers using Underminr force requests to reach an unintended destination by creating a mismatch between the domain specified in DNS lookups and TLS handshakes versus the actual IP address the connection reaches. The request appears to originate from and connect to an allowed, trusted domain—fooling both network monitoring tools and endpoint security systems—while the traffic actually routes to an attacker-controlled resource on another tenant's infrastructure within the same shared CDN edge.


According to research firm ADAMnetworks, this technique is particularly effective because the attack leverages infrastructure that organizations have explicitly whitelisted. When DNS filtering services (known as Protective DNS or PDNS) see a request for a trusted domain, they allow it. The endpoint sees the allowed DNS response. But because the attacker controls the actual destination IP address through CDN routing, the connection completes to a different hosted infrastructure entirely. The result: attackers gain a covert channel that bypasses egress policies, DNS filtering, and network detection tools all at once.


Underminr can be weaponized in multiple ways: attackers can hide connections to command-and-control servers, establish covert VPN or proxy tunnels to maintain persistence, and incorporate the technique into ClickFix attacks. Most concerning, approximately 88 million domains are potentially vulnerable, with internet infrastructure in the US, UK, and Canada facing the highest exposure.


## Severity and Impact


| Attribute | Details |

|-----------|---------|

| Vulnerability Name | Underminr (Domain Fronting Variant) |

| CVE ID | Not publicly assigned |

| CVSS Score | Not yet scored; high-severity evasion technique |

| Attack Vector | Network (HTTPS/TLS on port 443) |

| Attack Complexity | Low—requires standard HTTPS requests; no special tools initially required |

| Authentication Required | None |

| User Interaction | None |

| Impact Scope | Confidentiality, Integrity (attackers bypass detection and filtering) |

| Domains Affected | ~88 million (shared CDN infrastructure) |

| Researcher | ADAMnetworks |

| Publication Date | May 23, 2026 |


## Affected Products


Underminr impacts any organization relying on shared CDN infrastructure, including:


  • Large-scale hosting providers (AWS, Azure, Google Cloud, Akamai, Cloudflare, Fastly, Cloudflare, and similar platforms)
  • Organizations using Protective DNS (PDNS) filtering services that do not correlate DNS decisions with actual TLS destinations
  • Endpoints running DNS filtering tools that validate domain names without confirming endpoint routing integrity
  • Networks implementing egress filtering that rely solely on DNS-level or SNI-level controls
  • Any domain or application hosted on shared edge infrastructure where multiple tenants share the same IP space

    • The vulnerability is not tied to a single vendor or product—it affects the architectural assumptions underlying how modern CDNs route traffic and how security tools validate domain ownership.


    ## Mitigations


    For organizations using Protective DNS or DNS filtering services:


  • Correlate multiple signals: Ensure your PDNS solution correlates DNS lookups, edge IPs, SNI fields, Host headers, and actual CDN tenant routing. A request should only be allowed if ALL these signals point to the same trusted domain.
  • Implement TLS inspection: Deploy network monitoring that validates the actual destination certificate and hostname matches the DNS response, not just the SNI.
  • Monitor for mismatches: Log and alert whenever DNS, SNI, Host header, or routing destination signals diverge—this is a strong indicator of Underminr exploitation.

    • For network and security teams:


  • Layer egress controls: Do not rely solely on DNS or SNI filtering. Implement additional controls at the HTTP Host header level, certificate pinning for critical services, and behavior-based detection.
  • Review CDN provider policies: Contact your CDN provider to understand their mitigations against domain fronting and tenant isolation controls. Verify that multi-tenant routing cannot be abused.
  • Deploy endpoint detection and response (EDR): While Underminr bypasses network DNS filtering, EDR tools can detect suspicious outbound connections and process behavior that indicates C&C communication.
  • Update firewall and proxy rules: Ensure proxies and firewalls validate the full request chain—not just DNS and SNI—before allowing egress.

    • For CDN providers and infrastructure teams:


  • Strengthen tenant isolation: Ensure that shared edge infrastructure cannot be exploited to route traffic between tenants without explicit configuration.
  • Implement request validation: Add server-side checks that validate the requested hostname matches the actual destination before routing.

    • ## References


  • ADAMnetworks Research: [Underminr Domain Fronting Vulnerability Research](https://adamnetworks.com/) (original researchers and disclosure)
  • SecurityWeek Coverage: "Underminr Vulnerability Lets Attackers Hide Malicious Connections" by Ionut Arghire
  • NIST DNS Security Guidelines: https://csrc.nist.gov/publications/detail/sp/800-81/rev-2/final
  • SANS DNS Security: https://www.sans.org/reading-room/dns-security

    • ---


    ## HackWire Analysis


    Underminr arrives at a critical inflection point: organizations have spent years hardening DNS filtering as a foundational defensive layer. PDNS services are ubiquitous now—firewalls check them, endpoints phone home to them, security teams rely on them as a first-line filter. The assumption has been that if DNS blocking is working and SNI inspection is in place, you're protected. Underminr shatters that assumption.


    The vulnerability's elegance is also its danger: it doesn't require zero-days, malware sophistication, or social engineering. It requires only that the attacker understand the CDN's internal routing logic—something network researchers have documented for years. This is particularly problematic given David Redekop's (ADAMnetworks CEO) warning that once this technique becomes parametrized into AI-generated malware, it will become standard in attack chains. We're likely months away from seeing automated tools that incorporate Underminr bypasses alongside credential theft, lateral movement, and data exfiltration.


    The 88 million affected domains statistic is deceptive in scope—it's not that all 88 million will be exploited, but that attackers can choose from a massive pool of legitimate CDN-hosted domains to hide behind. That asymmetry is what defenders must grapple with. A single organization cannot whitelist 88 million domains, nor should they. The real mitigation is architectural: organizations need to stop trusting DNS and SNI as sufficient proof of destination legitimacy and begin correlating all signals in the request chain.


    The most immediate risk is to organizations with existing malware that uses DNS filtering evasion as part of its command infrastructure. That malware will be updated within weeks to leverage Underminr, instantly making their network detection evasion more effective. Second-order risk: insider threats, supply chain attackers, and advanced persistent threats will use this technique to maintain covert channels that pass through security controls.


    What defenders should do immediately: If your organization relies on PDNS filtering as a primary control (which many do), audit your monitoring to ensure you're logging the actual destination of HTTPS connections, not just DNS queries and SNI. If there's a mismatch, you've found an attacker. Second, contact your CDN provider directly and ask what controls prevent multi-tenant routing abuse. If they can't explain it clearly, escalate. — *HackWire Editorial*


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)