On October 8, 2026, Canonical said its websites were "under a sustained distributed denial of service attack." Within minutes, ubuntu.com, canonical.com, the Ubuntu blog, the developer portal and the Ubuntu Security API stopped responding. It was the second major DDoS against Canonical in six months.
Canonical is no small target. It runs some of the most-used open-source infrastructure in the world, with engineering talent to match. If an organization like that can be knocked offline twice in one year, the lesson for everyone else is plain: DDoS is not a solved problem, and good engineering alone is not a defense.
Two attacks, two different footprints
The first incident surfaced on April 30 as a ubuntu.com outage. By May 1, Canonical described a "sustained, cross-border attack" on its web infrastructure, and it was May 6 before mitigations restored service. Launchpad, PPAs, Ubuntu Single Sign-On, mailing lists and the Snap Store were all affected.
October was narrower and shorter. The main websites were down for about 4 hours and 12 minutes, and early reports said ISO downloads were hard to reach. Canonical confirmed that every website was back by October 14.
Canonical services hit in each 2026 attack
A second attack doesn't prove the first fixes failed; the smaller footprint suggests some hardening worked. But it raises a sharper question: which services were still exposed?
For security teams, losing the Security API and advisory pages mattered most. Those are the resources administrators reach for when they need to confirm a CVE fix, and they went dark at the moment attention was highest.
The attack machine keeps getting bigger and cheaper
Canonical hasn't said who was behind either attack, but the wider landscape explains a lot. In June 2026, Nokia's Deepfield team, working with Comcast, reported that the Kimwolf botnet split into more than 20 successor families after its takedown. Daily active DDoS-capable endpoints grew from about 1 million to 8–9 million in a year, and attacks now reach tens of terabits per second.
Many of those endpoints are cheap streaming boxes, backdoored apps and residential proxies on ordinary home connections. Blocking their IP ranges also blocks legitimate subscribers, so source reputation is a weaker signal than it used to be.
The firepower is also for rent. In April 2026, Europol's Operation PowerOFF took 53 DDoS-for-hire domains offline across 21 countries and warned more than 75,000 booter users. Takedowns help, but they don't clean up the compromised devices behind those services, or remove the motive.
The result: attack capacity and attack intent no longer need to belong to the same party. Anyone with a grievance and a credit card can rent a flood.
Redundancy helps, but it is not protection
The most instructive part of Canonical's story is what kept working. In both incidents, the APT package repositories stayed available. They are mirrored and distributed worldwide, and APT checks signatures and hashes. A mirror can deliver packages without becoming the authority on which packages are safe to install.
That is good architecture, and worth copying. But the websites, developer portal, security advisories and, in April, identity services all sat behind front ends that could be flooded. Each customer-facing service is its own target.
Two practical checks follow:
- Map which services sit behind your own front door: portals, APIs, login, DNS, status pages. Know which ones have no alternate path.
- Test failover in an authorized environment. Confirm that alternate routes keep valid TLS, hidden origins and signature checks intact. A failover that disables security is a new risk, not a fix.
Radware approach to mitigating floods
Much of the industry's attention has moved to Layer 7 threats such as HTTPS floods, API abuse, and bots. Those threats are real. But Canonical's October incident, reported as an "automated volumetric onslaught," demonstrates that Layer 3 and Layer 4 floods can still disrupt major online services.
As DDoS attacks become more distributed, sophisticated, and difficult to distinguish from legitimate traffic, effective protection requires more than simply absorbing large volumes of packets. The challenge is to identify and block malicious traffic quickly while preserving service availability for legitimate users.
| Flood Technique |
Industry Best Practice |
Radware Approach |
| Volumetric UDP Floods |
Cloud scrubbing and rate limiting absorb floods but may impact legitimate traffic. |
DefensePro BDoS detects anomalies and generates attack-specific signatures to minimize false positives. |
| SYN Flood / TCP State Exhaustion |
SYN cookies, proxies, and connection limits protect servers but may add overhead. |
DefensePro SYN Protection uses targeted challenges to block malicious connections while preserving legitimate traffic. |
| DNS Query Floods |
DNS rate limiting and anomaly detection filter suspicious queries but may miss changing patterns. |
DefensePro DNS Protection learns DNS traffic behavior and applies targeted mitigation. |
| Multi-Vector and Zero-Day Floods |
Anomaly detection and predefined signatures address attacks but may miss unknown patterns. |
DefensePro automatically generates real-time signatures to mitigate previously unseen attack patterns. |
| Bandwidth-Saturating Floods |
Upstream cloud scrubbing absorbs attacks exceeding local network capacity. |
Radware Hybrid DDoS Protection combines on-premises DefensePro with cloud scrubbing for upstream protection. |
Radware combines behavioral traffic analysis, automatically generated attack-specific signatures, and hybrid mitigation to address both the volume and complexity of modern DDoS attacks. Its Emergency Response Team (ERT) provides additional expertise during attacks, helping organizations maintain availability while limiting disruption to legitimate users.
Don't wait to be the next headline
Canonical recovered and kept its core distribution paths alive. Most organizations would not get off that lightly: hours offline mean lost revenue, frustrated customers and a security team pulled off everything else.
The question is not whether your organization will face a DDoS attack. It is whether your protection is in place before it starts. Now is the time to review which of your services are exposed, test how they hold up under pressure, and make sure mitigation kicks in automatically when the flood arrives.
Talk to Radware's DDoS experts to assess your exposure and see how hybrid, behavioral DDoS protection keeps your services online.
Sources