ubuntu.comへのDDoSとその対処
5月1日前後から発生していた、外部の攻撃者によるもの と見られるDDoS攻撃によるubuntu.comインフラストラクチャの可用性問題についての対策状況 が公開されています。
現状としては「DDoS攻撃の緩和措置を適用した」ということと、「 対処中のため、まだ十分なパフォーマンスが回復していないシステムがあるかもしれない」ということが説明されています。
なお、類似する事象が発生した場合はstatus.canonical.com （ステータスページ）と、upptime を確認することで把握できるでしょう。特にステータスページの下部には障害の履歴や対応状況が記載されているため、「 何か起きているかもしれないとき」に一次情報として利用できます。こうした問題への対処については、本稿後半の「注目すべきセキュリティー的な視点」もあわせて確認してください。
“copyfail”問題への対応
“copyfail” 問題（CVE-2026-31431 ）への対応カーネルと、関連するアドバイザリー が提供されています。この脆弱性は、一般ユーザー権限があればroot特権を取得できる性質のもので、強制アクセス制御によって防御されていない場合はシステムの制御権を攻撃者に奪われてしまいます。
アドバイザリーを参照の上、必要な対処を行ってください。通常の場合はカーネルの更新が推奨されます。
カーネルをすぐにアップデートできない場合、「 sudo rmmod algif_aead 2>/dev/null 」で問題のあるモジュールをアンロードする手順が存在します。アンロードは常に成功するとは限らないので、モジュールがアンロードされたかどうかを含めて手順を確認して対応してください。「 Manual mitigation (alternative)」として提示されている、モジュールのロードそのものをブロックする方法もあります（「 すでにロードされてしまっていて、アンロードもできない」展開の場合は再起動が必要になるため、「 新しいカーネルでの動作確認がどうしても必要」といった事情がない場合はアップデートするほうが安全と言えるでしょう） 。
Ubuntu 26.10 “Stonking Stingray”の開発 / ドキュメント公開サイトの整理
Stonkingの開発とは直接関係ないものの、ドキュメント関連の整理が行われるとともに、新しいポリシーが提示されて います。26.04 LTSにおいてリリースノートがdocumentation.ubuntu.comへ移動した こと以外に、次のことが示されています。
まず、ハードウェアサポートに関連するドキュメントがcanonical-ubuntu-hardware-support.readthedocs-hosted.com に集約される形になりました。ここでの「ハードウェアサポート」というのは「PC以外」の環境についてで、Raspberry Pi、RISC-Vボードと「さらにそれ以外」についてがここに集約されるのだ、という説明が行われています。
Zigに関連するドキュメントが追加 されました。
LLMが利用するウェブサイトの補助ドキュメントであるllms.txt の提供が開始されています。llms.txt、またはllms-full.txtがSphinxによって（Markdownから）ビルドされるタイミングで生成されるようになり、各種ドキュメントに付随するようになります。
各種ドキュメントに「ウェブリング」と呼ばれる共通ヘッダがセットされるようになりました。この共通ヘッダを経由して、複数のドキュメントを渡り歩くことができます。
各種ドキュメントについて、トリアージポリシーとプロセス、オーナーが明確にされました。
その他のニュース
Solana上にUbuntuのAIエージェント を構築している（名前はNumbat）という発表が行われています。現状ではある種のプレースホルダー的な発表 があるだけで現実的にどのような基準でトークンが配布されるのかは不明瞭ですが、「 Full eligibility requirements and claim instructions will be released soon through official Ubuntu channels.」（ 応募資格の詳細および申請方法については、近日中にUbuntuの公式チャンネルを通じて発表されます）ということで、今後の発表が待たれます。 Permission Prompt についての解説。AppArmorを含め、Snapパッケージにおける「権限」の要求についての説明です。 Windows環境においてUbuntuを利用する 方法。Intuneを含めた大規模デプロイメント環境において、UbuntuをWindowsと「共存」させる方法についての解説です。 Ubuntu Summit 26.04のタイムテーブル が公開されています。
注目すべきセキュリティー的な視点： ubuntu.comへの依存性を制御する ubuntu.comそのものが狙われる、というインシデントが発生したこともあり、今回は「ubuntu.comへの依存性をどう制御し、どのようにUbuntuをインストールした環境を防御するべきか」を考えてみましょう。
まず根本的には、「 ubuntu.comへのアクセスができないと、Ubuntu環境においてはパッケージの更新ができない」という問題があります。今回の攻撃では、脆弱性関連のAPIが比較的最後まで利用できず、攻撃者が「狙う場所」であることも明らかになりました。これはつまり、「 ここを狙うと脅迫として機能しやすい」という認識が攻撃者にあったことを意味します。
パッケージの更新ができない、あるいは脆弱性情報を取得できないことは、システム管理において脆弱性を塞ぐ方法のうち、特に重要な一つが利用できないということを意味します。パッケージの更新や公式な脆弱性情報の取得だけが脆弱性への防御ではありませんが、数ある中でベストな対応のひとつであることは事実です。そしてこの攻撃に対する耐性を獲得するには、「 ベストではないかもしれない、他の緩和策」を用いる必要があります。
ubuntu.comドメインでホストされているアーカイブサーバーからパッケージを取得できないのであれば、各種アーカイブミラーサーバーからパッケージを取得すればよいのではないか、という発想もありえます。しかし、各種アーカイブミラーサーバーも本質的には上流から単にコピーしているため、上流が落ちている状態では古いパッケージを提供することしかできません。
一方この意味では、「 自前のミラーサーバーを構築しておく」という方法で、「 アップデート作業全体まで阻害される」という事案を防ぐことはできる、と言えます。大規模な（あるいは本格的な）運用であればミラーサーバーを自前で持つ、という方法がまず必須と言えるでしょう。
また、ubuntu.comが利用できないということは、Ubuntu側から提供される緩和策の情報も得られないことを意味します。つまり、「 他の情報源」から大切な緩和策についての情報を得る必要があります。また、その緩和策がUbuntu上で真に機能するか検討する必要もあります。
また、大規模な攻撃シナリオとして「コアになるサイトを落とし、さらにトロイの木馬をインストールさせるニセの手順を流布する」という方法論もあります。さらに応用すると、「 あらかじめサプライチェーンを汚染しておき、「 手順としては確かに脆弱性を防ぐことそのものは可能だが、トロイの木馬を含む悪意あるコードが導入される」というようなこともありえるでしょう。
意味を十分に理解した上で、あるいは「確認可能な状態で」対応しないと、無意味な対策や、あるいはシステムの整合性を破壊する対策を導入してしまう可能性もあります。「 ある脆弱性の対処が、Ubuntuではどのように展開されるのか」を知っておく、ということで、この問題を緩和できるでしょう。
もっともここまで来ると「そもそも何を信用すればいいのか」という命題に還元されてしまいます。現実としては「どのようなソフトウェア的な構成要素から成り立っているのかを理解しておく」という方向になります。原理やリスク、あるいはそのリターンを理解していない手順を「なんとなく」使うこと、つまり解像度の失われたアクションがリスクを増幅する可能性がある、と考えておく必要があります。
この問題にはそこまで明確な「解」はありませんが、少なくとも「何か起きてから急に新しいことにチャレンジする」というシナリオを避けられるようにしておく、という必要はありそうです。
