Yandex Outage Shows Malicious Bots Can Migrate Between Cloud Providers
Cloudflare’s analysis of the October 2026 Yandex outage found that search crawling declined and attack-like traffic temporarily fell, but high-volume bot activity targeting a gambling service quickly shifted to other Russian hosting providers.
Xcademia Team

Yandex Outage Shows Malicious Bots Can Migrate Between Cloud Providers
The October 2026 disruption to Yandex infrastructure reduced traffic across its search and cloud networks, but Cloudflare’s analysis found little evidence that the outage caused a lasting interruption to malicious automated activity. Instead, the data showed that some high-volume bot operations moved to alternative hosting providers after Yandex.Cloud became unavailable.
In a report published on October 15, Cloudflare examined traffic associated with two Yandex autonomous system numbers (ASNs): AS13238, which supports Yandex Search, and AS200350, which operates Yandex.Cloud services. The analysis used Cloudflare Radar and Bot Management data to distinguish routine search crawling from other forms of automation, including vulnerability scanning and suspicious probing.
The findings challenge claims that reported strikes on Yandex data centers had knocked Russian bot farms and online influence operations offline. Cloudflare found no evidence in its network data of an associated global disruption to malicious activity or social media manipulation. However, the company cautioned that its analysis could not conclusively establish whether the strikes had no connection to activity outside the data it observed.
What Happened During the Yandex Outage?
According to Cloudflare, reported Ukrainian drone strikes hit three Yandex facilities in Russia between October 7 and October 11, 2026. The disruptions progressively reduced the available capacity of Yandex networks.
On October 11, traffic fell to 99% below its baseline for Yandex Search (AS13238) and 90% below baseline for Yandex.Cloud (AS200350). Although traffic partially recovered, both networks remained significantly disrupted through October 13, with traffic still around 86% to 90% below normal baselines.
Cloudflare reported that, as of October 14 at 18:00 UTC, traffic was at 85% of normal.
However, a sharp decline in network traffic does not automatically indicate that malicious automation has stopped. To assess the impact, Cloudflare compared traffic patterns before and during the event, examined the types of requests being sent, and tracked whether similar activity appeared through other networks.

Why the Two Yandex Networks Behaved Differently
Although both networks experienced major traffic declines, they served different purposes and carried different types of automated requests.
Yandex Search: Search Crawling Declined
Yandex Search’s ASN, AS13238, primarily carried requests associated with search indexing. Cloudflare classified 99.5% of its observed requests as automated, and 93.6% of its bot requests as verified.
In sampled traffic, 78.1% of requests belonged to verified YandexBot, 11.5% to YandexRenderResourcesBot, and 1.9% to YandexImages. These crawlers fetch web pages, rendering resources, and images to support search-related functions.
The disruption therefore reduced search crawling rather than demonstrating a broad shutdown of malicious bots.
The effects were visible across websites that rely on search discovery. Publishing and newspaper sites experienced a 44% decline in traffic from Yandex networks. Before the event, approximately 90% of traffic from the Yandex Search ASN to news sites consisted of YandexBot indexing articles.
Cloudflare also reported that 40.5% of its customers returned HTTP 403 Forbidden responses to this crawler, indicating that those sites blocked its requests. When the Yandex Search network went offline, websites consequently saw less indexing activity from Yandex.
Yandex.Cloud: A Different Mix of Automated Traffic
Yandex.Cloud, operating under AS200350, showed a different pattern. Approximately 95% of its scored requests were classified as bots, but none of the observed bot requests were verified by Cloudflare.
The requests also looked different from typical search crawler traffic. Nearly two-thirds sent data to websites, and some identified themselves as software written in JavaScript, Python, or Go. A larger share of requests went to software companies than was seen in Yandex Search traffic.
These characteristics do not, on their own, establish that every request was malicious. Cloud hosting can support legitimate applications as well as automated activity that probes websites or attempts to exploit vulnerabilities.
After the reported strikes, bot traffic from Yandex.Cloud fell by approximately 40%. Cloudflare also observed a 90% decline in WordPress plugin probing and a 93% decline in requests identified as scanning activity. Customer blocks against traffic from Yandex.Cloud fell by 70% during the event period.
Those changes indicated a decline in attack-like traffic arriving through the affected network. They did not establish that the operators behind that traffic had stopped working.
Evidence That Some Malicious Automation Moved to Other Providers
Cloudflare’s strongest evidence of migration came from traffic targeting a gambling service.
Before the outage, nearly all bot requests in Yandex.Cloud’s gambling category targeted one customer account. Immediately after the October 8 disruption, requests from Yandex.Cloud to that account dropped to zero.
At the same time, requests with matching characteristics began appearing from other Russian hosting networks, including Radist and Selectel.
Cloudflare identified three similarities across the requests:
Matching JA4 TLS client fingerprints: A network-level fingerprint that can help identify similar TLS client behavior.
The same uncommon request paths and HTTP headers: Repeated request details consistent with a shared automation pattern.
Matching custom User-Agent strings: Client-identification text that appeared consistent across the different providers.
Together, these similarities supported Cloudflare’s assessment that the automation had moved between hosting networks rather than simply disappearing.
The broader request totals reinforced that interpretation. Russian bot traffic targeting gambling accounts remained essentially flat during the week, increasing from 167.7 million to 170.1 million requests, a rise of 1.4%.
The distinction is important: traffic from one provider can fall sharply while the same operation continues from another. Looking only at the source network would miss that change.

How the Outage Affected Other Industries
Cloudflare also compared Yandex.Cloud bot traffic across destination industries during the October 7-13 event period.
The reported changes varied considerably by sector:
Destination industry | Before event | During event | Change |
|---|---|---|---|
Computer software | 24.24 million | 15.18 million | -37.4% |
Gambling | 23.01 million | 18.80 million | -18.3% |
Media, including adult | 1.33 million | 223,100 | -83.3% |
Internet and telecom | 524,200 | 206,500 | -60.6% |
Travel and tourism | 363,900 | 158,100 | -56.6% |
Retail and wholesale | 316,000 | 167,700 | -46.9% |
Gaming and computer games | 226,300 | 63,200 | -72.1% |
Publishing and newspapers | 90,800 | 8,800 | -90.3% |
Source: Cloudflare. Figures compare observed bot traffic before the event with traffic during October 7-13, 2026.
Computer software and gambling accounted for most of the observed Yandex.Cloud bot traffic. Cloudflare noted that software-related requests included traffic to api.cloudflare.com, and a majority of this traffic returned successful HTTP 200 responses both before and during the event. This points to legitimate use of the cloud network alongside other forms of automation.
The gambling category provided a clearer example of suspicious automation continuing through alternative infrastructure. By contrast, changes in other industry categories show that the outage affected traffic unevenly. A decline in a destination category should not, by itself, be interpreted as evidence of malicious intent or of an operation being permanently stopped.

Did the Outage Disrupt Social Media Manipulation?
Cloudflare examined social media traffic to assess claims that the reported strikes had disrupted influence operations.
Across its observations, total traffic from Russian-origin IP addresses decreased by 0.6% during the event period, while global traffic increased by 1.2%. Cloudflare also examined bot traffic reaching the “post,” “reply,” and “like” endpoints of a specific social media platform.
For those endpoints, traffic from Russian-origin IP addresses decreased by 5.7%, while global traffic increased by 1.1%. Cloudflare did not identify an unexpected shift that would support claims that the outage had crippled social media manipulation.
However, the scope of this conclusion matters. The analysis covered traffic visible to Cloudflare, not every platform, provider, or source of online activity. Cloudflare said additional data outside its network would be needed to conclusively establish whether the strikes had any connection to changes in social media manipulation.
The findings therefore do not prove that every influence operation continued unaffected. They show that Cloudflare's observed traffic did not support the broader claim that these operations had been knocked offline.
What the Data Shows About Automated Threats
Cloudflare’s analysis highlights two important differences between an infrastructure outage and the disruption of an operation.
First, the type of traffic matters. The steep decline in Yandex Search requests was largely explained by verified crawlers, while Yandex.Cloud carried a different mixture of application traffic and unverified automation. Treating both networks as a single source of “bot traffic” would obscure those differences.
Second, source infrastructure is not the same as operator identity. A hosting provider can carry both legitimate and suspicious requests. A drop in traffic from that provider does not establish who was responsible for the activity or whether the underlying operator has stopped.
For security teams, the practical implication is to examine request behavior and patterns across networks rather than relying only on traffic volume or source IP ranges. Cloudflare highlighted several relevant signals, including shared JA4 fingerprints, unusual request rates, and activity against sensitive endpoints. Web application firewall rules can also help control suspicious requests regardless of which network they originate from.
These signals are most useful when evaluated together and in context. A fingerprint, User-Agent string, or unusual request path alone does not conclusively identify an actor.
Conclusion: Monitor Behavior, Not Just Infrastructure
The Yandex outage demonstrated how a major infrastructure disruption can sharply reduce traffic without necessarily ending the automated activity that depended on it.
Cloudflare found that the disruption primarily reduced search crawling on Yandex Search, while some attack-like traffic from Yandex.Cloud declined and high-volume automation targeting a gambling service appeared through alternative hosting providers. Its analysis did not support claims that the outage had broadly crippled social media manipulation, although the company acknowledged limits to what its network data could establish.
For defenders, the central lesson is that infrastructure-level changes should be treated as one signal, not a complete measure of threat activity. Tracking request behavior, comparing patterns across providers, and applying controls to sensitive endpoints can help security teams identify suspicious automation even when its hosting location changes.
Source: Cloudflare Blog
About the Author