Android 2026年9月の四半期更新｜180件の内訳とパッチレベル 01/05

はじめに

2026年9月8日（現地時間）、Google が Android のセキュリティ情報を公開しました。修正された脆弱性は 180件 。うち最高深刻度の Critical が32件、High が148件です。

数だけ見ると異常に多く見えますが、これは事故ではありません。Android のセキュリティ情報は、3月・6月・9月・12月だけ極端に大きくなる ようにできています。同じ Google の公式ページを数え直すと、直前の7月と8月に載っていた脆弱性は どちらも0件 でした。

この記事では、次の順で整理します。

• Android Security Bulletin（ASB）とは何か
• セキュリティパッチレベルが「2026-09-01」と「2026-09-05」の2段に分かれている理由
• Project Mainline — OS の更新を待たずに修正が届く経路
• なぜ四半期だけ大きくなるのか（公式が言っていること／言っていないこと）
• 180件の内訳を、公式の表から数え直した結果
• 自分のボードで AOSP を動かしている人にとって、この2段構造が何を意味するか

数字はすべて、Google の公式ページに載っている表を筆者が自分で数え直したものです。数え方は §4 の最後に明記します。

🧭 1. Android Security Bulletin（ASB）とは

Android は Google だけで作られているわけではありません。OS 本体（AOSP）は Google が、SoC のドライバは Qualcomm や MediaTek が、カーネルは上流の Linux コミュニティが書いています。そこに端末メーカーの独自改造が乗ります。

脆弱性の修正がバラバラに公開されると、端末メーカーは追いきれません。そこで Google は、修正の開示を1か所にまとめて時刻を揃える 仕組みを用意しています。それが Android Security Bulletin（ASB）です。

公式の概要ページによれば、掲載される修正の出どころは3系統あります。

公開のタイミングも決まっています。原則として 毎月第1月曜日 で、その日が休日にあたる場合は翌営業日にずれる、と公式に書かれています。2026年9月分は9月8日（火）でした。

そして、公開のかなり前に関係者へは伝わっています。9月分のセキュリティ情報にはこう書かれています。

We notify our Android partners of all issues at least a month before publishing the bulletin. （すべての問題について、セキュリティ情報の公開の少なくとも1か月前に Android のパートナーへ通知しています）

つまり読者が記事でこの件を知る時点で、端末メーカーの手元には1か月以上前からパッチが渡っている、という前提です。

🧩 2. なぜパッチレベルが「01」と「05」の2段あるのか

9月分のセキュリティ情報には、パッチレベルが2つ書かれています。2026-09-01 と 2026-09-05 です。この2段構えは Android のセキュリティ情報の設計上もっとも分かりにくい部分なので、公式の説明をそのまま引きます。

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. （このセキュリティ情報に2つのパッチレベルがあるのは、すべての Android 端末に共通する脆弱性の部分集合を、パートナーがより速く修正できる柔軟性を持たせるためです）

要するに、全機種に共通する部分だけを先に出せるようにした ということです。

• 2026-09-01 ＝ どの Android 端末にも共通して存在する部分（System / Framework / ART など、AOSP 側のコード）の修正
• 2026-09-05 ＝ 01 の内容に加えて、カーネルと各 SoC ベンダー由来の修正まで含んだ完全版

なぜ分ける必要があるのか。01 の修正は Google の書いたコードだけで完結するのに対し、05 の修正は Qualcomm や MediaTek や Arm がパッチを出してくれないと端末メーカーには作れない からです。ベンダーの都合で1社でも遅れると、端末メーカーは「共通部分は直っているのに何も出せない」状態になります。それを避けるための逃げ道が 01 です。

公式は、宣言できる条件も明記しています。

• 2026-09-01 を宣言する端末は、そのレベルに紐づく全問題と、過去のすべてのセキュリティ情報の修正 を含んでいなければならない
• 2026-09-05 以降を宣言する端末は、今回および過去のセキュリティ情報の 該当するすべてのパッチ を含んでいなければならない

🔄 3. Project Mainline — OS 更新を待たずに届く経路

ASB の修正は、端末メーカーの OTA だけで届くわけではありません。もう1本、経路があります。

Android 10 で導入された Mainline（旧称: モジュール式システムコンポーネント）は、Android のシステムコンポーネントの一部をモジュールに切り出し、通常の Android リリースサイクルの外側で更新できる ようにした仕組みです。公式ドキュメントの説明から要点を挙げます。

• モジュールは APEX または APK の形式で配布される
• 更新は アトミック に適用される。対象モジュールがすべて更新されるか、1つも更新されないかのどちらか
• モジュールの更新で 新しい API は導入されない 。CTS が保証する SDK / System API と、安定した C API または安定した AIDL インターフェースだけを使う
• 配信経路は2つ。Google Play システム アップデート（Google Play ストアの基盤で動く）か、パートナー提供の OTA
• Google Mobile Services 搭載端末では Google が署名した com.google.android.* が使われ、AOSP の鍵で署名された端末では com.android.* が使われる
• Android 11 以下に対する Mainline のサポートは 2025年第4四半期をもって終了 している

2026年9月分では、180件のうち 20件 が Google Play システム アップデート経由でも配信される対象として挙げられています。モジュール別の内訳は次のとおりです。

この20件はすべて、パッチレベル 01 側の表にも載っている脆弱性です。Mainline は「別の脆弱性を直す経路」ではなく、「同じ脆弱性に届く2本目の経路」 だと理解するのが正確です。

そして重要なのは、この20件のうち 3件が、後述する System の Critical RCE だという点です（CVE-2026-28604 = adbd、CVE-2026-28618 = Media Codecs、CVE-2026-28662 = WiFi）。最も深刻な部類の修正の一部が、端末メーカーの OTA を待たずに届く設計になっています。

📅 4. 「四半期に大規模」はどこまで公式の話か

ここは、公式が言っていることと言っていないことを分けて書きます。

公式が言っていること

Google のセキュリティ情報の概要ページには、次の記述があります。

Android platform security fixes are merged into AOSP 24–48 hours after the quarterly security bulletin is released (March, June, September, December) and can be picked up directly from there. （Android プラットフォームのセキュリティ修正は、四半期のセキュリティ情報（3月・6月・9月・12月）の公開から24〜48時間後に AOSP へマージされ、そこから直接取得できます）

四半期という語と、3・6・9・12月という月の指定は、Google 自身の文章に書かれています。 さらにこの一文は、AOSP へのソース公開が四半期のセキュリティ情報に紐づいている、とも読めます。

公式が言っていないこと

一方で、月次は高リスクのものだけに絞る、という運用方針そのものについては、Google の公式な発表を見つけられませんでした。 筆者が当たったのは、9月分のセキュリティ情報の本文と FAQ、概要ページ、Mainline のドキュメントです。いずれにも運用変更の説明はありません。

この変更を報じたのは Android Authority の Mishaal Rahman 氏による2025年9月13日の記事で、同記事は Google が Risk-Based Update System（RBUS） と呼ぶ新方式を採用したと伝えています。同記事によれば、月次には高リスクのものだけを載せ、大半の修正は四半期にまとめる、という運用です。そして同記事は Google がこの変更を公に発表していない と明記したうえで、Google 広報の次のコメントを掲載しています。

Android and Pixel continuously address known security vulnerabilities and prioritize fixing and patching the highest-risk ones first. （Android と Pixel は既知の脆弱性に継続的に対処しており、最も高リスクのものから優先して修正・パッチ適用を行っています）

運用方針の名称と細部は Android Authority の報道であり、Google の公式発表ではありません。 ただし高リスクを優先するという原則自体は、上記のとおり Google 広報の発言として記録されています。

同記事はもうひとつ、実務上とても重要な区別を指摘しています。ここでいう高リスクは CVSS の Critical / High という深刻度の格付けとは別物 で、実際に悪用が観測されているか、既知の攻撃チェーンの一部かといった現実世界の脅威度で判定される、というものです。深刻度が Critical でも、悪用されていなければ四半期送りになりうる ということになります。

実際のデータで確かめる

方針の説明が公式に無くても、結果は公式ページに残っています。 Google のセキュリティ情報を筆者が1件ずつ数えた結果が次の表です。

パターンははっきりしています。四半期の月は99〜180件、それ以外の月は0〜6件。 2026年7月と8月に至っては、セキュリティ情報のページ自体は公開されているのに、脆弱性の表が1つもありません。FAQ とパッチレベルの説明だけが載っています。

2026年5月の1件も示唆的です。この月に載ったのは CVE-2026-0073 ただ1件で、System コンポーネントの Critical の RCE でした。しかも Google Play システム アップデートの対象にも入っています。四半期以外の月に何かが載るときは、こういうものが載る、という一例です。

📊 5. 2026年9月の180件を分解する

パッチレベル 2026-09-01（95件・うち Critical 26件）

Critical はすべて System と Framework に集中しています。System の56件を種別で見ると、権限昇格（EoP）30件、情報漏えい（ID）13件、リモートコード実行（RCE）9件、サービス拒否（DoS）4件でした。

パッチレベル 2026-09-05 の追加分（85件・うち Critical 6件）

サブコンポーネントまで降りると、どこが直されたのかがよく見えます。Imagination の25件は すべて PowerVR-GPU 、Arm の6件は すべて Mali 、Unisoc の7件は すべて Modem です。MediaTek の21件は Modem 9件、display 4件、apusys 2件、geniezone 2件、vdec 2件、hevc decoder 1件、trusted_mem 1件に分かれています。

つまり 05 レベルの追加分は、GPU ドライバとモデムとメディアデコーダにかなりの部分が集中している ことになります。どれも、アプリから叩ける位置にある巨大なベンダー製コード、という共通点があります。

カーネル側の Critical 5件

件数は少ないものの、中身は目を引きます。

Protected KVM（pKVM）で3件 。pKVM は Android がハイパーバイザ層で作る隔離環境で、そこでの権限昇格が Critical と評価されるのは筋が通っています。そして CVE-2026-52993 は 上流の Linux カーネルの TIPC における Critical の RCE で、参照先が upstream kernel になっています。Android のセキュリティ情報が Linux カーネルの上に乗っていることが、そのまま表に出ている形です。

カーネル側のパッチがどういう流量で流れてくるものなのかは、Linuxカーネルの「AIパッチ洪水」 で扱っています。

🎯 6. 最も深刻とされたもの — System の Critical RCE

セキュリティ情報の冒頭には、その月で最も深刻な問題が1文で書かれます。9月分はこうです。

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation. （これらの問題のうち最も深刻なのは System コンポーネントの Critical の脆弱性で、追加の実行権限を必要とせずリモートコード実行に至る可能性があります。悪用にユーザーの操作は不要です）

この条件に該当する System の Critical RCE は、表を数えると 8件 ありました。対象となる AOSP のバージョンは次のとおりです。

6件は Android 14 まで遡って修正が入り、2件は Android 16 以降だけ です（CVE-2026-28618 と CVE-2026-28662）。後者は比較的新しく入ったコードにある問題、と読むのが自然でしょう。

そして §3 で触れたとおり、CVE-2026-28604（adbd）・CVE-2026-28618（Media Codecs）・CVE-2026-28662（WiFi）の3件は Google Play システム アップデートの対象にも入っています。

悪用されているのかどうか

窓の杜は見出しで「悪用の兆候は今のところなし」としています。この点は、断定ではなく 確認できた事実の形 で書きます。

Google は、悪用が疑われる脆弱性については セキュリティ情報の本文に注記を入れる運用 をしています。実例として、2026年6月分にはこの一文があります。

Note: There are indications that CVE-2025-48595 may be under limited, targeted exploitation. （注: CVE-2025-48595 が限定的かつ標的型の悪用を受けている可能性を示す兆候があります）

2026年9月分のセキュリティ情報には、この種の注記が1つもありません。 筆者が本文全体を検索した結果、limited, targeted を含む記述は0件でした。

したがって正確な言い方は「Google が悪用の兆候を注記していない」であって、「悪用されていないことが確認された」ではありません。注記が無いことは、悪用が無いことの証明ではなく、Google が現時点で兆候を掲載していないという事実 です。

🔬 7. 「05」の実体は、ほとんどがチップベンダー

ここまでの内訳をベンダー視点で足し直すと、構造がはっきりします。

05 レベルの追加分85件のうち、チップベンダーの節に載っているものは76件 です（Imagination 25 + MediaTek 21 + Qualcomm closed-source 11 + Unisoc 7 + Arm 6 + Qualcomm 5 + Tsingteng Micro 1）。残りは Kernel が6件、TV が3件。

つまり 05 レベルの約9割は、Google が書いたコードではありません。 180件全体で見ても、42%がチップベンダー由来です。

この図が、§2 で見た2段構えの理由そのものです。01 で止まっている端末は、端末メーカーが怠けているとは限りません。 ベンダーからパッチが来ていない、あるいは自社の全機種ぶんの検証が終わっていない、という状態でも 01 は宣言できます。逆に 05 まで来ている端末は、SoC ベンダーとの供給関係が生きている証拠 でもあります。

中古端末や型落ちのタブレットを買うとき、パッチレベルの末尾が 01 で止まっているか 05 まで来ているかは、その端末がサプライチェーンのどこに立っているかの指標 として読めます。

🛠️ 8. 自分のボードで AOSP を動かしているなら

SBC やカスタム基板で AOSP を動かしている場合、話は少し変わります。ここは公式ドキュメントから読み取れる範囲でまとめます。

AOSP 側のパッチは自分で取りに行ける。 セキュリティ情報の公開から48時間以内に、対応するソースコードのパッチが AOSP リポジトリへ公開され、その後セキュリティ情報の側に AOSP へのリンクが追記される、と9月分の本文に書かれています。取得先が明確なぶん、01 レベルの修正は追随しやすい部類です。

Google Play システム アップデートは当てにできない。 Mainline の公式ドキュメントによれば、Google が署名した com.google.android.* のモジュールが使われるのは Google Mobile Services 搭載端末で、AOSP の鍵で署名した端末では com.android.* が使われます。 自前ビルドのボードには Google Play の配信基盤が乗っていないため、§3 の20件は勝手に届くものではなく、自分でモジュールを更新して配る対象 になります。Mainline のもう一方の経路である「パートナー提供の OTA」を、自分で用意する立場だと考えるのが正確です。

月次のソース公開は期待しにくい。 Android Authority は、Google が月次のセキュリティ更新についてはソースコードを公開しなくなり、四半期のぶんだけになった、と報じています。これは同社の報道ですが、Google 自身の概要ページが「四半期のセキュリティ情報の公開から24〜48時間後に AOSP へマージされる」と書いている ことと整合します。自前ビルド勢にとっては、実質的に 3月・6月・9月・12月が更新の単位 になる、ということです。

ベンダー由来の76件は、そもそも AOSP には無い。 GPU ドライバやモデムファームウェアの修正は、SoC ベンダーから受け取る BSP に依存します。ボードの SoC が Imagination の PowerVR や Arm の Mali を積んでいるなら、今月の修正の少なくない部分はベンダー BSP 側の話です。

まとめ

• 2026年9月8日公開の Android セキュリティ情報は 四半期の大規模更新 にあたり、180件（Critical 32件・High 148件）を修正している
• 四半期（3・6・9・12月）という単位は Google 自身の公式ページに書かれている。 一方で、月次は高リスクのみに絞るという運用方針の公式発表は見つからず、名称（RBUS）と細部は Android Authority の報道による
• 筆者が公式ページを数え直したところ、四半期の月は99〜180件、それ以外の月は0〜6件。2026年7月と8月は0件 だった
• パッチレベル 01 は AOSP 共通部分（95件）、05 はそこにカーネルとベンダー由来を足した完全版（+85件） 。05 は 01 の上位集合
• 05 の追加分85件のうち76件はチップベンダーの節 。GPU ドライバ・モデム・メディアデコーダに集中している
• 最も深刻とされたのは System の Critical RCE で、該当は 8件 。うち6件は Android 14 まで遡って修正が入る
• 20件は Project Mainline 経由でも配信され、うち3件は System の Critical RCE 。ただしこの経路が効くのは Google Play の配信基盤が乗っている端末
• 9月分の本文には、悪用の兆候を示す注記（6月分にはあった limited, targeted exploitation の記載）が 1件も無い

よくある質問（FAQ）

Q. 自分の端末のセキュリティパッチレベルはどこで確認できますか。

多くの端末では、設定 → デバイス情報 → Android バージョンの画面に「Android セキュリティ アップデート」として表示されます。メーカーによって名称と階層が違うため、見つからない場合は設定内の検索で「セキュリティ」を引くのが確実です。開発者向けには ro.build.version.security_patch プロパティが同じ値を持ちます。同じ画面に「Google Play システム アップデート」の日付が別途出ることがあり、そちらが §3 の Mainline 側の状態を表します。

Q. パッチレベルが「2026-09-01」で止まっていたら危険ですか。

危険というより、今月の修正のうち95件までが入っていて、ベンダー由来の85件がまだ入っていない状態 です。Google が定義上求めているのは、01 を宣言する端末が「そのレベルの全問題と過去のすべてのセキュリティ情報の修正」を含むことなので、01 自体は正規の状態です。ただし今月に限れば、最も深刻とされた System の Critical RCE 8件は 01 側に含まれている ため、そこは押さえられていることになります。

Q. なぜ7月と8月のセキュリティ情報は0件だったのですか。

Google はこの点について公式に説明していません。Android Authority は、月次には高リスクと判断したものだけを載せる方式に変わったためだと報じています。同記事によれば、ここでの高リスクは Critical / High という深刻度の格付けとは別で、実際に悪用が観測されているかどうかなど現実の脅威度 で判定されます。0件は「脆弱性が無かった」という意味ではなく、「今すぐ出すべきものが無かった」という意味になります。

Q. AOSP を自前ビルドしています。何をすればいいですか。

まず、セキュリティ情報の公開から48時間以内に AOSP へマージされるパッチを、自分のブランチへ取り込む工程を用意することです。次に、Google Play システム アップデートは自前ビルドのボードには届かない 点を織り込みます。Mainline のモジュールは AOSP の鍵で署名した端末では com.android.* になり、配布は自分の OTA で行う立場になります。最後に、GPU やモデムなどベンダー由来の修正は SoC ベンダーの BSP 待ちなので、更新の有無を個別に確認する必要があります。詳しくは §8 のチェック手順にまとめました。

Q. Critical が32件もあるのは異常な事態ですか。

四半期の月としては多いほうですが、構造上の増加 と見るのが妥当です。四半期ごとの Critical 件数を並べると、2025年9月が3件、12月が6件、2026年3月が10件、6月が18件、9月が32件でした。四半期にまとめる方式では、月次で拾わなかったぶんが積み上がって出てきます。件数の絶対値より、自分の端末のパッチレベルがどこまで来ているか を見るほうが実務的です。

Q. Pixel 向けの情報は別にあるのですか。

Pixel Update Bulletin という別のセキュリティ情報が存在します。ただし 2026年9月9日時点で、Pixel の一覧に載っている最新は2026年8月分（8月4日公開） で、9月分はまだ掲載されていませんでした。公式の FAQ によれば、端末・パートナー個別のセキュリティ情報に載る脆弱性は、パッチレベルの宣言には必須ではない、という位置づけです。

Q. 「悪用の兆候なし」と書いてあるのを見ました。確定した話ですか。

確定ではありません。9月分のセキュリティ情報の本文には、悪用に関する注記が1つもありません。 Google は兆候がある場合に注記を入れる運用をしており、2026年6月分には CVE-2025-48595 について「限定的かつ標的型の悪用を受けている可能性」という注記がありました。9月分にその種の記載が無い、というのが確認できる事実であり、悪用が無いことの証明ではありません。

参考

• Android Security Bulletin—September 2026（Google 公式）
• Android Security Bulletins 一覧・公開ルール（Google 公式）
• Android Security Bulletin—June 2026（Google 公式・悪用の注記がある回）
• Mainline（Google 公式・モジュール式システムコンポーネント）
• Exclusive: Google wants to make Android phones safer by switching to risk-based security updates（Android Authority・Mishaal Rahman・2025年9月13日）
• Androidに四半期に一度の大規模セキュリティ更新 ～180件を修正、「Critical」は32件（窓の杜・樽井秀人・2026年9月9日）

関連記事

• Linuxカーネルの「AIパッチ洪水」｜CVE 2,000件の正体とメンテナの適応
• NetScaler CVE-2026-8452｜DoS のはずが未認証 RCE、優先度の決め方
• NVIDIA×MediaTek 提携深化｜35億ドル出資でAIはどこまで降りるか
• Ubuntu 26.04 LTS の新機能｜sudo の Rust 化・X11 廃止・GNOME 50 と既知問題