DMIT August 26 Network Security Bulletin

1. Timeline

26 August 2026, 16:00–18:00 Eastern Time An off-peak window. During this period DMIT detected traffic with an unusual signature: modest in volume, but identical to the later abuse traffic in request construction and destination path. We assess this as reconnaissance traffic, meaning the attackers were verifying and cataloguing usable egress points ahead of the main operation.

27 August 2026, 03:00-04:00 Eastern Time Abnormal traffic growth appeared at our network edge, peaking at close to 100 Gbps within a short window. Investigation confirmed the traffic was not a DDoS attack but originated from a class of SNI proxy application deployed on customer virtual machines.

26 August to present DMIT has issued two email notices on this matter and powered off instances confirmed to be operating as open proxies. Both notices included remediation instructions and ticket support. A significant number of instances nonetheless resumed operation with no remediation, leaving the defect intact, and have since been exploited again by third parties.

The interval between the off-peak probing and the subsequent peak exploitation is the most notable feature of this incident. It indicates the attackers did not scan and immediately saturate. They completed an inventory of available egress points first, then launched in a coordinated fashion.

2. The defect

These applications fail to validate request origin and destination when handling SNI forwarding. The result is that any third party on the internet, holding no credentials for the instance whatsoever, can force the customer's virtual machine to proxy access to Cloudflare and the OpenAI resources behind it.

An instance running this software is, in effect, an open anonymous AI request egress available to the entire internet.

3. How the defect was verified

DMIT discloses its verification method in full:

If a customer's virtual machine can be exploited by any third party, DMIT can exploit the same defect to detect it. We performed connectivity verification along the same path an attacker would use, in order to confirm the defect is genuinely exploitable rather than inferring it from port signatures or traffic patterns.

This also defines our standard of assessment. We are not determining whether a customer runs a particular piece of software. We are determining whether the instance can, at this moment, be used by any third party as an anonymous egress. Whether you use it yourself and whether the port is open to the entire internet are two separate questions.

The probing was used solely to establish whether the defect exists. It did not involve reading or retaining customer data.

4. Why DMIT must act

4.1 Primary reason: the abuse shows clear signs of organization

DMIT assesses that this exploitation is not scattered opportunistic probing but organized abuse of AI resources. Plausible forms include third-party AI relay services, resale of API access, and bulk data collection for model distillation.

Two observations support this.

First, the attackers are able to generate correctly formed OpenAI requests, at volume, that continuously return large payloads. This indicates they likely hold batches of "legitimate" API credentials or some other means of producing valid requests. Simple scanning does not produce this signature.

Second, the off-peak reconnaissance traffic described above. Probe first, then exploit in concentrated fashion, is the behaviour of an actor with planning and resource coordination. It differs fundamentally from opportunistic abuse.

The scale of the traffic, the quality of request construction, its sustained nature, and the preparatory phase all point to the same conclusion: customer instances are being used as the anonymous egress layer of an industrial-scale data extraction chain.

4.2 Reputation risk to IP and ASN resources

If AI service providers begin flagging DMIT IP ranges and our ASN as malicious proxies or abuse sources, the consequences fall on every customer: address ranges enter risk-control lists, legitimate business requests get blocked, and the value of our optimized routes degrades. Reversing such classifications takes months, and is often not fully recoverable.

DMIT must therefore proactively remove resources that have been maliciously used, and resources that can be maliciously used, rather than waiting for external parties to make that determination on our behalf.

4.3 Inaction may be construed as facilitation

Having issued two notices, and being fully aware of both the defect and the nature of the traffic, continuing to permit these instances to operate constitutes, in practical terms, providing facilitation for a third party's activity.

A determination that DMIT "assisted third parties in distilling OpenAI models" would be clearly adverse to DMIT, and to every customer legitimately using AI API services on our platform. We will not allow a small number of unremediated instances to place the entire customer base's business continuity at that risk.

4.4 Secondary reason: edge capacity and platform-wide service quality

DMIT customer virtual machines are generally provisioned with 2 to 10 Gbps ports. Close to a thousand instances running concurrently at line rate is sufficient to exhaust edge capacity and degrade network quality for every customer on the platform.

We state this plainly: even absent any intervention, affected instances would typically exhaust their traffic allowance within one to two hours and be automatically rate-limited or suspended for overage. DMIT's billing revenue is unaffected either way. For the customer, however, having their traffic allowance consumed at no cost by an unknown third party is an obvious harm. We list this as a secondary reason because, while direct, it is self-resolving. The three reasons above are not.

5. Next steps

For instances that remain unremediated after two notices, DMIT will proceed with measures including service suspension, service termination, and cost recovery.

The specific measures, the basis on which they are applied, and the conditions for restoration will be communicated separately to affected customers in a third email notice. This bulletin does not constitute an enforcement decision against any individual account.

6. This is an industry-wide problem

The root cause is a common defect in customer-side software. The community has identified the same problem across many providers on the internet. To our knowledge, other data centers may not yet have seen exploitation at the scale DMIT experienced on 26 August. That does not mean their platforms are free of such instances; more likely they have simply not been selected as targets.

We are publishing this bulletin for two reasons: so that customers understand fully what happened on their own instances, and in the hope that the information is useful to our peers and to the wider community.

DMIT reserves the right to update this bulletin as the investigation develops. For questions regarding its contents, please contact us through the ticket system.