こんにちは、美空です。
Unityからセキュリティ修正のメールが届いたんだけど、件名を見てちょっとドキッとしちゃいました。
「Unity Platform Protection: Take action to address vulnerabilities」
しかも本文を読んでみると、Remote Code Execution（リモートコード実行）なんて物騒な言葉まで登場します！
えっ、これってUnityで作ったゲームが危険ってこと？
公開済みのゲームも全部ビルドし直さなきゃいけないの？
そんな疑問が浮かんだので、Unityが公開しているセキュリティアドバイザリを詳しく読んでみました。
すると、今回の問題は思っていたよりも影響範囲が明確になっていて、どんな場合に対応が必要なのかも具体的に説明されています。
もちろん、セキュリティの問題だから軽く考えていいわけじゃない。
でも、必要以上に怖がるのも違うと思います。
大切なのは、脆弱性の名前や深刻度だけを見るのではなく、実際にどういう条件で問題が発生するのかを知ること。
今回はUnity開発者の立場から、影響範囲と必要な対応を一緒に確認してみよう！
まず結論！ すべてのUnity製アプリケーションが危険なわけじゃない
今回Unityが案内したセキュリティ問題は2つ。
| 問題 | 概要 |
|---|---|
| Brotliデコーダーの脆弱性 | 細工された圧縮データの展開によって、メモリー破壊やコード実行につながる可能性 |
| eMudhra認証局の侵害 | 不正な証明書を悪用されることで、暗号化通信が盗聴・改ざんされる可能性 |
両方とも対策が必要な問題だけれど、実は原因も攻撃が成立する条件もまったく違います。
そして今回、特に強調しておきたいのがこちら。
UnityWebRequestとAssetBundleの標準機能は、今回のBrotliデコーダー脆弱性の直接の対象ではない。
これは私の推測じゃなくて、Unity公式のアドバイザリにも明記されていること。
ただし、これはあくまでBrotliの問題についての話。
UnityWebRequestによるHTTPS通信が、もう一方のeMudhraの問題と無関係になるわけではないし、取得したデータを別のライブラリでBrotli展開しているなら話は変わってくる。
この2つの問題は分けて考える必要があります。
Brotliの脆弱性って、何が問題なの？
まずはBrotliの方から。
BrotliはGoogleが開発したオープンソースのデータ圧縮技術で、Webコンテンツの転送などに広く使われているもの。
Unityにも.NETランタイムのクラスライブラリを通じてBrotliのデコーダーが含まれています。
今回発見されたのは、細工されたBrotli圧縮データを展開する際に、メモリーの範囲外へ書き込みが行われる可能性があるという問題。
識別番号は CVE-2026-111497。
CVSS v4.0のスコアは9.2で、深刻度の高い脆弱性として扱われている。
悪用されると、アプリケーションのクラッシュやメモリー内情報の漏えい、条件によっては任意のコードの実行につながる可能性がある。
ただ、ここで確認しておきたいことがあるの。
Brotliを使っているだけで危険なの？
答えはNO。
Unity公式によれば、今回の問題でアプリケーションが攻撃にさらされるのは、攻撃者が制御できるBrotli圧縮データを、影響を受けるデコーダーで展開する場合。
たとえば、こんな処理が確認対象になる。
-
外部サーバーから受信したBrotli圧縮データを展開する
-
ユーザーがアップロードしたBrotli圧縮データを読み込む
-
UGC（ユーザー生成コンテンツ）に含まれる圧縮データを展開する
-
サードパーティー製プラグインが外部データをBrotliで展開する
注意したいのは、データを受信したこと自体ではなく、そのデータが影響を受けるデコーダーに渡されるかどうか。
反対に、Brotli圧縮データを展開する処理がない場合や、アプリケーション自身が生成・管理している信頼できるデータだけを展開している場合、Unity公式は今回の問題にはさらされないと説明している。
セキュリティの深刻度は高いけれど、実際のアプリケーションへの影響は、その使い方次第ということです。
注意が必要なC#のAPI
Unity公式が影響を受ける可能性のあるAPIとして挙げているのは、主に次の3つ。
| API | 確認すべき条件 |
|---|---|
System.IO.Compression.BrotliStream |
信頼できないBrotliデータを展開している |
System.IO.Compression.BrotliDecoder |
信頼できないBrotliデータを展開している |
System.Net.Http.HttpClient |
Brotliの自動展開が有効になっている |
たとえば、次のようなコード。
using System.IO;
using System.IO.Compression;
public static byte[] DecompressBrotli(byte[] data)
{
using var input = new MemoryStream(data);
using var decoder = new BrotliStream(
input,
CompressionMode.Decompress);
using var output = new MemoryStream();
decoder.CopyTo(output);
return output.ToArray();
}これはBrotliStreamを利用した一般的な展開処理の例で、このコードそのものが不正というわけじゃない。
問題は、引数のdataに、どこから取得したデータが渡されるかということ。
攻撃者が用意した圧縮データを受け取って、そのまま脆弱なデコーダーに渡すような処理は確認が必要になる。
なお、上記はAPIの利用箇所を説明するための簡略化したコードで、展開サイズの制限や入力データの検証などは省略しているよ。本番アプリケーションで使う場合は、圧縮爆弾など別のリスクへの対策も必要になる。
もう一つ気を付けたいのがHttpClient。
HttpClientを利用しているだけで危険というわけじゃないけれど、Brotliによる自動展開を有効にしている場合は確認しておきたい。
そして、自分のソースコードに該当処理がなくても、導入したDLLやネイティブプラグインの内部で使われている可能性がある点にも注意が必要。
UnityWebRequestとAssetBundleが対象外なのはなぜ？
ここが今回の記事で一番伝えたかったところ！
Unity公式の説明では、UnityWebRequestが使用するHTTPライブラリは、Brotliをサポートしない構成でビルドされている。
つまり、UnityWebRequestの標準的な通信処理では、今回の脆弱性があるBrotliデコーダーを使わないということ。
同様に、AssetBundleなどUnityの標準アーカイブ形式で使用される圧縮方式は、LZ4、LZ4HC、LZMA。
Brotliは使用されていません。
整理すると、こんな感じ。
| Unityの機能・処理 | 今回のBrotli脆弱性 |
|---|---|
| UnityWebRequestの標準HTTP処理 | 対象外 |
| AssetBundleの標準読み込み | 対象外 |
| Unity標準のフォント読み込み | 対象外 |
| WebGLビルドファイルのBrotli圧縮 | Unityランタイムの今回の問題は対象外 |
| BrotliStreamによる外部圧縮データの展開 | 条件次第で対象 |
| Brotli自動展開を有効にしたHttpClient | 条件次第で対象 |
| サードパーティーのBrotliデコーダー | 実装・使用バージョン・入力条件の確認が必要 |
WebGLでもBrotliを使っているんじゃないの？
そう思った人、いると思います？
UnityのWebGLビルドでは、配信用ファイルをBrotliで圧縮できますよね。
でも、これは少し仕組みが違います。
WebGLのビルドファイルは、配信時にブラウザー側で展開されています。
つまり、今回問題になっているUnityランタイム内のBrotliデコーダーで展開しているわけじゃないんです。
つまり同じBrotliという名前でも、どの実装が処理しているかは違うんです。
ただし、ブラウザー自身のBrotli実装に関するセキュリティ問題は別に評価する必要があるし、WebGLアプリケーション内部で独自にBrotliデータを展開している場合は、その実装も確認対象になります。
UnityWebRequestで取得していれば何でも安全？
それも違うので注意してください。
たとえば、UnityWebRequestでサーバーからデータを取得して、そのあとC#のBrotliStreamで展開するようなプログラムだったら？
この場合、UnityWebRequest自体は問題なくても、後段の展開処理は今回の影響を受ける可能性があります。
ここで大切なのは、データをどう受信したかではなく、最終的にどのデコーダーで処理したかということ。
eMudhraの問題はBrotliとはまったく別
続いて、もう一つの問題。
eMudhraはデジタル証明書を発行する認証局（CA）。
2026年10月20日に、eMudhraの中間認証局の秘密鍵8件が侵害されたことが公表されました。
これがどういう問題なのかというと、悪意のある第三者が不正なサーバー証明書を作成できる可能性が生まれるということです。
通常、HTTPS通信ではサーバー証明書を使って通信先の正当性を確認しています。
ところが、侵害された鍵を使った偽の証明書を信頼してしまうと、攻撃者が正規のサーバーになりすまして通信の内容を盗み見たり、改ざんしたりする可能性があります。
ただし、攻撃を成立させるには、攻撃者が通信経路に割り込めることなどの条件も必要になります。
つまり、eMudhraの問題があるからといって、インターネットに接続したUnityゲームが無条件に乗っ取られるわけではありません。
UnityTLSとOSの証明書管理
Unityが説明しているポイントは、UnityTLSがOSから信頼されたルート証明書を取得するという仕組みです。
ただし、証明書チェーンの検証方法はプラットフォームによって異なります。
WindowsではOS側に検証を委ねる一方、macOSやLinuxなどではUnityTLS自身が証明書チェーンを検証するため、OSが問題の中間証明書だけをブロックしても十分ではない場合があります。
そのため、問題のある認証局をどのように信頼対象から外すかが重要になります。
これはUnityアプリケーションだけで完結する話ではなく、OSやプラットフォーム側のセキュリティ更新と合わせて考える必要があるということですね。
プラットフォームごとの影響
Unity公式が2026年10月30日時点で公開した評価を整理すると、次のようになります。
| プラットフォーム | Unity公式の評価と対応 |
|---|---|
| Windows / Xbox / UWP | Microsoftの2026年10月20日の証明書更新が適用されていれば保護される |
| WebGL | ブラウザー側で対象証明書をブロック済み |
| Android | 2026年10月のGoogle Play Services更新でゲーム側は保護される |
| macOS / iOS | 公式評価では影響あり。Unity修正版とApple側の対応状況を確認 |
| Ubuntu | 対策済みca-certificatesパッケージが適用されていれば保護される |
| SteamOS | バージョン3.9以降は保護されるとされている |
| その他のコンソール | プラットフォーム提供元の案内を確認 |
Androidについては、ゲーム実行時の通信とAndroidビルドに使用するOpenJDKを区別する必要があります。Unityに同梱されるOpenJDKについては、別途修正対応が案内されています。
また、eMudhraの問題について、Unityから届いたメールではCVE-2026-111943が紹介されていたけれど、UnityTLSに関する公式アドバイザリでは CVE-2026-114406 が使用されています。
前者は認証局側の侵害に関連する識別番号、後者はUnityの証明書検証への影響を示す識別番号として区別しておきましょう。
Unity Package Managerにも注意が必要
さて、ここまではゲーム側の話だったけれど、実はUnity Editorにも確認しておきたいところがあります。
それがUnity Package Manager（UPM）。
Unity公式によると、Package Managerクライアントには影響を受けるBrotliライブラリが含まれています。
しかも、パッケージの署名を検証する前に、レジストリから受け取った応答を展開する処理があるそうです。
もし悪意のあるScoped Registryを登録してしまったり、正規のレジストリになりすましたサーバーへ接続してしまったりすると、問題のあるデータを処理する可能性があります。
Unityの評価では、WindowsとmacOSではバイナリ保護機構によってクラッシュに影響が限定される一方、Linuxではコード実行の可能性もあるとされています。
ここは開発者として見逃したくないポイントですね。
自分のゲームがBrotliを使っていなくても、開発環境としてのUnity Editorは修正版に更新する意味があります。
特に外部のScoped Registryを追加している場合は、その配布元が信頼できるか確認しておきましょう。
そして、今回のeMudhraの問題と組み合わさると、正規のレジストリへの通信が偽装される可能性も考慮する必要があります。
だからUnityも、最終的には修正済みEditorへの更新を推奨しているんですね。
修正版Unity Editorはどれ？
今回の問題に対応するUnity Editorのバージョンを確認してみましょう。
2026年11月2日に確認したUnity公式アドバイザリでは、修正バージョン表の最終更新日は10月30日となっています。
| Unity系列 | 最初の修正版・公開状況 |
|---|---|
| Unity 6.3 LTS（6000.3） | 6000.3.27f2 |
| Unity 6000.7 Beta | 6000.7.0b7 |
| Unity 6000.6 | 修正版公開待ち |
| Unity 6.0 LTS（6000.0） | 修正版公開待ち |
| Unity 7000.0 Alpha | 修正版公開待ち |
| Unity 2022.3 / 2021.3 | Unityが対応を評価中 |
Unity 6.3 LTSの6000.3.27f2では、今回のセキュリティ対応として次の修正が含まれています。
-
MonoのBrotliデコーダー修正
-
IL2CPPのBrotliデコーダー修正
-
Package Managerに含まれるNode.jsランタイムの更新
-
侵害されたeMudhra証明書を使用するTLS接続の拒否
つまり、今回の2件に関する対策がUnity Editorとランタイムの両方に反映されているんですね。
もちろん、修正版Editorへのアップデートによる動作変更がないか、プロジェクトのテストは忘れずにおこないましょう。
バージョンの公開状況は今後変わるので、対応前にはUnity Download Archiveで最新の修正版を確認が必要です。
Unity Hubも忘れずに
Unity Hubについても別途アップデートがあるよ。
Unity Hub 3.22.4では、侵害されたeMudhraの中間証明書を使用するTLS接続を拒否する修正が追加されています。
さらに2026年10月28日公開の Unity Hub 3.22.5 では、Electronやネットワーク関連ライブラリのセキュリティ修正が含まれています。
Unity Hub 4.xについては、今回のBrotli問題の影響を受けないとされています。
開発環境を更新するなら、EditorだけでなくHubのバージョンも確認しておきましょう。
自分のプロジェクトに影響があるか確認してみよう！
ここからは実践編。
まずは利用しているUnity Editorのバージョンを確認。
Unity Hubで確認するのが簡単だけれど、プロジェクトの次のファイルを見る方法もあります。
ProjectSettings/ProjectVersion.txt
続いて、Brotliの使用箇所を確認します。
Windows環境でripgrep（rg）が使えるなら、PowerShellから次のコマンドで検索できます。
rg -n "BrotliStream|BrotliDecoder|AutomaticDecompression|DecompressionMethods|HttpClientHandler|SocketsHttpHandler" Assets PackagesここでAutomaticDecompressionやHttpClientHandlerが見つかった場合は、Brotliが有効になっているかを調べます。
ただし、この検索はあくまで一次調査。
検索結果が0件だったとしても、DLLの内部やサードパーティー製ライブラリ、外部のネイティブプラグインまで確認できたわけではありません。
もし該当するプラグインを利用しているなら、開発元が公開しているセキュリティ情報もチェックしてください。
Package ManagerのScoped Registryを確認
次はPackages/manifest.json。
ここにscopedRegistriesが設定されている場合は、登録先URLと配布元を確認しておこきましょう。
外部レジストリの使用がすべて危険というわけではないけれど、信頼できないレジストリをむやみに追加しないことは大切です。
修正済みEditorへ移行するまでの間は、特に慎重に扱いたいところですね。
対応が必要かを判断するチェックリスト
- Unity Editorのバージョンを確認した
- ソースコードにBrotliを使用した展開処理があるか確認した
- HttpClientのBrotli自動展開設定を確認した
- サードパーティー製DLL・プラグインの使用状況を確認した
- Scoped Registryの設定を確認した
- 対象プラットフォームの証明書更新状況を確認した
- 修正版Unity Editorへの更新計画を決めた
- 再ビルドが必要な公開済みアプリケーションを洗い出した
公開済みのゲームは再ビルドが必要？
ここも気になるところですね。
今回の2つの問題は、再ビルドの必要性も分けて考えましょう。
| 状況 | 対応 |
|---|---|
| 信頼できないBrotliデータを影響対象APIで展開している | 修正版Editorで再ビルド・再配布 |
| Brotliを展開しないゲーム | 今回のBrotli問題だけを理由とした再配布は不要 |
| UnityWebRequestやAssetBundleの標準機能のみ利用 | Brotli問題を理由とする再配布は通常不要 |
| eMudhraの問題についてOS側の対策が適用済み | OS側の保護が有効なら、一般的にゲームの再ビルドは不要 |
| eMudhraの影響が残るプラットフォーム | プラットフォームの対応状況とUnity修正版を確認 |
| 開発中のプロジェクト | 修正版Editorへの更新を推奨 |
Brotliのデコーダーは、Unity製アプリケーションのビルドに含まれるものです。
そのため、実際に脆弱なデコーダーを利用している公開済みアプリケーションについては、開発PCのUnity Editorを更新しただけでは修正されません。
修正版Editorでアプリケーションを再ビルドし、ユーザーへ再配布する必要があります。
一方、そもそも危険なBrotli展開処理が存在しない場合は、そのアプリケーションの再配布までは必要ないとUnity公式も説明しています。
eMudhraについても、OSの証明書更新で保護される場合があるため、公開済みアプリケーションの再ビルドが一律に必要なわけではありません。
なお、現時点で修正版Editorを利用できない場合は、Brotliについては信頼できない圧縮データを展開する処理を一時的に停止する、あるいは対象APIの利用を避ける方法が暫定的な対策になります。
根本的には修正版への移行が必要だけれど、状況に応じた段階的な対応もできるということですね。
悪用は確認されているの？
ここも正確に伝えておきたいところ。
BrotliのCVE-2026-111497は、2026年10月27日に米国CISAのKnown Exploited Vulnerabilities（KEV）カタログに追加されました。
つまり、Brotliの脆弱性自体については、実際の悪用が確認されているということです。
だから、決して軽視していい問題ではありません。
ただし、Unityが2026年10月30日時点で公表した情報では、Unity製アプリケーションに対する今回の脆弱性の悪用は確認されておらず、ユーザーや顧客への影響も確認されていないと説明しています。
「Brotliの脆弱性が悪用されている」
という事実と、
「Unity製のゲームが実際に攻撃された」
という事実は別。
この2つを混同しないことが大切です。
まとめ：必要な対応を、必要なところに
今回のUnityのセキュリティ修正について調べてみて、改めて感じたことがあります。
それは、セキュリティの話は「どこが危険なのか」と同じくらい、「どこは今回の問題の対象ではないのか」を説明することが大切だということです。
Brotliの脆弱性は深刻な問題だけれど、UnityWebRequestやAssetBundleの標準処理は直接の対象ではありません。
eMudhraの証明書問題は暗号化通信に関係するけれど、OSやプラットフォームの更新によって対策できる場合もあります。
そして、公開済みゲームの再ビルドが必要かどうかも、実際に使っている機能や対象プラットフォームによって変わってきます。
だから、まずは自分のプロジェクトの状況を確認することです。
開発中のプロジェクトについては修正版Editorへ更新し、Brotliの脆弱性に実際にさらされている公開済みアプリケーションについては再ビルドと再配布を行います。
プレイヤーに対しても、OSやデバイスのセキュリティ更新を適用してもらうことが大切ですね。
必要な対策はしっかり行う。でも、対象ではないものまで危険だと決めつけない。
不安を大きくするためのセキュリティ情報ではなく、正しく判断するためのセキュリティ情報でありたいですね。
それじゃ、また次のUnity Topicsで！
参考資料
免責事項（セーフハーバー）
本記事は、Unity Technologiesが公開している公式ドキュメント、セキュリティアドバイザリ、および執筆時点で確認可能な情報をもとに、筆者個人の見解として作成したものです。Unity Technologiesおよびその関連会社の公式見解を示すものではありません。
掲載内容については正確性の確保に努めていますが、情報の完全性、正確性、最新性、および特定の環境への適合性を保証するものではありません。
特にセキュリティ上の脆弱性、影響範囲、修正状況、対応方法については、Unityのバージョン、利用するパッケージ、対象プラットフォーム、実装内容などによって異なる場合があります。また、公開後に新たな情報が判明し、評価や推奨される対応が変更される可能性があります。
実際にセキュリティ対策やアップデートを実施する際には、必ずUnity Technologiesおよび関連するプラットフォーム提供元の最新の公式情報を確認し、ご自身の開発環境やアプリケーションへの影響を評価したうえで判断してください。
本記事は特定のシステムやアプリケーションの安全性を保証するものではなく、法的または専門的なセキュリティ助言を提供するものでもありません。
本記事の情報を利用したことにより生じた損害について、筆者は法令上認められる範囲で責任を負わないものとします。
この記事は2026年11月2日に確認した公式情報に基づいています。影響範囲や修正版の公開状況は変わる可能性があります。実際の対応では、利用しているUnityのバージョン、パッケージ、対象プラットフォームの最新情報を確認してください。
