Tinfoil hat mode: a competitor wants to exploit copy.fail on some ubuntu servers, and is DDoSing canonical so that they can't update and thus patch the vuln
Double tinfoil hat mode: an attacker learned of my plan to finally update my personal computer out of 20.04 today and is DDoSing canonical so I can't do that and I remain vulnerable to the backdoors they've found. The plot thickens...
Canonical/Ubuntu have been under DDoS
31–40 of 76 posts
Re: Canonical/Ubuntu have been under DDoS
#32Though this outage may be more related to the copy.fail upgrade cycle, it reminds me of a thought I've had recently in respect of agents. In the UK they have this issue called "TV pickup" ( https://en.wikipedia.org/wiki/TV_pickup ). TV pickup is where everyone in the UK watching a popular TV show gets up to boil a high-powered tea kettle at the same time on an ad break. This causes a temporary surge in electricity de…
Um, no.
I daresay you could find the odd example, as for any grid in a stressed situation, but it's not like we turn to each other every week in the dark and say "Oh, it must be half time at the Manchester United match".
Re: Canonical/Ubuntu have been under DDoS
#33Earlier quoted context omitted.
If you can access AF_ALG on a server you don't need to do shenanigans like that. It's much easier to just find another bug and exploit that one instead. The copy.fail website is very silly, it is not a special bug. If anyone gets compromised by that vuln their node architecture was broken anyway, patching copy.fail doesn't help.
In what way is it "not a special bug"? It's a publicly known root access from RCE exploit. Those cannot be a dime a dozen. I'm sure it's especially interesting for any shared hosting services which might be affected, and could be delayed. I could find any places running containered services and exfiltrate secrets parallel services, no? What constitutes "special" for you, out of curiosity? Something chaining with a hy…
Even just in AF_ALG there have been several such vulns fixed in 2026 already. Kernel wide probably hundreds. It's true that most of them will be harder to exploit than this one but that just means you need to prompt your AI a bit harder to get an exploit. (To be fair, in a lot of cases it's gonna be hard to escalate privs without crashing the machine).
Ubuntu has userns restrictions now which takes away the main sources of LPEs (random qdiscs, nftables, all that garbage) but there are still huge numbers of these vulns. This is why platforms that do native untrusted code executions have extreme sandboxing. Note Android and ChromeOS aren't affected coz they already knew this code was broken and hide it from unpriv workloads.
You can't run untrusted code on Linux without either a very very carefully designed sandboxing layer (like Android/ChromeOS) or virtualization. copy.fail is just one among tens of thousands of reasons for this, and it's a pretty uninteresting one at that.
What is "special" depends on your usecase but for my job it's mostly about stuff that's exposed to KVM guests. Biggest source of concerning vulns for us is probably vhost. I expect there are also lots of undiscovered and scary vulns in places like virtiofs, vfio, DAX, and wherever we do device passthrough.
> I could find any places running containered services and exfiltrate secrets parallel services, no?
Yes. Regardless of copy.fail. Cloud providers don't do that without a VM layer. (If yours does, you need to switch).
Re: Canonical/Ubuntu have been under DDoS
#34Earlier quoted context omitted.
If you can access AF_ALG on a server you don't need to do shenanigans like that. It's much easier to just find another bug and exploit that one instead. The copy.fail website is very silly, it is not a special bug. If anyone gets compromised by that vuln their node architecture was broken anyway, patching copy.fail doesn't help.
I thought copy.fail is a privelage escalation exploit, become root from a regular user? Am I missing something? How would "node architecture" make people vulnerable to this? You have to have shell access to a victim first right? Or am I missing something?
Re: Canonical/Ubuntu have been under DDoS
#35Though this outage may be more related to the copy.fail upgrade cycle, it reminds me of a thought I've had recently in respect of agents. In the UK they have this issue called "TV pickup" ( https://en.wikipedia.org/wiki/TV_pickup ). TV pickup is where everyone in the UK watching a popular TV show gets up to boil a high-powered tea kettle at the same time on an ad break. This causes a temporary surge in electricity de…
Well, that and the rush to upgrade for copy.fail. Has Ubuntu published patches yet?
Re: Canonical/Ubuntu have been under DDoS
#36Re: Canonical/Ubuntu have been under DDoS
#37Earlier quoted context omitted.
Frustrating because the Slack snap is broken so every day you have to downgrade it and I guess you can't without connectivity. This might be the incentive I need to finally purge snap.
Just move to flatpak, much nicer to deal with
Re: Canonical/Ubuntu have been under DDoS
#38Maybe they could use this DDoS attack as their 17th round technical interview. Any candidate who successfully mitigates the attack would then make it to the 18th round. Win win!
Re: Canonical/Ubuntu have been under DDoS
#39Re: Canonical/Ubuntu have been under DDoS
#40Though this outage may be more related to the copy.fail upgrade cycle, it reminds me of a thought I've had recently in respect of agents. In the UK they have this issue called "TV pickup" ( https://en.wikipedia.org/wiki/TV_pickup ). TV pickup is where everyone in the UK watching a popular TV show gets up to boil a high-powered tea kettle at the same time on an ad break. This causes a temporary surge in electricity de…
https://www.theregister.com/2026/05/01/canonical_confirms_ub...
"Canonical says its web infrastructure is under attack after a pro-Iran hacktivist group instructed its members to target the open source giant."
Perhaps more to do with extortion rather than activism. (I have no idea how accurate theregister is on this story.)