Summary

  • Most of the lost Yandex Search traffic was verified crawling, not an attack disappearing. The cloud-hosting network carried a mixture of ordinary applications and suspicious automation.
  • At one gambling customer account, matching requests reappeared through other Russian hosts after the Yandex.Cloud stream stopped. That supports continuity of the observed activity, not identification of its operator or a verdict on the whole Internet.

A publisher wants a search crawler to find its articles and a vulnerability scanner to leave its software alone. An outage can remove both visitors from its logs. A lower bot count, by itself, does not say which outcome the site has gained—or lost.

Cloudflare's 14 October account of the Yandex disruption gives this distinction a concrete twist. Search crawlers stopped arriving in large numbers. But at one gambling-sector customer, the suspicious requests did not simply go away: after the Yandex.Cloud stream stopped on 8 October, requests with matching traits appeared through other Russian hosts, including Radist and Selectel.

The old source had gone quiet; the customer was still receiving something it recognised. That leaves a website with two practical questions: is useful search traffic returning, and is the unwanted activity actually declining? The same downward curve cannot answer both.

The useful bots disappeared too

Yandex's 9 October statement described serious damage and a shutdown in Sasovo after a drone attack overnight on 7–8 October, followed by damage to part of its Kaluga infrastructure on the 9th. An 11 October update added a stopped facility in Vladimir. These are the company's accounts of its facilities; they do not identify the operators of everything hosted on its networks.

Cloudflare separated the network serving Yandex's search engine from the one hosting cloud customers. Network numbers, known as ASNs, make that separation possible: AS13238 belongs to the search side of this comparison, AS200350 to the cloud side. They tell an observer which network delivered a request, not who wrote or ran each customer's program.

The search network was largely doing useful search work. About 90% of its pre-outage traffic to news sites was YandexBot indexing articles. Losing those visits reduces the crawler's opportunities to discover content for Yandex Search.

Cloudflare's classification helps explain that finding. It calls a bot verified when it meets its requirements for honest self-identification and non-abusive behavior. Of the requests observed from the search network, 99.5% were automated; of those bot requests, 93.6% were verified. The sample included YandexBot, YandexRenderResourcesBot and YandexImages, doing work consistent with fetching articles, rendering pages and processing images for search.

The scale of the interruption was substantial. On 11 October, search traffic was 99% below its baseline and cloud traffic 90% below. Both remained 86–90% below normal on the 13th. The report's later observation, at 18:00 UTC on the 14th, put traffic at 85% of normal. These are dated measurements from Cloudflare's view, not a current service-status guarantee.

A cloud address is a shared address

The cloud network was harder to read. Roughly 95% of its scored requests were bots, and none of the observed bot requests had Cloudflare's verified status. But verification is a specific classification, not a dividing line between every legitimate program and every hostile one.

Almost two-thirds of the cloud requests sent data to websites. Software applications and integrations featured prominently; most of the software-sector requests returned HTTP 200 before and during the event. A successful response does not certify good intent, but it helps explain why this was not simply a network full of attackers. Ordinary customer software was there too.

Suspicious activity did fall. Cloudflare reported about 40% less bot traffic from AS200350, 90% less WordPress-plugin probing and 93% fewer scanner-identified requests. Customer blocks of Yandex.Cloud traffic fell 70%. These measure different things. Fewer requests arriving from a particular host, and fewer blocks applied to them, do not by themselves establish that the underlying operation ended.

The gambling account provides the more discriminating test. Nearly all the Yandex.Cloud bot requests in that destination sector had targeted this account across its hostnames. When its old source disappeared, the incoming requests through other hosts retained the same JA4 TLS fingerprint—a characteristic of how the client makes its encrypted connection—as well as uncommon paths and headers and custom User-Agent strings.

Several matching traits at the same destination make Cloudflare's migration interpretation more persuasive than a resemblance between two big traffic curves. They still do not provide a person's identity. Nothing here establishes that Yandex operated the requests, that all bots moved, or that the same pattern held at sites outside Cloudflare.

One account is not a national total

A broader number sits beside that case, not inside it. Russian bot requests to gambling accounts in Cloudflare's sample rose from 167.7 million before the event to 170.1 million during it, or 1.4%. Those are sector-wide observations across the sampled accounts, not the request count for the single customer just described.

The report's dated table also puts automated traffic at 39.4% of worldwide HTTP requests observed by Cloudflare on 1–6 October, and 39.5% on both the 11th and 13th. Within Russia-origin HTTP requests, the corresponding shares were 50.4%, 42.2% and 42.1%. These are proportions of requests, not counts of people or bot operators. A broadly unchanged global proportion can coexist with a regional decline and a busy customer account.

Cloudflare Radar provides the traffic-measurement context; it does not turn the company's customer-level evidence into a census of the Internet. Cloudflare says its observations did not support claims that the disruption crippled social-media manipulation, while acknowledging that data outside its network would be needed to settle a wider connection.

Lu Heng's Note 65 on running-code primacy offers an editorial analogy: operational evidence should carry more weight than a label. It discusses Internet-number governance, not this outage, and supplies no incident evidence. Here the practical distinction is narrower. A hosting name tells us where a request came from. What it did, and whether it kept arriving, can tell the customer considerably more.