What is known#
SecurityWeek reports on a technique called Underminr, described by ADAMnetworks as a vulnerability in shared CDN infrastructure that can let attackers hide malicious connections behind domains that appear trusted.
The issue sits near a familiar seam: the gap between what a network thinks a connection is doing and where that connection actually lands inside shared internet infrastructure.
The older pattern is domain fronting. In that model, an attacker places an allowed domain in visible TLS fields such as SNI and certificate validation, while a different destination is carried deeper inside the encrypted HTTP layer. CDN routing then uses the internal host header to send the request to the hidden destination. To many monitoring systems, the traffic appears to be going to the reputable front domain.
Underminr is described as different. Instead of relying on a front domain in the classic way, it presents the SNI and HTTP Host of one domain while forcing the request to the IP address of another tenant on the same shared CDN edge. The result is still a trust mismatch. The visible indicators can look acceptable, while the actual connection can reach a different hosted name.
ADAMnetworks says this has been exploited against large-scale hosting providers, including providers that already applied mitigations against domain fronting.
That detail matters. If accurate, it means defenders cannot treat old domain-fronting controls as a full answer. The routing layer changed. The blind spot moved.
Why shared CDN infrastructure creates the opening#
CDNs and large hosting platforms are built for scale. Many domains can share the same edge infrastructure. That design improves performance and resilience, but it also means network policy cannot always treat one IP address as one clear destination.
In simple filtering models, defenders often rely on DNS lookups, IP reputation, SNI, hostnames, or allowlists. Each signal can be useful. None of them is complete by itself.
Underminr appears to abuse the places where those signals are checked separately.
ADAMnetworks describes the detection gap this way: DNS decisions, edge IPs, SNI, Host headers, and CDN tenant routing are not always correlated. An endpoint may show an allowed DNS lookup. The connection may still complete against another hosted name.
That is the core issue. A policy engine may approve what it sees at one layer. The CDN may route based on another layer. The attacker benefits from the difference.
SecurityWeek says the technique has been observed mostly over TCP port 443, where SNI exposes the intended TLS hostname. That does not make the activity easy to interpret. Port 443 is the normal path for web traffic, SaaS platforms, VPNs, proxies, and malware command-and-control traffic. The signal is noisy by design.
What attackers can do with it#
According to the report, threat actors can use Underminr to hide connections to command-and-control servers. They can also use it for VPN and proxy connections and to work around network egress controls.
That last point is the practical one for enterprise defenders. Egress filtering is supposed to restrict where systems can connect. Protective DNS and domain allowlists are often part of that control. If a malicious connection can appear tied to an allowed domain while reaching another tenant on shared infrastructure, the control loses precision.
SecurityWeek says ADAMnetworks identified four strategies for using Underminr to bypass Protective DNS monitoring and filtering. The source summary does not provide implementation detail for each strategy, and that should not be invented. The safe conclusion is narrower: ADAMnetworks claims there are multiple workable paths, not one edge case.
The report also says real-world use can involve malicious applications and shell scripts. ADAMnetworks says the technique can also be abused in ClickFix attacks.
ClickFix matters because it lowers the entry point. These attacks often trick users into running commands or scripts under the promise of fixing an issue, passing a CAPTCHA, or resolving an access problem. If the resulting script can use a CDN routing mismatch to reach hidden infrastructure, the network may see traffic that looks less suspicious than it is.
The scale claim needs care#
ADAMnetworks estimates that approximately 88 million domains are potentially affected by Underminr. SecurityWeek also reports that internet infrastructure in the US, the UK, and Canada is most impacted.
Those are large numbers, but “potentially affected” should not be read as “actively exploited” or “all vulnerable in the same way.” Shared hosting and CDN exposure is broad. Actual exploitability depends on provider behavior, routing logic, tenant placement, monitoring controls, and how the attacker constructs the connection.
The source also quotes ADAMnetworks CEO David Redekop warning that AI-generated malware could increase use of the technique once it becomes parametric information in attacker tooling. That is plausible as a risk forecast, but it remains a forecast. The more grounded concern is simpler: once a bypass pattern is documented and repeatable, commodity tooling tends to absorb it.
Defenders should avoid two bad readings.
First, do not dismiss this as a branding exercise around domain fronting. The reported mechanics are different enough to affect detection assumptions.
Second, do not treat the 88 million figure as proof that every organization is immediately exposed. The useful question is whether your controls correlate the relevant layers or approve them independently.
What defenders should check#
The immediate work is not panic. It is validation.
Teams that rely on Protective DNS, domain allowlists, or simple SNI-based policy should review whether their stack correlates DNS resolution, destination IP, SNI, HTTP Host, certificate data, and CDN routing context where available.
Practical checks:
- Review outbound connections to shared CDN and hosting infrastructure, especially port 443 flows that pair allowed DNS activity with unusual destination IP behavior.
- Test whether egress controls validate only the requested domain or also the effective destination path.
- Look for scripts or applications that establish outbound TLS connections while bypassing normal browser or proxy paths.
- Revisit ClickFix detections. User-executed shell commands remain a high-value telemetry point.
- Ask security vendors and CDN providers how they handle SNI, Host header, DNS, and tenant-routing mismatches.
For organizations in heavily restricted environments, the key question is whether “allowed domain” means “allowed tenant and route,” or merely “a name that appeared in one visible field.” Those are not the same control.
The larger lesson#
Underminr is another reminder that trust decisions made at one layer can break at another.
Shared CDN infrastructure is not inherently unsafe. It is part of how the modern web works. The risk appears when security tools flatten that complexity into a single allow/deny signal.
A connection can have a clean-looking DNS lookup. It can use a common edge IP. It can expose an expected SNI value. It can still be routed in a way the policy engine did not model.
That is the seam attackers want.
The defensive answer is not to block CDNs broadly. That would break too much of the internet. The better answer is tighter correlation, better egress visibility, and fewer assumptions that a trusted-looking domain proves the final destination is trusted.