Incident Report: May 13, 2026

Good afternoon,

We have prepared a detailed report on the DDoS attack against the infrastructure of our regional partner, which affected the availability of our customers’ infrastructure in the Almaty, Tashkent, and Nairobi regions. The incident started on May 13 at 11:20 and was moved to monitoring status on May 14 at 18:11. All times below are indicated in the GMT+3 time zone (Moscow).

TL;DR

On May 13, the network of our regional partner in Almaty, Tashkent, and Nairobi was hit by a large-scale UDP flood carpet DDoS attack at L3/L4, with peak traffic reaching up to 250 Gbps. The total duration of the incident was 30 hours and 51 minutes: 9 hours and 27 minutes of degraded network availability, followed by more than 21 hours until full recovery.

To protect customer infrastructure and data, the partner temporarily suspended external BGP announcements while preserving local connectivity. To mitigate the attack, traffic was redirected to external DDoS scrubbing centers: in Almaty and Nairobi, through established tunnels; in Tashkent, through a filtering system on the backbone provider’s side after additional tuning. To reduce the risk of similar incidents in the future, together with the partner we are already implementing permanent connectivity to several external DDoS mitigation providers with failover scenarios, automated BGP scenarios, preconfigured backup routes to scrubbing centers, and improvements to local DNS operation when external regional connectivity is unavailable.

What Happened

The regional partner’s network was hit by a carpet and multi-vector UDP flood DDoS attack at L3/L4. The attack was cascading: it affected several regions at once. It was a carpet attack: malicious traffic was directed not at a single IP address, but at many addresses simultaneously. It was also multi-vector: the parameters of malicious traffic kept changing, which made detection and filtering more difficult.

Peak load on backbone links reached 100–250 Gbps. As a result, the standard DDoS protection system could not adapt fast enough to the changing attack profile, and the traffic volume started affecting not only local infrastructure but also upstream telecom networks.

Customer Impact

During the incident, customers may have experienced full or partial unavailability of resources from the external internet, unstable network connectivity, reduced access speeds, issues with DNS resolution, private networks between resources in different regions, and interconnects with internet providers.

We want to emphasize separately that customer data and infrastructure were not affected.

Our Actions to Protect the Infrastructure

The Selectel engineering team, together with the partner’s specialists, started diagnostics immediately after the first monitoring alerts appeared. Initial diagnostics took additional time because malicious traffic overloaded external links. To access some systems and coordinate the response, backup management channels had to be established.

Because the attack posed a threat not only to the local infrastructure but also to upstream telecom networks, BGP announcements to the external internet were temporarily suspended. This was a necessary decision: it reduced the load on telecom operators, protected the infrastructure, and preserved local connectivity inside the regions where technically possible.

After that, the joint technical team started organizing a backup traffic scrubbing scheme through external DDoS mitigation providers: testing tunnels, configuring routing, and redirecting traffic to external scrubbing centers.

Why Recovery Took Time

The main delays were caused by the scale of the attack, its carpet nature, and the need to coordinate with external telecom operators and DDoS mitigation providers. The attack targeted not one address or service, but a large number of IP addresses across all affected regions. Filtering individual directions or addresses therefore did not solve the problem.

To restore public availability, it was necessary to coordinate routing, bring up tunnels, verify traffic flow, and tune filtering for the actual attack profile. Recovery in Tashkent took longer because additional manual tuning of the protection system on the backbone provider’s side was required.

Recovery Work

Almaty and Nairobi

To scrub the traffic, the decision was made to route it through external DDoS scrubbing centers using tunnels. The first attempt was unsuccessful: the external provider was also unable to fully scrub the malicious traffic. After analyzing the situation, traffic was switched to another mitigation provider. This helped: the operator’s scrubbing system filtered the malicious traffic and allowed recovery to begin.

After the initial recovery, some customers may have experienced reduced speed and unstable performance. This was caused by routing changes, increased RTT, and additional traffic processing on the external scrubbing system. After bandwidth and routing settings were adjusted, the situation stabilized.

Tashkent

The automatic protection on the backbone provider’s side initially could not correctly detect and filter the attack. In close coordination with the provider, additional tuning of the protection system was performed. After the settings were optimized, the provider successfully filtered the attack at the cross-border node, which allowed network availability to be restored gradually.

Timeline of Key Events

• May 13, 11:20–12:25 — Detection and initial diagnostics
  Monitoring systems detected the first signs of network unavailability and abnormal load. The team started diagnostics. Because external links were overloaded, some actions were performed through backup management channels.

• May 13, 12:25–13:45 — Determining the scale of the attack
  The team confirmed that the attack affected several regions at once and a large number of the partner’s IP addresses. Coordination with backbone operators and DDoS mitigation providers began.

• May 13, 13:45–15:50 — Temporary withdrawal of external BGP announcements
  To protect the infrastructure, external connectivity was temporarily disabled. Local connectivity inside the regions was preserved where technically possible. DNS resolution issues also appeared during this period.

• May 13, 15:50–19:00 — Connecting external protection
  In Almaty, a tunnel was established to the first external scrubbing center. At this stage, the actual attack volume was confirmed at up to 200–250 Gbps. The initial filtering scheme did not fully filter the attack, so the team started switching to a backup mitigation provider. In Tashkent, backbone providers were manually configuring their protection system. In Nairobi, one upstream provider temporarily disabled the BGP session due to overload in its own network.

• May 13, 19:00–22:59 — Connecting the backup mitigation provider and partial recovery
  For Almaty and Nairobi, the backup DDoS mitigation provider was connected. In Tashkent, after manual tuning, the backbone provider started filtering the attack correctly. Availability and DNS resolution began to recover gradually.

• May 13, 22:59 — May 14, 01:39 — Resolving performance issues
  After connectivity was restored, some customers in Almaty and Nairobi observed reduced speed. The team identified and fixed a bandwidth configuration issue on the scrubbing system side and continued adjusting routing.

• May 14 — Stabilization and return to the normal scheme
  After the attack was no longer detected at significant volumes, the team started moving connectivity back to the normal scheme. Network access was restored, and performance returned to normal. On May 14 at 18:11, the incident was moved to monitoring status.

Measures We Will Take to Reduce the Risk of Recurrence

The Selectel engineering team, together with the partner’s specialists, has started working on changes to the network architecture and response processes.

Permanent External DDoS Protection

We will implement permanent connectivity to external DDoS mitigation providers for the affected regions. During an attack, this will allow all malicious traffic to be redirected to partner scrubbing centers in a semi-automated mode using a scheme that proved effective under real attack conditions.

Automatic Protection Activation

We will add automatic triggers for enabling DDoS protection when predefined thresholds for traffic, packet loss, and network availability are reached. This will reduce the time between the start of an attack and the start of filtering.

BGP Scenario Automation

We will prepare automated scenarios for managing BGP announcements. Their purpose is to quickly isolate the external perimeter while preserving local connectivity inside the region and through local internet exchange points where technically possible. This will help protect the infrastructure from overload faster and reduce dependency on manual switching during an incident.

Backup Tunnels and Routes

We will prepare backup routing schemes and tunnels to external mitigation providers in advance. For Tashkent, we will separately complete the technical and legal coordination of these schemes with local partners and in line with regulatory requirements, so that in an emergency we do not spend time on approvals during an active incident.

Local DNS Resilience

We will review the DNS resolution architecture in the regions so that, when external connectivity is lost, basic network functions remain operational and resources remain available to local users.

Drills and Response Playbooks

We will update internal response playbooks for large-scale L3/L4 attacks and run drills involving the network team, duty engineers, support, and external operators. Separate scenarios will cover carpet attacks against many IP addresses in a region and simultaneous attacks against multiple regions.

We thank our customers for their support, patience, and feedback during this large-scale attack and service recovery.

We would also like to thank the DDoS mitigation providers, telecom operators, and backbone providers for their prompt assistance and coordination in mitigating the attack.

The Selectel Team

The incident is closed. Post-mortem follows.

Since the last status update, no issues with resource availability have been observed. The DDoS attack no longer has a significant impact on the network availability of the infrastructure.

Throughout the night, the engineering team worked on optimizing the filtering system, network configuration, and routing rules. This work will continue today and is aimed at reducing the risk of repeated impact from the attack and improving network stability.

Due to the specifics of the filtering system, some legitimate routes may be blocked. If you experience network connectivity issues between your resources, please contact support — we will check the affected routes and make manual adjustments if necessary.

We continue to monitor the situation closely and will report any significant changes. We will provide a detailed explanation of the attack and our actions during the incident after its consequences have been fully resolved.

After changing the network configuration and redirecting traffic to the deployed filtering systems, we managed to almost completely eliminate the impact of the active DDoS attack on the infrastructure.

Network connectivity for resources in all regions has been restored. The control panel is operational again, including resource display and management. Issues with local DNS resolvers have been resolved.

Temporary issues may still occur with VPN connections between regions, along with increased latency and false positive triggers in the DDoS protection system, where legitimate traffic may be blocked.

We continue working on fine-tuning the filtering system and network configuration, as well as mitigating the consequences of the attack.

The reconfiguration of our network equipment and traffic filtering systems has been successfully completed.

In the Tashkent region, our team has already transitioned to the new protection schema. Network connectivity in the region has been preliminarily restored, and we expect a gradual return to normal operations and full resource availability.

We kindly ask our customers to check their services on their end to confirm everything is accessible and functioning correctly.

Our engineering team, working alongside our network operators, is continuously reconfiguring the network infrastructure to mitigate the severe DDoS attack.

The temporary isolation of external traffic has successfully restored network connectivity for VMs in the TAS-IX, UZ-IX, and KAZ-GOV-IX local networks. Our current focus is on fixing DNS issues to fully restore Kubernetes clusters and databases in the Tashkent and Almaty regions.

We are actively progressing with the configuration of our external traffic filtering systems. Upon completion, all inbound external traffic will be redirected to these specialized filtering facilities.

To mitigate the ongoing DDoS attack targeting our network infrastructure in Uzbekistan, we have temporarily separated external internet traffic from the local TAS-IX and UZ-IX networks.

As a result of this measure, access to services hosted in the Tashkent region is gradually being restored for users within Uzbekistan. We continue to work diligently to resolve the incident and bring global network connectivity back online.

As part of our ongoing efforts to mitigate the DDoS attack on our network infrastructure in the Almaty region, we have temporarily isolated external internet traffic from the local KAZ-GOV-IX networks.
Additionally, to filter external traffic, we have established a tunnel to redirect it to our partners’ dedicated scrubbing centers and are now actively initiating the blocking process.

We continue to expand network capacity and configure additional traffic filtering in collaboration with our network providers.
We have also engaged specialized partners to establish new routing paths to redirect a portion of the traffic to external scrubbing centers.
We will provide the next status update as soon as further details are available.

We are currently experiencing disruptions affecting the network availability of some of our services. The incident was caused by a large-scale attack targeting our infrastructure and impacting all of the company’s autonomous systems. While the attack has disrupted network connectivity, all servers, virtual machines, and customer data remain fully secure and have not been affected by the incident.

Our engineering team, together with upstream network providers and cybersecurity partners, is actively implementing a comprehensive set of mitigation measures to filter malicious traffic and restore stable network operations. We are isolating the attack vectors and rerouting traffic through new protected communication channels.

Due to the high intensity of the attack, the exact timeline for full recovery is currently unknown. We have engaged all available technical resources to resolve the issue as quickly as possible.

We will do our best to provide the next status update within the next hour, as soon as there are any significant developments.

We have detected massive network attacks on our data center infrastructure. The issue has now been fully contained and will be resolved as soon as possible.

Hello.

We are observing a large number of reports regarding the unavailability of virtual machines in the regions and the control panel. The unavailability is caused by a confirmed DDoS attack.

Our technical specialists are already working to resolve the issue.