Incident Report: May 13, 2026

Dear Customers and Partners,

Below is a detailed report regarding the DDoS attack on the Servercore infrastructure across the Almaty, Tashkent, and Nairobi regions. The incident started on May 13 at 11:20 and was transitioned to monitoring status on May 14 at 18:11. Please note: all times in this report are indicated in the GMT+3 time zone.

TL;DR

On May 13, Servercore’s network in Almaty, Tashkent, and Nairobi was hit by a massive UDP flood carpet DDoS attack on L3/L4 levels, peaking at 250 Gbps. The total duration of the incident was 30 hours and 51 minutes: this included 9 hours and 27 minutes of severe network degradation, followed by 21 hours and 24 minutes of gradual recovery before full service was restored.

To protect our infrastructure and customer data, we temporarily paused external BGP announcements while keeping local connectivity intact. To mitigate the attack, we routed traffic through external DDoS scrubbing centers: via established tunnels for Almaty and Nairobi, and through local telecom filtering systems for Tashkent after additional custom configuration. To reduce the risk of similar incidents in the future, we are already implementing always-on connections to multiple external DDoS scrubbing providers with automated failover, BGP automation scripts, pre-provisioned backup routes, and local DNS resilience measures for regional isolation scenarios.

What Happened

The Servercore network was targeted by a multi-vector, L3/L4 UDP flood carpet DDoS attack. The attack was cascading: it impacted multiple regions simultaneously. It was a carpet attack: instead of targeting a single IP address, the malicious traffic was distributed across a vast range of IPs at once. It was also multi-vector: the traffic profile constantly shifted, making detection and filtering exceptionally difficult.

Peak load on our backbone transit channels reached 100–250 Gbps. As a result, our standard DDoS mitigation systems — which handle typical malicious traffic in normal operation — were overwhelmed by the extreme volume and dynamic nature of the attack. Ultimately, the sheer volume of traffic started affecting not only our local infrastructure but also upstream transit providers.

Severe network degradation lasted for a total of 9 hours and 27 minutes. Over the following 21 hours and 24 minutes, connectivity was largely restored, though some speed degradation persisted due to the temporary mitigation routing paths. The overall duration of the incident spanned 30 hours and 51 minutes until full recovery.

Customer Impact

During the incident, customers may have experienced complete or partial loss of external internet access, unstable network connectivity, reduced speeds, and issues with DNS resolution, VPNs, and ISP interconnects.

We want to explicitly emphasize that customer data and infrastructure were entirely unaffected.

Our Mitigation Efforts

The Servercore engineering team began investigating the moment our monitoring systems triggered the first alerts. Initial triage took longer than usual because the malicious traffic had saturated our external uplinks, forcing us to rely on backup out-of-band management channels to access systems and coordinate our response.

Because the attack threatened both our infrastructure and upstream networks, we made the necessary decision to temporarily drop BGP announcements to the external internet. This relieved the pressure on transit providers, protected our core infrastructure, and kept local, intra-region connectivity alive wherever possible.

Following this, the team focused on setting up an emergency traffic scrubbing scheme via external DDoS protection partners: testing tunnels, updating routing policies, and swinging traffic over to external scrubbing centers.

Why Recovery Took Time

Recovery was delayed primarily by the sheer scale and carpet nature of the attack, coupled with the need to coordinate closely with external telecom and DDoS mitigation providers. Because the attack targeted massive IP blocks across all affected regions rather than specific addresses or services, standard targeted filtering did not solve the problem.

To safely restore public availability, we had to agree on and test new routing paths, verify traffic flows, and fine-tune filtering rules to match the live attack profile. Recovery in Tashkent took longer due to the need for additional manual configuration of the scrubbing hardware on the upstream backbone provider’s side.

Recovery Breakdown

Almaty and Nairobi

We opted to route traffic through external DDoS scrubbing centers. Our initial attempt failed, as the first external provider also struggled to scrub the malicious traffic. After assessing the situation, we switched traffic to a secondary mitigation provider. This worked: their scrubbing complex successfully filtered the bad traffic and allowed us to initiate recovery.

Following the initial restoration, some customers experienced slower speeds and unstable performance. This was caused by routing changes, increased latency (RTT), and the additional traffic processing overhead at the external scrubbing center. Once we optimized bandwidth and routing policies, performance stabilized.

Tashkent

Working closely with local telecom operators, we fine-tuned their mitigation hardware. After optimizing the settings, we successfully established malicious traffic filtering at the provider edge and gradually brought network resources back online.

Incident Timeline

• May 13, 11:20–12:25 — Detection and initial triage
  Monitoring systems flagged severe network drops and anomalous load spikes. Engineers began investigating. Due to uplink saturation, some actions had to be performed via backup management channels.

• May 13, 12:25–13:45 — Assessing the impact
  The team confirmed the attack was hitting several regions and a massive number of IPs simultaneously. Coordination with backbone operators and DDoS mitigation providers began.

• May 13, 13:45–15:50 — Dropping external BGP announcements
  External connectivity was temporarily severed to protect infrastructure and upstream networks. Local regional connectivity was maintained. DNS resolution issues also surfaced during this window.

• May 13, 15:50–19:00 — Enabling external mitigation
  A tunnel to the primary scrubbing center was established for Almaty, confirming the true attack volume of 200–250 Gbps. Because the primary mitigation failed to fully absorb the attack, the team initiated a failover to a backup provider. Meanwhile, Tashkent providers began manual hardware configuration. In Nairobi, an upstream provider temporarily dropped our BGP session to protect their own network from overload.

• May 13, 19:00–22:59 — Backup mitigation and partial recovery
  The backup scrubbing provider was successfully engaged for Almaty and Nairobi. In Tashkent, manual fine-tuning was completed, and upstream filtering kicked in. Services began to recover gradually. Fixes were pushed to restore DNS resolution.

• May 13, 22:59 — May 14, 01:39 — Resolving performance bottlenecks
  With connectivity restored, customers in Almaty and Nairobi reported slow speeds. Engineers identified a bandwidth limitation on the scrubbing provider’s side, corrected it, and optimized routing.

• May 14 — Stabilization and return to normal operations
  Once the attack volume dropped to insignificant levels, the team began reverting traffic to standard routing paths. Network access and speeds normalized. The incident was officially moved to monitoring status at 18:11 on May 14.

Preventative Measures and Next Steps

We are already overhauling our network architecture and incident response protocols.

Always-On External DDoS Protection

We will implement permanent connections to external scrubbing providers for the affected regions. In the event of an attack, this will allow us to swing all traffic to our partners’ scrubbing centers semi-automatically, using an architecture that proved effective under real attack conditions.

Automated Mitigation Triggers

We will implement automated triggers that instantly engage DDoS mitigation when specific traffic, packet loss, or availability thresholds are breached, drastically reducing time to mitigation.

BGP Automation

We will develop scripts to automatically manage BGP announcements. These will rapidly isolate our external perimeter while maintaining local and IXP connectivity where technically feasible, minimizing our reliance on manual intervention during crises.

Pre-Provisioned Backup Routes

We will build standby routing paths and tunnels to external scrubbing providers in advance. For Tashkent, we will handle the necessary technical and legal compliance approvals with local partners proactively, ensuring no time is wasted on approvals during an active incident.

Local DNS Resilience

We will redesign our regional DNS architecture so that basic network functions and local resource availability remain fully operational even if external connectivity is severed.

Drills and Playbooks

We will update our internal playbooks for massive L3/L4 attacks and run disaster recovery drills with our NOC, duty engineers, support teams, and external partners. We will specifically practice scenarios involving multi-region carpet attacks targeting massive IP blocks.

We sincerely appreciate your patience, support, and feedback as we worked through this massive attack and restored services.

We would also like to extend a special thank you to our DDoS mitigation partners, telecom operators, and backbone transit providers for their rapid response and collaboration.

The Servercore 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 receiving a large number of reports regarding the unavailability of the VM and the control panel due to disrupted network connectivity between regions.

Our technical specialists are already working to resolve the issue.