Ubuntu 27.04 “Tenacious T-Rex” の開発
Ubuntu 27.04の開発がスタートしました。コードネームは“Tenacious T-Rex”（粘り強いティラノサウルス）、リポジトリ名や愛称としては「tenacious」が用いられることになります。形容詞＋動物の名前、というUbuntuのお約束からは少しだけ離れ[1]、恐竜がマスコットになる初のリリースです。
現時点ではリリースノートのひな形と仮置きされたスケジュールが準備され、リリース日が2027年4月22日であることが決められ、ツールチェインも準備された、要するに「最序盤に行われるタスクが完了した」だけの段階です。どのような新機能やテーマが採用されるのか、といった点はこれから見えてくることになるでしょう。
[1] 15.10の“Wily Werewolf”（狼男）や23.10の“Mantic Minotaur”（ミノタウルス）など、「動物」というカテゴリーからやや外れた名前が与えられることはそれなりにあり、そこから比べると恐竜は動物に近いのではないか、あるいは、もともと鳥類がアリなので恐竜もそこの枠でOK、といった弁護の余地があります。
PHPや証明書失効への対応
各種ニュースを含めて世間を騒がせているPHPの脆弱性（{CVE-2026-109618}、{CVE-2026-109619}）について、Ubuntuにおける対応が公表されています。気にするべきことは次のとおりです。
Ubuntuでは対応するPHPパッケージが提供済みなので、対応しているパッケージに更新することで対応できます。unattended-upgradesによって自動的に更新されていることもあるでしょう。
PHPを暗黙でロードしているようなソフトウェア（たとえばmod_phpを利用しているapache2）では、そのプロセスの再起動を行うことで対策できます。
もし20.04 LTS以前のLTSバージョンを利用している場合は、Ubuntu Proサブスクリプション経由でESM（Expanded Security Maintenance）リポジトリを有効にしている必要があります。
EOLしたバージョンには更新版は提供されないので、サポート対象のバージョンにアップグレードするところから対応する必要があります。
また同様に世間を騒がせている[2]、eMudhraの証明書問題についても証明書パッケージの更新が行われたことが公表されています。公表された内容を含め、行うべき対応は次のとおりです。
対応する証明書パッケージ、つまりca-certificatesを更新し、証明書ストアを更新する必要があります。通常は（証明書ストアのコピーを保持していなければ）パッケージの更新だけで問題ありません。
ソフトウェア側で独自の証明書ストアを保持している実装（たとえばJava）では、それらの更新も必要です。
golangなどの一部の処理系では、予防的にこれらの証明書チェインを拒否する形の実装が準備されていることがあります。これらの更新は「証明書ストアが更新できない環境」に備えたものであり、対応は必須ではありません。
Webブラウザーなどで「この問題に対応済みかどうか」を確認したい場合は、https://emudhra.we-have-a-problem.com/を開いて「Does your client still trust the compromised intermediates?」セクションで補助的に確認できます。
[2] これは「なんらかの理由で秘密鍵が0-255のレンジから選ばれてしまい、結果として『4』のような数値が入っていたので秘密鍵が事実上既知」という問題です。
CVE-2026-99999（PwnEscape）への対応
Linuxカーネルにおける新しい攻撃ベクターとして、「ネットワーク処理のチェックサムにおけるメタデータの検証不備」に起因する新しい攻撃手法が発見されました。この攻撃手法はCVE-2026-99999がアサインされ、通称として「PwnEscape」と呼ばれています[3]。悪用により、仮想化ゲストからホストを侵害することが可能です。
Ubuntuを利用している場合、短期的な対処として、次のことが必要です。現時点では対応カーネルは準備中です。
対処版カーネルが登場したら、それに更新する（現時点では安定的な攻撃がどこでもできる、という状態ではないので、まだ時間があります）。
また今後、この脆弱性を用いた攻撃が日常的になることに備える必要があります。
「正規のユーザーが実行している仮想マシンが乗っ取られ、そして仮想化ホストまで攻撃される」というシナリオがありうるので、仮想マシンが外部になんらかのサービスに依存している場合、そこから攻撃される可能性を考慮する必要があるでしょう。あわせて、攻撃される機会そのものを制御することも必要です。たとえば次のような対処が考えられます。
何らかの方法ですでにパッチしたり、mitigationを展開している環境に一時的に避難する。
クラウドサービス的な形で「任意の仮想マシン」を起動できる環境の場合、新規ユーザーの登録を停止することも選択肢に入るでしょう（攻撃者は新しいアカウントを使うことが多いと考えられるからです）。
新規ユーザーが実行するインスタンスはパッチ済みの空間にアサインする、仮想ホストそのものの異常性を検出して乗っ取りに気付けるようにする。
こうした「新種の攻撃ベクターを持つ脆弱性」が発見された場合、同種の攻撃手法が探索され、そして新しい脆弱性が発見されることがほとんどです。言い換えると、類似する影響範囲を持つ攻撃が続出することが考えられます。少なくとも次の対処を検討しましょう。
同種の対応、つまり「仮想マシンを保持するホスト」のカーネルを頻繁に更新できるようにする。たとえば仮想マシンをライブマイグレーション等で「脇によけて」更新できるようにしたり、必然性の低い仮想マシンが提供するサービスを廃止し、仮想インスタンスを一時停止できるようにする。
全体的に、この脆弱性そのものよりも「この脆弱性が登場することで変化すること」のほうが大きな影響をもたらすので、「類似する事例が毎月登場するようになったらどうするべきか」を考えておくことをお勧めします。
[3] gihyo.jpの記事も参照してください。
その他のニュース
Workshopの0.9.8と0.9.9がリリースされています。クレデンシャルをsystemd経由で管理できるようになったことと、vsockによる仮想マシン実装のリライトが行われています。なんとなく1.0.0が近づいてきている気配があります。
Multipass 1.17がリリースされています。Availability Zoneを定義する機能とともにDebian・Fedoraのクラウドイメージを扱う機能が追加され、WindowsやmacOS環境における仮想マシンのインターフェースの更新が行われています。