A DDoS knocked Ubuntu's update servers offline. The Copy Fail patch landed in the same 24-hour window.

Canonical confirmed on May 1 that Ubuntu’s web infrastructure was under a sustained DDoS attack that had knocked the company’s primary services offline since 1 PM EST the day before. The hit list runs deep: ubuntu.com, login.ubuntu.com, security.ubuntu.com, the Snap Store, Launchpad, MAAS, the Livepatch API, and Landscape, plus blog and developer subdomains.

This is bad timing. The outage opened a 24-hour window during which admins running Ubuntu fleets could not reliably check whether their boxes were vulnerable to Copy Fail, the kernel page-cache root exploit Canonical patched on April 29. Apt mirrors and ISO downloads stayed online, so binaries were technically available, but the Ubuntu Security API that automated tools query for CVE state was down or rate-limited. Anyone whose patch pipeline depends on Canonical’s USN feed lost visibility right when they needed it most.

Who is doing this and why

A self-described hacktivist crew calling itself “The Islamic Cyber Resistance in Iraq 313 Team” claimed responsibility on Telegram, then demanded Canonical “open a negotiation channel” or accept a sustained attack. The 313 Team has not stated specific demands beyond that ultimatum. Researchers tracking the campaign attribute the traffic to Beamed, a DDoS-for-hire service capable of pushing more than 3.5 Tbps. That is roughly half the volume of Cloudflare’s record 7.3 Tbps mitigation last year and well inside the range a midsize provider can sustain for days.

Canonical’s spokesperson Lelanie de Roubaix told reporters: “Canonical’s web infrastructure is under a sustained, cross-border attack and we are working to address it.” That’s the only on-record statement so far. The status page has been the primary signal channel, and the status page itself has gone red and yellow in shifts as different subdomains came back and dropped again.

The Copy Fail collision

Copy Fail is a 732-byte page-cache exploit that gets root on every major Linux distro since 2017. Canonical and Red Hat both shipped patches on April 29. Two days later, the public-facing infrastructure that confirms a given Ubuntu host has those patches went dark. For most home users, this doesn’t matter. For anyone running compliance-driven fleets, it matters a lot. SBOM tools, vulnerability scanners, and Ansible playbooks that hit security.ubuntu.com on every run started timing out, which means the audit trail for the most-talked-about Linux CVE of 2026 has a 24-hour gap right at the worst moment.

Canonical’s recommendation, per its status updates, is to fall back on NVD or OSV data for CVE checks until the Ubuntu API recovers. That is a sensible workaround for any team with the muscle memory to swap a feed mid-incident, and a real ask for any team that doesn’t.

What this means for you

If you run Ubuntu in production, do three things today. First, check your patch state for CVE-2026-3141 the slow way. Connect to each box and confirm the kernel package version, since you can’t trust the dashboard right now. Second, point any vulnerability scanner that pulls from Canonical’s API at OSV.dev or NVD as a temporary fallback so your audit logs don’t have a gap. Third, document the gap. If you’re under SOC 2 or FedRAMP audit, you’ll want timestamps showing you treated the outage as a known control failure and re-validated patch state once Canonical was back.

The longer-term takeaway is harder. Hacktivist DDoS against open-source infrastructure has been rare since the early 2010s, and a 3.5 Tbps booter aimed at a Linux distribution is a new failure mode for the ecosystem. Canonical will be fine. The next target won’t necessarily be. Watch whether the Free Software Foundation, the Apache Software Foundation, or one of the smaller Linux distros draws the same kind of traffic in the coming weeks. If a booter campaign can pin a distro’s patch feed during an active CVE response, the threat model for “infrastructure of the open ecosystem” needs an honest revisit, not a status page.