Firefox 154更新、脆弱性58件とESR移行の要点

【更新 2026-08-24】本記事を見直し、修正しました。主な修正点：Mozillaの内部発見バグに付く定型評価の引用を MFSA 2026-74 の実際の文言に合わせ（同アドバイザリに「任意コード実行」の記載はありません）、ChromeとEdgeでローカルネットワークアクセス制限が既定になったバージョンをChrome 142／Edge 143に訂正し、IPAガイドラインのリンクをガイドライン本体のページに差し替えました。あわせて、グラフィックス系の修正件数に要確認の注記を追加しています。

Mozillaは2026年8月18日、Webブラウザ「Firefox 154」を公開し、58件の脆弱性を修正しました。深刻度「高（High）」が20件含まれます。同日に法人向けの延長サポート版（ESR）153.1／140.14／115.39、メールクライアントのThunderbird 154／153.1／140.14も更新されています。現時点で悪用を確認したという公式発表はありません。

ただし情シスにとって、今回は「パッチを当てて終わり」ではありません。ESR 140は2026年9月29日にサポート終了を迎え、後継のESR 153ではローカルネットワークアクセス（LNA）の許可制が既定で効きます。SaaSの画面から社内の複合機・ICカードリーダー・常駐エージェントに接続するような業務があると、移行後に許可を求めるダイアログが出て問い合わせが集中しかねません。今のうちに洗い出しておくべき論点です。

この記事でわかること

Firefox 154／ESR 3系統で何件・どんな脆弱性が修正されたか
ESR 140のサポート終了期限と、ESR 153へ移行するときの注意点
ローカルネットワークアクセス（LNA）制限とは何か、どの業務が止まりうるか
Firefoxのグループポリシーで業務影響を事前に回避する方法

何が起きたのか：Firefoxの4系統が同時に更新された
1. どの脆弱性に注目すべきか
ローカルネットワークアクセス（LNA）とは何か
1. どのアドレスが「ローカル」扱いになるのか
2. 「うちは関係ない」と即断しない
影響を受ける環境：ESR 140利用組織は9月29日が期限
情シスが事前に潰しておくべき業務影響
現場目線の課題：期限は分かっていても手が回らない
情シスはどうすべきか
まとめ
出典

何が起きたのか：Firefoxの4系統が同時に更新された

Mozillaは2026年8月18日付でセキュリティアドバイザリ（MFSA）を公開し、Firefoxのリリース版とESR 3系統、およびThunderbirdを同時に更新しました。修正件数は次のとおりです。

アドバイザリ	対象バージョン	修正件数	内訳（高／中／低）
MFSA 2026-74	Firefox 154	58件	20／26／12
MFSA 2026-77	Firefox ESR 153.1	52件	19／23／10
MFSA 2026-76	Firefox ESR 140.14	31件	15／14／2
MFSA 2026-75	Firefox ESR 115.39	13件	10／3／0
MFSA 2026-78〜80	Thunderbird 154／153.1／140.14	―	Firefox側と共通の修正を反映

アドバイザリ全体の深刻度は「高（high）」で、「緊急（Critical）」に分類された脆弱性は今回ありません。58件は多く見えますが、Firefoxはリリース間隔が約4週間と短く、内部のファジングで見つかったメモリ安全性の問題をまとめて計上するため、この規模は珍しくありません。件数に慌てるより、更新が行き渡っているかどうかが実務上の論点です。

どの脆弱性に注目すべきか

結論から言えば、Web閲覧だけで悪用されうる「高」20件、なかでもサンドボックスの外に出る系統です。高危険度の内訳を見ると、傾向がはっきりしています。

CVE-2026-75874：Remote Settings Clientコンポーネントのサンドボックス脱出。ブラウザの隔離機構を越えられるため、他の脆弱性と組み合わされると影響が大きくなります
グラフィックス処理に集中：CanvasWebGL、Canvas2D、ImageLib、テキスト描画などで解放済みメモリ参照（use-after-free）や権限昇格が~~計10件超~~ 【要確認 2026-08-24：MFSA 2026-74 で Graphics 系コンポーネント（Graphics: CanvasWebGL／Canvas2D／ImageLib／Text ほか）に該当するのは「高」20件中9件、全深刻度で数えると16件です。どちらの範囲を指した件数か確認が必要】。画像やWebGLコンテンツを表示するだけで踏みうる箇所です
JavaScriptエンジン：WebAssemblyとガベージコレクタのuse-after-free、緩和策バイパス（CVE-2026-74936〜74938）
CVE-2026-74987／74988／74990：Mozillaが内部発見したメモリ安全性の問題。「一部にメモリ破壊などの痕跡があり、十分な労力をかければ悪用され得たと推定される」という定型の評価が付きます

中危険度にも、Cookie関連の同一オリジンポリシー回避（CVE-2026-74963）、Service Workersの同一オリジンポリシー回避（CVE-2026-74956）、フォーム自動入力からの情報漏えい（CVE-2026-74966）など、業務データに触れうるものが含まれます。「中だから後回し」と機械的に判断せず、少なくとも次の定例更新までには当てておきたいところです。

ローカルネットワークアクセス（LNA）とは何か

ローカルネットワークアクセス（LNA）とは、Webサイトが利用者の社内ネットワークや端末内部（localhost）へ接続しようとしたとき、ブラウザが利用者の許可を求めて遮断する仕組みです。Firefoxでは153から既定で有効になり、今回の154でWebSocket接続にも適用範囲が広がりました。これまで通常のHTTPリクエストだけが対象で、WebSocketは素通りしていた抜け道がふさがれた形です。

背景には、公開Webサイトから社内側を叩く攻撃が現実にあることがあります。閲覧しただけのサイトがプライベートIPをスキャンして機器を特定したり、ルータや複合機の管理画面にCSRF（クロスサイトリクエストフォージェリ）で設定変更を仕掛けたりする手口です。当サイトで扱ったRDK-BのWebUIの脆弱性5件やQNAP NASのCSRF脆弱性のような「社内機器の管理画面」が、まさにLNAの守ろうとしている対象です。

どのアドレスが「ローカル」扱いになるのか

仕様（WICG Local Network Access）では、アドレス空間を3つに分けています。

区分	主な範囲
ループバック	127.0.0.0/8、::1/128 など（端末自身）
ローカル	10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16、100.64.0.0/10、fc00::/7、fe80::/10、および `.local` ドメイン
パブリック	上記以外

ポイントは、より公開度の高い側から、より内側へ向かう通信だけが許可制になることです。つまり「インターネット上のサイト → 社内IP」「インターネット上のサイト → localhost」「社内のイントラサイト → localhost」が対象で、社内のイントラWebアプリをブラウザで直接開く操作そのものは対象外です。この線引きを取り違えると影響範囲を過大に見積もることになるので、注意してください。

「うちは関係ない」と即断しない

実務で効いてくるのは、クラウド側の画面が端末内の常駐アプリと通信するタイプの業務です。ICカードリーダーや電子証明書のミドルウェア、ラベルプリンタ・レシートプリンタの連携ツール、スキャナ取り込みユーティリティ、一部のWeb会議クライアントなどは、localhostで待ち受けるヘルパーを常駐させ、SaaSの画面からそこへ接続する構成が広く使われています。この形はまさに「パブリック → ループバック」であり、LNAの許可対象です。

自社が該当するかは、次の観点で確認できます。SaaSを使う業務端末で netstat -ano（Windows）を実行し、127.0.0.1で待ち受けているプロセスを洗い出す。あるいは、業務アプリのインストール時に「常駐アプリ」「ブリッジ」「ヘルパー」といった名前のコンポーネントが同時に入っていないかを確認する。該当があれば、そのSaaSベンダーにLNA対応状況を問い合わせるのが確実です。

なお、これはFirefoxだけの動きではありません。Chromeは2025年10月28日公開のChrome 142で許可プロンプトを既定導入し（それ以前はフラグによる試験導入でした）、Chromium系のEdgeもEdge 143から既定で有効になっています。ブラウザ全体の流れです。「標準ブラウザはChromeだから無関係」ということにはなりません。

影響を受ける環境：ESR 140利用組織は9月29日が期限

企業でFirefoxを配布している場合、多くはESR（延長サポート版）を使っているはずです。ここで期限が迫っています。

ESR 153は2026年7月21日にリリース済み。今回の更新で153.1になりました
ESR 140は2026年9月29日でサポート終了。以後はセキュリティ更新が提供されません
ESR 115はWindows 7／8.1や古いmacOS向けに延長提供されている系統で、今回115.39が公開されました

そして重要なのが、LNAを制御するグループポリシーはFirefox 145以降／ESR 153以降でしか使えない点です。ESR 140を使っている組織は今のところLNAの影響を受けていませんが、ESR 153へ上がった瞬間にまとめて顕在化します。「9月末の移行期限」と「LNAの業務影響」が同時に来ると考えて準備してください。

情シスが事前に潰しておくべき業務影響

Firefoxには LocalNetworkAccess というエンタープライズポリシーが用意されており、Windowsのグループポリシー（GPO）、macOSのplist、policies.json のいずれからでも設定できます。設定項目は次のとおりです。

設定項目	内容
`Enabled`	LNA保護そのものの有効／無効
`EnablePrompting`	利用者への許可プロンプトを出すかどうか
`BlockTrackers`	サードパーティのトラッカーによるローカル接続を遮断（実験的機能）
`SkipDomains`	チェックを免除するドメインの配列。`*.example.com` のようなワイルドカード指定が可能
`Locked`	利用者による変更を禁止

現実的な進め方は、LNAを無効化するのではなく、業務で必要なドメインだけを SkipDomains で例外にすることです。Enabled を false にすれば確かに問い合わせは止まりますが、それはルータ・複合機を狙うCSRFやローカルスキャンに対する防御を丸ごと捨てることを意味します。例外は「どのSaaSが、どの常駐アプリに、なぜ接続するのか」を台帳化したうえで最小限にとどめ、定期的に棚卸ししてください。

現場目線の課題：期限は分かっていても手が回らない

この手の「ブラウザの仕様変更で業務が止まる」問題のやっかいなところは、止まるまで誰も気づかないことにあります。ESRの移行計画は立てられても、「その端末で誰がどのSaaSを使い、その裏でどんな常駐アプリが動いているか」までは、情シスの側から完全には見えません。部門が自分たちで契約したSaaSであればなおさらです。結局、移行当日に「印刷できない」「カードリーダーが反応しない」という問い合わせが来て、そこで初めて構成を知る——という経験をした方も多いのではないでしょうか。

加えて厄介なのが、Firefoxを「標準ブラウザではないが、特定の業務システムのためだけに残してある」というケースです。台帳上は主要ブラウザとして扱われないため更新計画から漏れやすく、しかしその業務システムは止められません。9月29日という期限は、こうした「見えていないFirefox」を棚卸しする良い機会でもあります。

情シスはどうすべきか

個別の設定手順はベンダー公式ドキュメントに任せ、体制面は公的機関の指針に沿うのが結局は近道です。

まずは更新の適用状況を可視化する：ヘルプ＞Firefoxについて、または資産管理ツールでバージョンを確認。ESR 140が残っていれば9月29日までの移行計画を立てる
ESR 153の検証環境でLNAプロンプトの有無を確認する：主要な業務SaaSを実際に操作し、許可を求められる箇所を洗い出す
脆弱性管理と資産管理の枠組みを整える：IPA「中小企業の情報セキュリティ対策ガイドライン」が、限られた人員でどこから手を付けるかの優先順位を示しています
利用者向けの啓発を怠らない：LNAのようなプロンプトは、意味が分からないまま「許可」を押されると保護が無効化されます。IPA「対策のしおり」などを使い、「見覚えのない許可要求は許可しない」を周知しておくことが、地味ですが効きます

ブラウザ更新の重要性そのものについては、Firefox 153・ESR更新の記事やFirefox for Androidの情報漏えい脆弱性もあわせてご覧ください。

まとめ

Firefox 154で脆弱性58件（高20件）を修正。ESR 153.1／140.14／115.39、Thunderbirdも同日更新。緊急（Critical）はなく悪用の公式報告もありませんが、サンドボックス脱出とグラフィックス系のメモリ破壊が中心なので早期適用が望まれます。
ESR 140は2026年9月29日でサポート終了。ESR 153への移行計画を今すぐ確認してください。移行と同時にローカルネットワークアクセス制限が効き始めます。
SaaSとlocalhost常駐アプリを組み合わせた業務は許可プロンプトの影響を受けます。LocalNetworkAccess ポリシーの SkipDomains で必要最小限の例外を作り、保護そのものは無効化しないでください。