注目

インシデント / INCIDENT / SOFTWARE SUPPLY CHAIN

Mozilla、Firefox/ThunderbirdのGPG署名キーを緊急失効・交換 — 秘密鍵がGitHubのプライベートリポジトリに誤公開

Mozillaは2026年8月10日、FirefoxとThunderbirdのリリース署名に使うGPG署名サブキーを交換した。暗号化されていない秘密鍵のコピーが社内のプライベートGitHubリポジトリに誤ってコミットされたためで、監査では不正アクセスの証拠は確認されていない。旧キーは失効済みで、RPMパッケージ利用者は配布元に応じた手動対応が必要になる場合がある。

Mozillaは2026年8月10日、ブラウザ「Firefox」とメールソフト「Thunderbird」のリリース成果物に付与するGPG署名に使う署名サブキーを交換したと発表した。Linux向けのtarball(圧縮アーカイブ)、RPMパッケージ、チェックサムファイルなどの署名に使っていた鍵で、暗号化されていない秘密鍵のコピーが、社内のプライベートGitHubリポジトリに誤ってコミットされたことがきっかけだ。

Mozillaのリリースエンジニアリング担当であるBen Hearsum氏がセキュリティブログで公表した。同氏は「利用可能な監査記録を調査した結果、鍵がリポジトリにある間に不正な第三者によってアクセスされた証拠は見つからなかった」と説明している。リポジトリへのアクセスはMozilla内の少数の開発者に限定されており、彼らはすでに他の手段で鍵への正規のアクセス権を持っていたという。

何が起きたのか

GPG(GNU Privacy Guard)は、ファイルやメッセージに「電子署名」を付けるための仕組みだ。ソフトウェアの配布元は、配布ファイルに自分の秘密鍵で署名を付け、利用者は公開鍵でその署名を検証する。これにより「このファイルは確かに配布元が作ったもので、改ざんされていない」ことを確認できる。

今回の問題は、その署名に使う秘密鍵(サブキー)のコピーが、暗号化されないまま社内リポジトリに置かれてしまったことだ。もし秘密鍵が漏えいすれば、攻撃者が正規の署名を偽造し、悪意あるファイルを本物のFirefoxのように見せかけて配布できる——つまりサプライチェーン攻撃の入り口になり得る。

Mozillaは漏えいの証拠はないとしているが、リスクを排除するため、旧サブキーを失効させ、新しいサブキーを発行した。あわせて、同様の問題を防ぐための追加の保護策を導入したと述べている。

新旧のキーの情報

  • 旧キー(失効済み): フィンガープリント 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353
  • 新キー(現在の署名用サブキー): フィンガープリント 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3(有効期限: 2028年8月5日)

新しい公開鍵と旧キーの失効証明書は、Mozillaの公開サーバー(archive.mozilla.org のNightly配布ディレクトリ)やkeys.openpgp.orgから取得できる。なお、GPGの仕組み上、失効証明書をインポートした後は、旧キーで署名されたリリースを検証できなくなる点に注意が必要だ。

誰が対応すべきか

Mozillaは「ほとんどの利用者には追加の対応は不要」と明言している。対応が必要なのは次の2つのケースだ。

  1. GPG署名を手動で検証している利用者 — 新しい署名キーをインポートし、旧キーの失効証明書を取り込む必要がある
  2. FirefoxのRPMパッケージを利用している環境 — パッケージ管理ツールの種類によって手動対応が必要な場合がある(詳細は下記)

Thunderbirdは公式のRPMパッケージを提供していないため、RPM関連の対応は不要とされている。

RPM利用者の対応手順

RPMパッケージ管理ツールは、GPGキーの更新・失効の扱い方がツールによって異なる。配布元ごとの対応は次のとおり。

環境 対応
Fedora 43以降 追加対応は不要。次の更新時にdnfが新しいキーを自動取得し、インポートの確認を求められる。表示されるフィンガープリントが 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3 であることを確認して承認する
Fedora 42以前 / RHEL / Rocky Linux / AlmaLinux 手動でのキー入れ替えが必要。更新時に「Import of the key didn’t help」などのエラーで失敗する
openSUSE / SUSE系 同様に手動でのキー入れ替えが必要。zypperがキーを自動で置き換えられず、「Signature verification failed」や「NOKEY」エラーになる

Fedora 42以前・RHEL系・openSUSE系での手動対応手順は次のとおり。

# 1. 旧キーを先に削除する(重要: 削除せずにインポートすると、更新が成功したように見えて実際には反映されない)
sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353

# 2. 新しいキーをインポートする
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg

# 3. パッケージ情報をクリアして更新を再試行する
# Fedora/RHEL系の場合:
sudo dnf clean all
# openSUSE/SUSE系の場合:
sudo zypper refresh

注意: rpm --import を実行する前に、必ず旧キーを削除すること。旧キーが残ったままインポートすると、コマンドが成功したように見えてもキーが更新されない。

今何をすべきか

  1. 自分が該当するか確認する — Firefoxを通常のダウンロード(Windows/macOS/Linuxのtarball)で使っている場合は対応不要。RPMパッケージ(特にFedora 42以前、RHEL、Rocky、AlmaLinux、openSUSE、SUSE)を運用しているサーバーやPCがある場合は、上記の手順でキーを入れ替える
  2. GPG署名を検証する運用を見直す — 組織内でソフトウェア配布の署名検証を自動化している場合は、新キーのフィンガープリントを許可リストに追加し、旧キーの失効を反映する
  3. 鍵管理の点検に活かす — 自組織でも、秘密鍵がリポジトリやバックアップ、共有ストレージに平文のまま残っていないか確認する。暗号化されていない秘密鍵の取り扱いは、漏えいリスクを常にはらむ

ソフトウェアの署名鍵は「信頼の起点」だ。鍵の漏えいを疑った場合、攻撃の証拠が見つからなくても、鍵を失効させて交換するのが安全側の判断になる。今回のMozillaの対応は、そのプロセスの見本と言える。

出典: Mozilla Security Blog — Updated GPG key for signing Firefox and Thunderbird Releases(2026年8月10日)

この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。