フロンティアAIの知能は、サイバーセキュリティで最も重要な争奪の的です。
問題は一つだけ。最上の部位を手にするのは誰か、です。
今のところ、優位を握りつつあるのは攻撃のスピードです。エージェント型AIフレームワークを使う攻撃者が、50のエンタープライズアプリケーションを10時間足らずで侵害しました。以前なら10日かかっていた攻撃キャンペーンです。
100人を超えるテック業界のリーダーが、デジタルインフラに残された時間は少ないと警告する公開書簡に署名しました。フロンティアAIラボがOpenAI DaybreakやAnthropicのCyber Verificationのような利用制限付きプログラムを立ち上げて防御側を後押しするなか、業界は居心地の悪い競争に直面しています。マシンスピードの悪用が主導権を握る前に、自動化された防御は規模を拡大できるのか。
ほかにも、ボイスフィッシングが数秒でMFAを突破した手口、サンドボックスから3回脱出したAIモデル、Uberに科された自動化ガバナンスをめぐる8億2,500万ユーロの制裁金、そしてKijiが開発者のマシン上でプロンプトからのPII漏えいを直接防ぐ仕組みを取り上げます。
この号の内容
🌡️ 脅威レベル：高度警戒
⚡ ニュース：押さえておきたいセキュリティの話題5本
🔎 ディープダイブ：防御側に残された時間は閉じつつある
🎣 これはフィッシング？
🔬 技術研究：MFAは破られた。デバイストラストは持ちこたえた。
🛠️ 今週のツール：Kiji Privacy Proxy
👤 今週の人物：Hannes Hapke
📅 今週のイベント：GrrCON 2026
📚 今週の本：Joshua J. Drakeほか著『Android Hacker’s Handbook』
😅 今週のミーム
❓ 最後にひとつ質問
では、始めましょう。
今週の話題に入る前に、現在の脅威レベルを確認しておきます。
🌡️ 脅威レベル
⚡ ニュース
複数行のgit設定一つでGitPythonのRCEが発生
GitPythonのクリティカルな脆弱性（CVE-2026-78676、CVSS 9.8）により、アプリケーションが信頼できないリポジトリ設定を解析する際に、攻撃者がリモートコード実行（RCE）を達成できます。Kodem Securityの開示によると、この欠陥は書き込み時に複数行の設定値を安全でない方法で再シリアライズすることに起因し、攻撃者は引数を注入して、その後のgit操作でcore.hooksPathを上書きできます。直ちにGitPython 3.1.59にアップグレードし、自動化されたCI/CDパイプラインやスキャンパイプラインでは、すべてのリポジトリ設定ファイルを信頼できないユーザー入力として扱ってください。
PaperCutが緊急パッチ適用を呼びかけ、攻撃者はゼロデイを連鎖させて印刷サーバーでRCE
PaperCutは緊急アドバイザリと強化ガイダンスを公開しました。これは、PaperCut NGおよびMFサーバーを標的とした実環境での活発な悪用をセキュリティ研究者が報告したことを受けたものです。脅威アクターは複数の脆弱性を連鎖させ、インターネットに公開された印刷サーバー上で、認証情報を必要とせずに認証なしのリモートコード実行を達成しました。ベンダーのパッチを直ちに適用し、管理ポートへのアクセスを社内のプライベートな管理用VLANに限定し、印刷サーバーで異常な子プロセスの実行がないか監視してください。
cPanelで権限のないホスティングアカウントがサーバーのroot権限を完全に奪取可能
cPanelは必須アップデートを公開し、cPanelおよびWebHost Manager（WHM）のドメインパーキングとアドオンドメインの処理に影響するクリティカルな権限昇格の脆弱性CVE-2026-65643に対処しました。セキュリティ情報の開示で確認されたとおり、この欠陥により、共有ホスティング基盤上の権限のないテナントが境界チェックを回避し、完全なroot権限で任意のコマンドを実行できます。共有ホスティング事業者は最新のcPanel/WHMビルドを直ちに適用し、rootのcron設定に想定外のスクリプト実行パスがないか監査する必要があります。
残高計算の欠陥により、攻撃者が6つのブロックチェーンで資金を流出
Cosmos Labsは緊急アラートを公開しました。対象は、共有のCosmos EVMモジュールにある残高処理のクリティカルな脆弱性（GHSA-7g4w-cg88-2cq2）です。BleepingComputerの報道によると、攻撃者は8月20日から8月25日にかけてこのロジックの欠陥を積極的に悪用し、バリデーターによる協調的な緩和策が展開されるまでに、少なくとも6つの独立したネットワークで流動性を流出させました。コアプロトコルのチームは、グローバルなトークン残高が数学的な整合性チェックに合格しない場合に必ずトランザクションの実行を停止する、自動化された不変条件の監視を実装する必要があります。
制約のないCI/CDのOIDCトークンがクラウドインフラへの扉を開けたままにする理由
セキュリティ研究者が公開した分析は、GitHub Actionsワークフローでワイルドカード指定のid-token: write権限を与えると、組織がクラウドをまたいだラテラルムーブメントにさらされることを示しました。この研究によると、侵害された依存関係がパッケージ公開のワークフローに感染すると、IDプロバイダー層で厳格なaudienceのバインディングが明示的に強制されていない限り、意図しないクラウドプロバイダー（AWSなど）向けのOIDCトークンを発行できてしまいます。クラウドIAMの信頼ポリシーには明示的なaudience（aud）クレームとsubject（sub）クレームを設定し、ビルドランナーが無関係な本番環境のロールになりすませないようにしてください。
🔎 ディープダイブ
防御側に残された時間は閉じつつある
100人を超えるテック業界のリーダーが、同じ書簡に署名しました。
署名者にはOpenAI、Anthropic、Googleに加え、CrowdStrike、Fortinet、Oktaなどのセキュリティ企業が名を連ねています。メッセージは遠回しではありません。自動化されたAIによる攻撃はまもなく規模を拡大し、デジタルインフラはその準備ができていない、というものです。
この警告は、もはや将来のリスクをめぐる理論上の議論ではありません。すでに現実の攻撃として表面化しています。
10時間の侵害
今年初め、Palo Alto Networks Unit 42は、高度なエージェント型AIの能力が攻撃者の手に渡るまで1年かかると見積もっていました。
実際には5か月でした。
Unit 42は現在、攻撃者がエージェント型AIフレームワークを使って50のエンタープライズアプリケーションを悪用したインシデントを調査しています。侵害にかかった時間は10時間未満でした。AI以前の時代なら、同じ攻撃キャンペーンに少なくとも10日はかかっていたはずです。
これこそ公開書簡が警告している世代交代です。AIは今や、マルウェア開発からソーシャルエンジニアリング、ランサムウェアの交渉まで、攻撃チェーン全体の戦力を倍増させるものになっています。攻撃者はAIを使い、マシンスピードでソフトウェアサプライチェーンの奥深くに入り込んでいます。
競い合う2つの時間軸
公開書簡は、異なる速度で進む2つの現実を指摘しています。
攻撃の自動化：AIモデルは、最小限の人間の指示で脆弱性を発見し、エクスプロイトを書き、インフラを標的にできるほどの能力を持ちつつあります。
防御の負債：病院から浄水場まで、不可欠なシステムがレガシーソフトウェア、過剰な権限、未修正のバグによって依然として露出しています。
これが、連合が「防御側の窓（defender’s window）」と呼ぶものを生み出しています。
現時点では、防御チームも攻撃者と同じフロンティアの能力を利用できます。AIはコードベースを読み解き、設定ミスを特定し、従来の手動レビューよりも速く修正案を作成できます。
この窓が開いているのは、防御側が敵対者よりも速く自動化を拡大できている間だけです。
4つの優先事項
差を埋めるため、連合は4つの中核的な方向性を示しています。
エンタープライズのチーム向け：防御には、進行中のインシデントと同じ緊急性で取り組むこと。リスクの高い設定ミスを修正し、権限を制限し、大量のログ解析やコード解析には低コストのモデルを使い、フロンティアモデルは複雑なエッジケースのために取っておくこと。
セキュリティベンダー向け：フロンティアのAIエージェントの能力に対してツールを継続的にテストし、検証済みのプレイブックをリソースの乏しい運用者と共有すること。
政府向け：防御のための資金を重要インフラに振り向け、脅威インテリジェンスの共有を拡大し、脅威アクターに現実のコストを課すこと。
AIラボ向け：防御チームにモデルへのアクセスを提供し、エージェントのアイデンティティを追跡可能にし、責任ある開示の窓口を維持すること。
フロンティアAIラボはすでに、審査を経たセキュリティチーム向けの利用制限付きアクセスプログラムを通じて、この転換を実行に移しています。OpenAIはDaybreakの取り組みを拡大し、Daybreak BlueとDaybreak Redを導入して、承認された防御側が脆弱性の発見とエクスプロイトの検証のためにガードレールを外したGPT-5.6-Cyberなどのモデルを利用できるようにしました。同様に、AnthropicはCyber Verification Programを立ち上げ、検証済みのセキュリティ専門家や組織に対して、Claudeモデルの安全対策を調整して提供し、誤検知による拒否を受けることなく、許可されたテストや研究を行えるようにしています。
中心にある矛盾
この書簡には、居心地の悪いパラドックスがあります。
防御を呼びかける先頭に立つフロンティアAI企業は、自律的な悪用を可能にする能力を開発しているのと同じ企業なのです。
書簡は、AIの能力の行き先を単一の組織がコントロールすることはできないと認めています。デジタルインフラのセキュリティ態勢は、モデルの進歩を止められるかどうかには左右されません。左右するのは、防御側の修正が、ついに自動化された発見よりも速く進めるかどうかです。
それまでは、窓は開いていますが、時計の針は進んでいます。
🎣 これはフィッシング？
難易度：中
このメールには、アカウントの保護を促すボタンがあります。
👉 パスワードを変更
リンク：
http://myaccount.google.com-securitysettingpage.ml-security.org/signonoptions/どうしますか？
🔐 リンクをクリックして認証情報を更新する
🗑️ フィッシングとして報告し、自分でアカウント設定に移動する
🔬 技術研究
MFAは破られた。デバイストラストは持ちこたえた。
フィッシングへの答えは多要素認証だと、私たちは繰り返し言われてきました。
しかし、MFAが完全に破られても、企業が侵害されずに済むことがあります。
それが、2026年8月22日にReliaQuestが受けた攻撃の裏にある、居心地の悪い現実です。このサイバーセキュリティ企業は2026年8月23日、恐喝グループShinyHuntersとのつながりを名乗る攻撃者に標的にされたことを認めました。ReliaQuest自身の説明によると、攻撃者は従業員1人のパスワードとMFAのプッシュ通知の両方を突破しました。
注：ReliaQuestは「侵害」という見方に異議を唱えています。ShinyHuntersはより広範な侵害を主張してOktaのダッシュボードのスクリーンショットをリークサイトに投稿しましたが、スクリーンショットを確認した研究者は、写っていたのは1人のユーザーの設定ページだけだったと述べており、ReliaQuestは、アプリケーション、システム、顧客データのいずれにも到達されていないとしています。以下は、ReliaQuestが公表したインシデントの説明です。
境界が破られた場所
破られたのは人間の層で、非常に説得力のある口実によって突破されました。
攻撃者はボイスフィッシング（ビッシング）キャンペーンを展開し、ReliaQuestのセキュリティチームのメンバーを装って従業員に電話をかけました。電話の相手は被害者に対し、よく似たドメインreliaquest.claimsでホストされたシングルサインオン（SSO）ポータルにログインするよう指示しました。
1人の従業員がこの策略に引っかかりました。偽のページにアクセスして認証情報を入力し、決定的なことに、その後スマートフォンに送られてきたMFAのプッシュ通知を自ら承認してしまったのです。
まさにその瞬間、標準的なアイデンティティの境界は崩れました。攻撃者は有効なパスワードと、MFAで承認されたセッションを手にしたのです。
攻撃の流れ
攻撃チェーンの各段階
ビッシングの電話：攻撃者がセキュリティ担当者を装い、従業員を偽のログインポータルに誘導する。
よく似たドメイン：従業員が正規のSSOのURLではなくreliaquest.claimsにアクセスする。
認証情報の収集：従業員が収集用サイトに有効なパスワードを入力する。
MFAの突破：従業員は正規のMFAプッシュ通知を受け取り、自分のログイン試行によるものだと思って承認する。
ダッシュボードからの横展開：攻撃者がReliaQuestのアイデンティティダッシュボード（Okta）への一時的な閲覧専用アクセスを得る。
ブロック：攻撃者はダッシュボードから下流のアプリケーションへの横展開を試みるが、元のセッションが登録済みでMDMに準拠した企業のエンドポイントに紐付いていないため、アクセスは拒否される。
なぜ重要か
プッシュ通知は、結局のところ人間の判断です。
セキュリティが、従業員が「承認」と「拒否」のどちらを押すかに完全に依存していると、腕の立つソーシャルエンジニアはいずれ「承認」を押させることに成功します。
このインシデントは、ユーザーを認証することとデバイスを認証することの間にあるギャップを浮き彫りにしています。攻撃者はユーザーのアイデンティティのコンテキストを盗みましたが、登録済みの物理的な社用ノートPCを用意することはできませんでした。ReliaQuestはSSOポータルの背後にデバイストラストの制御を重ねていたため、横展開の試みは堅い壁に突き当たりました。
攻撃者のセッションは強制終了され、侵害されたパスワードは失効し、認証要素はリセットされました。注目すべきは、ShinyHunters自身も記者に対し、アクセスは閲覧専用でアプリケーション、システム、顧客データのいずれにも到達していないと語ったことです。この点については、ReliaQuestの説明を裏付ける形になりました。
防御側が学ぶべきこと
セキュリティチームへの教訓はシンプルです。フィッシング耐性の対策がMFAのプッシュ通知で終わっているなら、それは不完全です。
フィッシング耐性のあるMFAを導入する：FIDO2 / WebAuthnのパスキーやハードウェアセキュリティキーに移行してください。これらは認証フローを正規のブラウザーのオリジンに暗号的に結び付け、認証情報の収集とプッシュ疲れを完全に無力化します。
MFAプッシュは突破されると想定する：標準的なMFAプッシュ通知は、MFA疲労攻撃やビッシングの口実に対して脆弱なものとして扱ってください。
デバイストラストを強制する：SSOとゼロトラストネットワークアクセス（ZTNA）のポリシーを設定し、MDMに登録され準拠した企業のエンドポイントから発信されたリクエストでない限り、アプリケーションへのアクセスをブロックしてください。
類似ドメインの登録を監視する：今回使われた.claimsのパターンのように、自社名を悪用し、あまり一般的でないトップレベルドメインと組み合わせた新規登録ドメインを積極的に探してください。
閲覧専用アクセスも調査する：下流のアプリケーションがブロックされていても、アイデンティティダッシュボードへの不正アクセスはすべてクリティカルなインシデントとして扱ってください。
🛠️ 今週のツール
Kiji Privacy Proxy
GitHub：https://github.com/dataiku/kiji-proxy
AI APIへのプロンプトに含まれるPIIをローカルでマスキングする、オープンソースのゲートウェイ。
適用範囲：開発者のエンドポイント、ローカルのAIコーディングエージェント、データ損失防止（DLP）。
機能：セキュリティチームがローカルのAIコーディングアシスタントやコマンドラインのエージェントを導入するにつれ、機密性の高い設定ファイル、社内の顧客ログ、認証情報が、外部に送られるプロンプトのペイロードに含まれてしまうことがよくあります。
Dataikuのkiji-proxyは、開発者のワークステーションと外部のAIプロバイダーのAPI（OpenAI、Anthropic、Gemini）の間に、軽量なクライアント側のチェックポイントを置きます。
ローカルの機械学習：ONNXで最適化されたTransformerモデル（DistilBERT）をホストマシン上でローカルに実行し、メールアドレス、SSN、クレジットカード、氏名など26種類のPIIを100ms未満のレイテンシで検出します。
コンテキストを考慮した置き換え：モデルの推論を混乱させる破壊的な[REDACTED]ブロックを挿入する代わりに、機密性の高い値をリアルな合成データに置き換えるため、LLMは自然なコンテキストを保てます。
通信途中での復元：モデルプロバイダーから返ってくるAPIレスポンスを傍受し、ユーザーに出力を渡す前に、元の実際の値をローカルで静かに元の位置に戻します。
クイックスタート
# Route CLI tools or terminal agents through Kiji's local transparent proxy
export HTTP_PROXY=http://127.0.0.1:8081
export HTTPS_PROXY=http://127.0.0.1:8081
# Run your usual AI workflows—PII is sanitized in flight and restored locally
cat support_dump.txt | claude -p "summarize this customer feedback"代替にならないもの
エンタープライズ向けのネットワークゲートウェイや、サーバー側のAPI DLPソリューション。kiji-proxyは開発者のワークステーションのレベルで動作し、ネットワークのペイロードがローカルマシンを離れる前に、プロンプト経由の意図しない情報流出を防ぎます。
👤 今週の人物
Hannes Hapke
今週ご紹介するのはHannes Hapkeです。575 Lab（Dataikuのオープンソース研究部門）の責任者で、Google Developer Expertでもあり、O’ReillyとManningから本番環境の機械学習システムに関する書籍を複数共著しています。
開発チームやセキュリティチームが日々のワークフローにコマンドラインのAIエージェントやLLMツールを組み込むことが増えるにつれ、機密データ（社内ログからAPIキーまで）が外部に送られるプロンプトのペイロードに簡単に紛れ込むようになりました。この問題に取り組むため、HannesはKiji Privacy Proxyの開発とオープンソース化を主導しました。
重いエンタープライズ向けのコンプライアンスゲートやサーバー側のフィルターに頼る代わりに、Kijiは開発者第一のアプローチを取ります。軽量なMLプロキシをワークステーション上で直接動かし、ネットワークリクエストがマシンを離れる前にPIIをローカルで検出してマスキングし、レスポンスが返ってきたときに元の値を復元します。
機密データの露出リスクを負わずに開発者が安全にAIワークフローを導入できる、実用的なオープンソースツールを作り上げたことから、Hannes Hapkeを今週の人物に選びました。👏
📅 今週のイベント
GrrCON 2026
今年9月、約2,800人のセキュリティ研究者、開発者、経営幹部、エシカルハッカーがグランドラピッズに集まります。MidWest InfoSec, LLCが主催する、米国中西部を代表するサイバーセキュリティと人工知能のカンファレンス、GrrCONの第15回です。
肩肘張らない、気取らない雰囲気で知られるGrrCONは、営業トークよりも実践的なセキュリティ、オープンな協力、研究を重視しています。2日間のプログラムでは、複数の技術講演トラックに加え、実務者によるワークショップや体験型のビレッジが用意されています。
AppSecチームやセキュリティエンジニアリングチームにとっては、攻撃的なエクスプロイト、脅威ハンティング、防御エンジニアリング、新たなAIリスク管理を深く掘り下げる場であり、すぐに役立つ知見を得て同業者と交流するのに最適な場です。
📍 会場：DeVos Place（ミシガン州グランドラピッズ）
📅 日程：2026年9月24日〜25日
📚 今週の本
Android Hacker’s Handbook
著者：Joshua J. Drake、Zach Lanier、Collin Mulliner、Pau Oliva Fora、Stephen A. Ridley、Georg Wicherski
Androidオペレーティングシステムの内部をどう分解して理解するのか？
Wileyから出版された『Android Hacker’s Handbook』は、Androidプラットフォームの脆弱性を理解し、監査し、分析することに特化した初の包括的な技術ガイドでした。
主なテーマ：
OSアーキテクチャとセキュリティモデル：Linuxカーネル、ネイティブデーモン、コアフレームワークにわたって、Androidがセキュリティ設計をどのように実装しているか、その根本的な仕組みを検証します。
脆弱性分析：システムコンポーネント、コアサービス、ネイティブのC/C++ライブラリの弱点を特定する手法を解説します。
root化のプロセス：ハードウェアのパーティション構成と、昇格した権限を得るために必要なブートプロセスを詳しく説明します。
ファズテスト：ファジングツールとIPC/Binderの監査を使って脆弱性を自動で発見するアプローチを教えます。
アプリケーションの監査：個々のAndroidアプリケーションを分解し、リバースエンジニアリングし、保護するための手法を詳しく紹介します。
背景と変遷：
2014年に出版された本書は、Androidの内部構造について確かな技術的基礎を読者に与えてくれます。この12年間で、プラットフォームはアーキテクチャ上の大きな変化を遂げました。ARTランタイムへの移行、SELinuxの強制の義務化、ハードウェアに裏付けられたKeystore/StrongBoxの実装、APEXによるモジュール単位のアップデート、システム全体でのRustの採用、ARM Memory Tagging（MTE）などです。
基礎となる原則は今も役立ちますが、12年にわたるプラットフォームの進化を考えると、改訂第2版が出る理由は十分にあります。
😅 今週のミーム
Jiraチケットのステータス：ブロック中（ハッカーにより）🥺
自律的なエージェント型フレームワークが50のエンタープライズアプリケーションの脆弱性を10時間足らずで発見し悪用できるとしたら、自社のチームが手動のまま残しておくわけにはいかない防御策を一つだけ挙げるなら何でしょうか？
The Breach Brief、Ostorlabチーム