Mozilla、Firefox・Thunderbirdの署名用GPG鍵を交換 GitHubリポジトリへの誤コミットが原因、不正アクセスの証拠はなし|セキュリティとITのニュース-セキュリティ対策Lab

投稿日時: 2026年08月13日更新日時: 2026年08月13日

Mozillaは2026年8月10日、FirefoxおよびThunderbirdの一部リリース成果物（Linux用tarball、RPMパッケージ、チェックサムファイル）に使用しているGPG署名用サブキーを、新しいものに交換したと公式セキュリティブログで発表しました。原因は、これまで使用していた秘密鍵の暗号化されていないコピーが、誤ってプライベートなGitHubリポジトリにコミットされていたことです。Mozillaは監査ログを確認したうえで、第三者による不正アクセスの証拠は確認されていないとしています。

この記事のサマリー

Mozillaは2026年8月10日、Firefox・ThunderbirdのLinux用tarball、RPMパッケージ、チェックサムファイルの署名に使用しているGPGサブキーを、新しいものに交換したと発表しました。
原因は、従来使用していた秘密鍵の暗号化されていないコピーが、誤ってプライベートなGitHubリポジトリにコミットされていたことです。
当該リポジトリへのアクセスはMozilla社内の少人数のグループに限定されており、そのメンバー全員が、他の正規の手段を通じて元々この鍵へのアクセス権を持っていた人物でした。
Mozillaが利用可能な監査記録を確認した結果、この鍵がリポジトリに存在していた間に第三者からアクセスされた証拠は見つかっていません。
Mozillaは旧鍵を失効させ、新しい鍵を発行するとともに、同様の事案の再発を防ぐための安全対策を追加したとしています。
ほとんどの利用者は対応不要ですが、GPG署名を手動で検証している利用者と、Firefox RPMパッケージを利用している利用者の一部は、対応が必要な場合があります。

整理表

項目	内容
発表日	2026年8月10日
発表元	Mozilla（公式セキュリティブログ）
対象	Firefox・Thunderbirdの一部リリース成果物（Linux用tarball、RPMパッケージ、チェックサムファイル）
原因	秘密鍵の暗号化されていないコピーが、誤ってプライベートなGitHubリポジトリへコミットされていた
不正アクセスの証拠	監査ログの確認範囲では確認されていない
リポジトリへのアクセス範囲	Mozilla社内の少人数のグループ、全員が別の正規手段で元々鍵へのアクセス権を保有
対応	旧鍵の失効、新しい署名用サブキーの発行、再発防止策の追加
新しい鍵のフィンガープリント	827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3
一般利用者への影響	ほとんどの利用者は対応不要
対応が必要な利用者	GPG署名を手動検証している利用者、Firefox RPMパッケージの一部利用者
Thunderbirdへの影響	公式RPMパッケージを提供していないため、RPM関連の対応は不要

何が起きたか

Mozillaによると、Firefox・Thunderbirdの一部リリース成果物の署名に使用しているGPGサブキーの、暗号化されていないコピーが、誤ってプライベートなGitHubリポジトリにコミットされる事案が発生しました。このリポジトリへのアクセスは、Mozilla社内の少人数のグループに限定されており、そのメンバーは全員、別の正規の手段を通じて、元々この鍵へのアクセス権を保有していた人物だったとしています。

一般的に、ソフトウェアのリリース署名に使われるGPGの秘密鍵が流出した場合、これを入手した攻撃者は、悪意あるファイルに対して正当な署名を作成できてしまいます。これはサプライチェーン攻撃のリスクを伴います。攻撃者が改変・悪意あるバージョンのソフトウェアを、正規のものであるかのように配布できてしまう可能性があるためです。ただし、この悪用が実際に成立するには、攻撃者が署名済みの不正ファイルを利用者に届ける別の手段（侵害されたミラーサイト、代替のダウンロード経路、ソーシャルエンジニアリング等）も必要になります。

Mozillaは、利用可能な監査記録を確認した結果、この鍵がリポジトリに存在していた期間中に、第三者によってアクセスされた証拠は見つかっていないとしています。とはいえ、暗号化されていない秘密鍵をソースコード管理システム内に置いたままにしておくことが望ましくないのは明らかであり、Mozillaは念のため、露出した鍵を失効させ、新しい鍵に交換する対応を取りました。近年、ソフトウェアサプライチェーンを狙った攻撃が相次いで報告されている状況を踏まえ、鍵が露出した兆候が見られた時点で速やかにローテーションを行うという判断は、多くの組織で採用されつつある実務的な対応でもあります。

利用者側で必要な対応

Mozillaは、ほとんどの利用者にとって、今回の鍵の交換に伴う対応は不要だとしています。対応が必要になるのは、主に次の2つのケースです。

1つ目は、Mozillaが提供するGPG署名を手動で検証している利用者です。この場合、新しい署名用鍵と、旧鍵の失効情報の両方をインポートする必要があります。新しい鍵のフィンガープリントは「827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3」で、これと一致することを確認したうえで鍵を受け入れるよう、Mozillaは呼びかけています。

2つ目は、FirefoxのRPMパッケージを利用している利用者です。Fedora 43以降を利用している場合、次回のFirefoxアップデート時にdnfが更新された鍵を自動的にダウンロードし、利用者はそのインポートを承認するだけで済むとされています。一方、Fedora 42以前、RHEL、Rocky Linux、AlmaLinux、openSUSE、SUSEを利用している場合は、旧鍵を手動で削除し、新しい鍵を手動でインポートする必要があります。また、旧鍵の失効情報をインポートした後は、通常の署名検証プロセスにおいて、失効した旧サブキーで署名された過去のリリースが検証エラーとして扱われるようになる点にも注意が必要です。なお、Thunderbirdは公式のRPMパッケージを提供していないため、RPM関連の対応は不要です。

情報システム部門が確認すべき対策ポイント

組織内でFirefox・Thunderbirdのリリースファイルを手動でGPG検証する運用を行っている場合、新しい鍵のフィンガープリント（827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3）を確認したうえで、鍵と失効情報をインポートしてください。
LinuxディストリビューションでFirefoxをRPMパッケージ経由で配布・管理している場合、利用しているディストリビューションのバージョンに応じて、自動更新で対応できるか、手動での鍵の入れ替えが必要かを確認してください。
自社の開発・リリースプロセスで、署名用の秘密鍵や認証情報が、暗号化されずにソースコード管理システムにコミットされていないか、シークレットスキャンツールを用いて点検してください。今回の事案は、Mozillaのような大手組織でも、正規のアクセス権を持つ担当者による誤操作によってこの種の露出が起きうることを示しています。
署名鍵・認証情報が誤って公開・限定公開のリポジトリに含まれてしまった場合の対応手順（鍵の失効、再発行、影響範囲の監査、利用者への告知）を、あらかじめ整備しておくことをおすすめします。GitHubの内部リポジトリ侵害を受けてGitHub自身が署名鍵をローテーションした事例については、GitHubがGHES 3.20.3をリリース-事前認証SSRFが可能な脆弱性を修正でも解説していますので、あわせてご参照ください。