コミュニティ運営のLinuxディストリビューションOpenMandrivaは2026年7月8日、同ディストロの元コントリビューターであったDavide Beatrici氏(音声チャットプロジェクトMumbleのリードデベロッパとして著名)が、内部トラブルを契機に残存していた管理者権限を用いて破壊的操作を行ったとする「サボタージュ未遂」の声明を公式フォーラムで公開しました。声明によれば、Beatrici氏はGNOMEおよびCOSMIC関連のGitHubリポジトリを削除するとともに、開発ブランチCookerに空のパッケージをpushし、両デスクトップ環境向けのパッケージ群を一括でobsolete(廃止扱い)に設定しました。削除されたリポジトリには長年にわたる開発成果が含まれており、声明を出したAngryPenguin氏は、自身が約10年にわたり関わってきた内容だと説明しています。この空パッケージがCookerユーザ側の更新処理で適用されていれば、GNOMEまたはCOSMIC関連パッケージが広範に削除される可能性がありました。
本件は2024年3月のxz-utils事件以降、Linuxコミュニティが繰り返し議論してきた「信頼されたコントリビューターがそのままサプライチェーン攻撃面になり得る」という構造的問題が、今回は操作の痕跡が比較的明確に残る形で顕在化した事例にあたります。xz-utilsは「Jia Tan」というペルソナによる2年越しの社会工学の産物でした。一方、今回のOpenMandriva事案では、約3年間参加していた既知のコントリビューターが、コミュニティ内の対立と離脱後に問題となる操作を行いました。xz-utilsとは性質の異なる内部脅威の事例です。Beatrici氏自身は当該行為を「サボタージュではない」と明確に否定しており、対立の経緯やOpenMandriva運営側の対応の妥当性については、双方の主張が食い違っています。しかしどちらの立場を取っても、単独の管理者による一連の操作が、長年蓄積された開発成果を失わせ、エンドユーザのシステムにも影響を及ぼし得るレベルであった、という事実そのものがLinuxディストロ運営における権限モデルとバックアップ戦略の再点検を促す事例になっています。
OpenMandrivaが公表したサボタージュ未遂の全体像
本件はセキュリティ脆弱性ではなく、管理者権限を持つ元コントリビューターによる破壊的操作で、CVE番号は該当しません。OpenMandriva側は公式フォーラムで透明性のため詳細を公開し、犯罪行為に当たると主張しつつ法的措置は見送るとしています。声明の発表主体はOpenMandriva長年の開発者兼メンテナである「AngryPenguin」で、被害復旧作業と同時に完全なシステム監査も実施済みで、リポジトリ削除とパッケージ操作以外の追加の問題は確認されていないとされています。
| 項目 | 内容 |
|---|---|
| 事件通称 | OpenMandriva sabotage attempt(公式声明の表現、CVE非該当) |
| 対象ディストロ | OpenMandriva Linux(2012年にMandriva Linuxからコミュニティへ開発を移管して発足、community-run、LLVM/Clangでほぼ全体をビルドする独自方針) |
| OpenMandriva側による名指し | Davide Beatrici氏(Mumble音声チャットプロジェクトのリードデベロッパ、約3年前からOpenMandrivaに参加) |
| 声明発信者 | AngryPenguin氏(OpenMandriva長年の開発者・メンテナ) |
| 事件発生日 | 2026年7月8日早朝(公式声明は同日15:43 UTC発表) |
| 問題となった操作(1) | OpenMandrivaのGitHubリポジトリの一部を削除。長年の開発作業を含み、声明者自身は約10年関わってきたと説明。対象はGNOMEおよびCOSMIC関連リポジトリ。 |
| 問題となった操作(2) | OpenMandrivaの開発ブランチCookerに空のパッケージをpush、GNOMEおよびCOSMICの全パッケージをobsoleteに設定。パッケージマネージャによって処理されると、対象環境にインストールされているGNOMEおよびCOSMIC関連パッケージが一括削除される可能性。 |
| 影響範囲 | パッケージ変更は開発ブランチCookerが対象。ローリングリリースROMEや安定版Rockへの伝播・影響は、記事執筆時点の公式声明では明記されていない。 |
| ユーザへの実害 | OpenMandriva側は空パッケージを確認し、obsolete化されたパッケージの復旧作業を開始。公式声明ではユーザ環境での具体的な実害は報告されていないが、影響の有無や範囲の詳細は明記されていない。 |
| 権限の由来 | OpenMandriva側によれば、Beatrici氏はOneDevへの移行・ミラー作業を担当し、事件時点でも管理者権限を保持していた。 |
| Beatrici氏の反論 | The Lunduke Journalへのコメントで「これはサボタージュではない」「意図はディストリビューションへの加害ではない」「Cosmic/GNOMEリポジトリの削除とobsoleting packageは慎重に行った」「一部メンバーが自身の`.onedev-buildspec.yml`ファイルを事前連絡なしに削除したことへの対抗」と説明 |
| OpenMandriva側の対応 | 削除リポジトリとobsoleted packagesの復元作業を実施、完全なシステム監査完了、他の違反なしを確認。OpenMandriva側は犯罪行為に当たると主張しつつ、法的措置は見送り。 |
事件に至る経緯
OpenMandriva公式声明とBeatrici氏の反論(The Lunduke Journal経由)を突き合わせると、事件は次のような順序で進行しました。両者の主張は事実の骨格については概ね一致しますが、動機と経緯の解釈で対立があります。
まず、Beatrici氏とほぼ同時期にOpenMandrivaに参加した別の2名のうち1名が、他のコントリビューターや利用者に対して攻撃的な言動を繰り返し、これが原因で数名のコントリビューターがプロジェクトを離れました。OpenMandriva声明によれば、多くの敵対的なやり取りは非公開のメッセージで発生していたためAngryPenguin氏を含む運営側が全体像を把握するのは遅れがちで、後日「もっと早く対応すべきだった」と反省する経緯があります。OpenMandriva側によれば、そのコントリビューターが公開のMatrixチャットとGitHub上でも別の人物に攻撃的な言動を取ったため、AngryPenguin氏は対象者をOpenMandriva-CookerチャンネルのMatrixチャットからkickする対応(banではなく、単一チャンネルからのkick)を取りました。
この対応への抗議として、Beatrici氏を含む2名のコントリビューターがOpenMandrivaを離脱します。これを受けてAngryPenguin氏は「Beatrici氏の個人所有インフラへのミラーを維持する意義がなくなった」と判断し、自身が保守するパッケージのミラー接続の一部を切断しました。Beatrici氏側の主張によれば、この切断作業の一環でOpenMandriva側の一部メンバーが、Beatrici氏の管理していたリポジトリから`.onedev-buildspec.yml`ファイルを事前連絡なしで削除しました。これがBeatrici氏の後続行動の直接的な引き金になった、というのが彼自身の説明です。
問題となった操作の技術的内容
2026年7月8日早朝、Beatrici氏はまだ保持していた管理者権限を用いて、二段構えの操作を実行しました。
第一段は、OpenMandrivaのGitHubリポジトリからCOSMICおよびGNOME関連リポジトリの削除です。OpenMandriva声明では長年にわたる作業とされ、AngryPenguin氏は自身が約10年関わってきた内容だと説明しています。Beatrici氏本人の説明でも「Cosmic and GNOME repositoriesを慎重に削除した」と行為自体は認められています。GitHubでは、組織所有者が削除から90日以内であれば一部のリポジトリを管理画面から復元できます。ただし、空でないfork networkに属するリポジトリでは復元に制約があり、team permissionsは復元されません。今回削除された各リポジトリの復旧状況や失われた付随情報の詳細は、公表時点では明らかにされていません。
第二段は、Cookerリポジトリへの空パッケージのpushです。RPMベースのディストロにおいて、パッケージのspec fileでは`Obsoletes:`ディレクティブを用いて「別の名前で提供される機能を持つ古いパッケージを置き換える」という宣言が可能です。Beatrici氏はこの仕組みを利用し、GNOMEおよびCOSMICデスクトップ環境のすべてのパッケージを`Obsoletes:`対象として列挙した空パッケージをpushしました。パッケージマネージャは通常、`Obsoletes:`を持つパッケージのインストールにあたって列挙対象を自動的にアンインストールするため、この空パッケージが利用者側の更新トランザクションで処理された場合、環境にインストールされているGNOMEおよびCOSMIC関連パッケージが一括削除されることになります。GNOMEまたはCOSMICを唯一のデスクトップ環境として利用しているシステムでは、次回ログイン時にグラフィカルセッションを起動できなくなる可能性があります。
OpenMandriva側は本件の空パッケージを確認して復旧作業に着手しており、公式声明ではユーザ環境での具体的な実害は報告されていません。ただしこの手法自体は、通常のパッケージ配布パイプラインが持つ「上流の`Obsoletes:`宣言を信頼する」という設計上の前提を悪用したものです。同じRPM機構を採用する他のディストリビューションでも、パッケージ公開権限が悪用され、レビューを通過した場合には、同様の影響が生じ得ます。
xz-utils事件との対比:内部脅威の異なる系譜
本件が業界で広く注目された背景には、2024年3月に発覚したxz-utils backdoor事件(CVE-2024-3094)以降、Linuxコミュニティが繰り返し議論してきた「信頼されたコントリビューターのサプライチェーン上の脅威」という論点があります。xz-utilsでは「Jia Tan」名義のコントリビューターが約2年間の期間をかけてxz-utilsプロジェクトへの信頼を構築し、最終的にはmaintainer権限を獲得したうえで、liblzmaにバックドアを組み込み、特定のsshd構成で認証前の遠隔侵害につながり得る仕組みを埋め込みました。これは高度に隠密な社会工学と、コミュニティが依存する「信頼されたコントリビューターには広い権限を与える」という慣行が組み合わさった典型例でした。
OpenMandriva事件は、xz-utilsとは異なる系譜の内部脅威の顕在化です。共通点は「trust boundary(信頼境界)がそのままattack surface(攻撃面)になる」という構造で、管理者権限を持つコントリビューターがその権限で持続的または一時的なダメージを与え得る点です。相違点は行為の性質にあり、xz-utilsが目立たない挿入を目的とした「covert(隠密)」型であったのに対し、今回のOpenMandriva事案では、リポジトリ削除とパッケージobsolete化という明示的な操作が行われたとOpenMandriva側が説明しており、少なくとも操作の痕跡はxz-utils事件よりも表面化しやすいものでした。技術的な検知の難易度も対照的で、xz-utilsは、配布tarballと複雑に難読化されたビルド処理に悪意あるコードが組み込まれており、通常のソースレビューでは発見しにくい仕組みでした。一方、OpenMandriva事件は、リポジトリの変更履歴や監査ログから比較的追跡しやすい操作でした。
この2つの事件が示すのは、サプライチェーン上の内部脅威は単一の対策では防げないという事実です。xz-utilsのような隠密型に対してはコードレビューとreproducible builds、artifact provenanceが有効ですが、OpenMandriva事案のように、リポジトリ削除やパッケージ操作の痕跡が比較的明確に残るタイプに対しては、権限モデル、監査ログ、多重バックアップ、そして単一コントリビューター依存の解消といった運用面の対策が求められます。両者の防御手段には重なりもありますが、脅威モデルの想定が異なるため、同時に整備する必要があります。
実務対応と組織設計の見直し
本件が示す教訓は、OpenMandriva特有の問題を超えて、コミュニティ運営型のオープンソースプロジェクトおよび企業内のCI/CDパイプライン運営一般に適用される、いくつかの構造的な指針として整理できます。
- 管理者権限の付与に対する最小権限原則の徹底:Beatrici氏の権限は「リポジトリのミラー作業のため」に付与されたものですが、その権限は同時に「リポジトリの削除」や「パッケージのpublish」といった破壊的な操作にも使用可能でした。GitHubやGitLab、RPMビルドパイプラインでは、role-based access controlで書き込み権限と破壊的権限を分離可能な場合が多く、ミラーやバックアップ作業に必要な権限を読み取り中心に限定し、リポジトリ削除、設定変更、パッケージ公開などの破壊的権限を別ロールへ分離する運用を検討します。
- 離脱またはトラブル発生時の管理者権限の即時剥奪:Beatrici氏はプロジェクトを離脱した後も管理者権限を保持していました。コントリビューター離脱、離職、または内部トラブル発生時に該当者の全システム上の権限を即時に見直し・剥奪するプロセスは、GitHub organizationの管理者にとって明確に定義されているべきです。
- 単一コントリビューター依存のインフラ構造の解消:Beatrici氏個人のOneDevインスタンスをミラー先として利用していた構成には、一個人の管理する外部インフラへ運用が依存するリスクがありました。同種のミラー/バックアップは複数の独立した場所(異なるプロバイダ、異なる管理者)に分散させることで、単一コントリビューターの離脱や敵対的行動に対する耐性を確保できます。
- 破壊的操作のペア承認またはauditログの必須化:パッケージmanifestの`Obsoletes:`ディレクティブのような、下流のユーザ環境に大規模な変更を及ぼす可能性のある要素については、単一コントリビューターの単一操作で反映されない設計にすることが望ましいです。GitHub上でのbranch protection rulesと同様、パッケージビルドパイプラインでも「特定のディレクティブを含む変更には別の承認が必要」というルール設定が有効です。
- Cooker等の開発ブランチでのユーザ側の防衛策:Cookerを直接利用する環境では、DNFが提示するトランザクション内容、とくに大量のパッケージ削除や`Obsoletes:`による置き換えを更新前に確認します。無条件で`-y`オプションを使うワークフローや自動更新スクリプトは、こうした操作を無警戒に通してしまう可能性があります。定期スナップショット(Btrfs snapshotやZFS snapshot)の運用も、Cooker利用者にとって現実的な最終防御ラインです。
- コミュニティ内対立の早期検知と正式な調停プロセス:本件の遠因には、非公開のメッセージを含むコミュニティ内での攻撃的な言動があったとOpenMandriva側は説明しており、AngryPenguin氏自身も「もっと早く対応すべきだった」と表明しています。オープンソースプロジェクトの運営には、攻撃的な言動の早期検知、正式な調停プロセス、およびエスカレーション時の管理者権限見直し手順を明文化することが、間接的にサプライチェーン防衛の一部として機能します。
OpenMandriva事件は、記事執筆時点で復旧作業が進められている事案ですが、xz-utils事件と並べて見れば、Linuxディストロやオープンソースプロジェクトが依存する「信頼されたコントリビューター」というモデルの脆さを、まったく異なる方向から示す事例です。信頼を前提とすること自体は共同開発の効率にとって不可欠ですが、その信頼が単一障害点(single point of failure)にも単一破壊点(single point of destruction)にもなり得ることを、権限モデルとバックアップ戦略の設計に反映させておく必要があります。
一次情報・公式情報
- Statement regarding attempted distribution sabotage(OpenMandriva公式フォーラム、AngryPenguin氏、2026年7月8日15:43 UTC)
- OpenMandriva Release Plan and Repositories(OpenMandriva公式Wiki、Cooker/ROME/Rockの区分)
- Restoring a deleted repository(GitHub Docs、90日以内復元・fork network制約・team permissions非復元の仕様)
- Dependencies(rpm.org公式ドキュメント、Obsoletesディレクティブの動作仕様)
参考情報
- OpenMandriva: Statement regarding attempted distribution sabotage(LWN.net、2026年7月9日)
- OpenMandriva Linux says contributor tried to sabotage the project(BleepingComputer、2026年7月10日、Beatrici氏の反論を含む)
- OpenMandriva claims disgruntled admin trashed repos after community bust-up(The Register、2026年7月9日)
- OpenMandriva GitHub Disrupted & Nefarious Package Push In Sabotage Attempt(Phoronix、2026年7月8日)
- OpenMandriva Says Former Contributor Sabotaged Its Repositories(Linuxiac、2026年7月8日)
- In an Angry Fit, Dev ‘Sabotages’ OpenMandriva Repository(FOSS Force、2026年7月9日)
- CVE-2024-3094(xz-utils backdoor事件、参考:内部脅威系譜)
コメント