はじめに
正規の署名がついているから安全、というのは半分しか正しくありません。今日紹介する2つの事件は、その「半分」の危うさをこれでもかと見せつけてきます。npmのプロベナンス証明書と、MicrosoftのSecure Boot署名。どちらも「これは正規のものです」と保証するための仕組みなのに、その保証レイヤーそのものを迂回されてしまいました。今日はこの2本を軸に、Linux/OSS界隈の5本をまとめます。
1. @asyncapi npmパッケージ4件にボットネットローダー混入――「証明書つき」で汚染が成立した日
まず一発目からかなり重い話です。API仕様記述の標準として広く使われる@asyncapiのnpm名前空間で、4パッケージ・計5バージョンが多段階ボットネットローダー「Miasma RAT v3」の配布に悪用されました。週合計およそ290万ダウンロードという、CI環境で日常的にnpm installされるツール群がやられています。
侵入経路がまた手が込んでいます。攻撃者はelzotebo999というアカウントで36件ものスパムPRを立ててメンテナの目を散らし、その裏でpull_request_targetトリガーの誤設定を突いて本命のPRを通しました。このトリガー、フォークからのPRでもベースリポジトリの権限で動くのでシークレットにアクセスできてしまう代物です。窃取した高権限PATでリリースワークフローを起動させ、悪性版パッケージをnpmへ公開させた、という流れでした。
ペイロードも念入りで、require()が呼ばれたタイミングで発火する遅延実行、IPFS経由でのダウンロード、AES-256-GCM暗号化された8.25MBのローダー…と、静的スキャナをすり抜ける工夫が随所にあります。展開されるMiasma RAT本体は744モジュール・91,973行、C2チャネルはHTTPからEthereumスマートコントラクトまで7系統。正直、ここまでの規模のRATがnpmパッケージ経由で降ってくると聞くと背筋が伸びます。
そして一番引っかかるのがここです。汚染された5バージョンはすべて、npmの正規OIDC信頼済みパブリッシャー経由で公開され、有効なSLSAプロベナンス証明書が付与されていました。プロベナンスは「どのビルド環境から出たか」を証明する仕組みですが、そのビルド環境自体が乗っ取られていれば、証明書は「正しく汚染されている」ことを保証するだけになってしまう。しかもこの脆弱なワークフロー、58日間も内部で指摘されながら放置されていたというオチまでついています。この記事を書きながら、筆者も真っ先に手元のプロジェクトのpackage-lock.jsonをgrepしました。幸い今回は該当バージョンにヒットしませんでしたが、正直ヒヤッとしたのは事実です。皆さんも心当たりがあれば、今すぐ確認をおすすめします。
2. io_uringにロックレスMPSCキュー導入――Linux 7.2で非同期I/Oの土台を作り直す
ここでいったん、地味だけど効く話に切り替えます。Linux 7.2のio_uringサブシステムに、Dmitry Vyukov設計のロックレスMPSCキューが導入されました。従来はllist（LIFOリンクリスト）でtask_workを積んでいたため、FIFOの順序に戻すためのO(n)反転処理を毎回回す必要があったのですが、新実装はキュー構造そのものでFIFOを保証するため、この反転コストがまるごと消えます。push操作はアトミック交換1回で完了、しかも面倒だった「リトライリスト」も不要になりました。
ユーザースペースのAPIは一切変わらないので、Nginx・PostgreSQL・RocksDBのようなio_uringを使うアプリは、カーネルを上げるだけで恩恵を受けられます。派手なベンチマーク値はまだ出ていませんが、キューが深くなる高負荷時ほど効きそうな改善です。機能を足すのではなく機構を削って速くする、こういうリファクタリング、個人的にすごく好きです。
3. Linus Torvalds「LinuxはAI反対プロジェクトでも社会運動でもない」と明言
小休止トピックです。GoogleのRoman GushchinがRustで実装したエージェント型AIコードレビューツール「Sashiko」をめぐる論争を受けて、Torvaldsが踏み込んだ発言をしました。「LinuxはアンチAIプロジェクトのひとつではない。フォークするかここを去ればいい」。Sashikoは直近1,000件の未フィルタセットで53%のバグを発見し、しかもそのバグは人間レビュアーには100%見逃されていたという実績を出しています。
とはいえ野放しにしているわけではありません。2026年4月施行のAIポリシーで、AIエージェントは法的拘束力を持つSigned-off-byタグを使えず、代わりにAssisted-byタグで使用を透明化し、AIが生成したコードの責任はすべて提出した人間が負う、と明確に線引きされています。「便利だから使う、ただし責任は人間が丸ごと引き受ける」というこの落とし所、他のOSSプロジェクトがAI導入を検討する際の参考になりそうです。
4. COSMIC Epoch 1.3リリース――全Rust製デスクトップ初のFrosted Glass実装
明るい話題も挟みます。System76がCOSMIC Epoch 1.3.0をリリースしました。目玉はすりガラス（Frosted Glass）エフェクト。パネルやウィンドウにまで適用範囲が及び、実装のために基盤ライブラリlibcosmic全体を更新する必要があったとのこと。全Rust製デスクトップがこの手のブラー系エフェクトを本格実装したのは初めてで、「Rustでは描画が重い」という懸念への実物の回答になっています。
GPU監視まわりも地味に強化されていて、Intel GPUのVRAM使用量取得、AMD／IntelのGPU消費電力のリアルタイム表示が追加されました。ラップトップの省電力管理やクリエイティブ用途で刺さる機能です。2025年12月の安定版1.0からわずか7ヶ月でここまで来ているペースの速さには素直に驚きました（正直、Rustデスクトップはもう少しゆっくり育つものだと思っていました）。
5. UEFI失効リストに未登録の旧shimバージョン――Secure Bootバイパスが今も有効
締めは今日最大級のインパクト、そして1本目と対になる話です。ESETが発見した11個の旧shimブートローダー（v0.9以下）が、MicrosoftのUEFI失効データベース（dbx）に10年以上登録されないままでした。管理者権限を持つ攻撃者がSecure Bootを迂回してOS起動前に任意コードを実行できる状態が、実に10年以上放置されていたことになります。CVE-2026-8863（CVSS 7.8）とCVE-2026-10797が割り当てられ、CMU CERTが7月15日にVU#616257としてアドバイザリを公開しました。
shimはUEFIファームウェアとLinuxカーネルをつなぐ「橋渡し役」で、Microsoftの証明書で署名された信頼の起点です。ところが古いshim（v0.9以下）にはコンポーネント単位で世代管理するSBAT（Secure Boot Advanced Targeting）が存在せず、無効化する手段はdbx更新しか残っていません。そのdbxに11バイナリが長年登録されていなかったのですから、防御手段が実質ゼロの状態が続いていたわけです。攻撃者は脆弱なshimバイナリをターゲットマシンに持ち込むだけで、BoozkittyやBlackLotusのようなUEFIブートキットをSecure Bootが有効なシステムにすら展開できてしまいます。
Linux側の対応はsudo fwupdmgr refresh && sudo fwupdmgr updateでdbx更新を適用するのが基本線ですが、古いshimに依存していた環境は先にshimを更新しておかないと起動不能になる恐れがあるので、適用前にブート構成を確認してから、というのが現実的な進め方です。
まとめ
今日の5本を貫くテーマは、「署名された信頼は発行した瞬間がゴールではなく、その後どう取り消せるかで真価が問われる」ということでした。@asyncapiでは正規のプロベナンス証明書が汚染パッケージにお墨付きを与え、旧shimでは正規のMicrosoft署名が10年以上失効されずに生き延びた。発行の仕組みはどれも高度に整備されているのに、取り消しの運用が追いついていない――この非対称性、皆さんの現場ではどちらが盲点になっていますか。まずは手元のnpmロックファイルとブート構成、両方をちらっと確認するところから始めてみてください。