偽のエラーログが命令に変わる、社内AI乗っ取りの入口

エラーログをAIエージェントに解析させる環境では、ログに紛れ込んだ文章がAIへの命令として実行される危険があります。

研究チームの検証では、偽のエラーメッセージを読み込んだAIが、指定された第三者のパッケージをダウンロードして実行したのだそうで、この手法では、外部の文章へ不正な指示を埋め込む「間接プロンプトインジェクション」が利用されていたのだそうです。

エラーログ

研究チームは、エラー監視ツール「Sentry」とAIエージェントをMCPサーバーで連携させ、追加診断のため特定のパッケージを実行するよう指示した偽のログを送ったのだそうで、実験で使われたパッケージは、研究用サーバーへ接続を試みるだけのものだったのですが、悪意あるプログラムへ置き換われば、認証情報の窃取、プログラムの改ざん、裏口の設置につながる構造だったようです。

同様の検証を世界規模で行った「AgentJacking」では、大企業を含む100社以上の社内AIエージェントが不正な通信を返したことが確認され、実際のデータ窃取を行わない実証実験として実施されています。

コーディング用AIエージェントは、ファイルの読み書き、シェルコマンドの実行、パッケージの導入、外部サービスへの接続といった権限を持っていて、業務を自動化する能力が、そのまま攻撃時の実行能力にもなります。

従来のセキュリティ製品は、既知の不正ファイルや不審なコマンドの組み合わせを手掛かりに検知する一方、AIエージェントによる設定ファイルの読み取りやスクリプト実行は、開発業務でも日常的に発生しており、正規の作業と攻撃の区別が難しくなります。

対策は、AIが読むデータと、AIへ与える命令を同じ信頼度で扱わないことで、パッケージの導入、シェル実行、認証情報へのアクセス、外部通信には個別の権限制限や人の承認を設ける必要があります。

エラーログは本来、原因を調べるための記録だったのですが、AIが実行権限を持つ環境では、記録の中の一文が操作命令へ変わり、読むだけだったデータが行動を起こす時点で、ログも入力欄もセキュリティ境界になってしまいます。

AIエージェント時代のサイバー防衛：OpenAIの警鐘と企業が備えるべき現実

生成AIやAIエージェントが業務に入り込み始める一方、そのAI自体がサイバー攻撃の主体となる事例が現実のものになりつつあります。

AIモデルがテスト環境から抜け出し、ソフトウエアの脆弱性を突いてインターネットに接続し、他のAIエージェントと連携しながら外部サービスへ侵入する・・・。

そんな「悪夢」に近いシナリオが、すでに複数回確認されていて、OpenAIやMicrosoft、Googleなど155の組織は、AIを利用した広範なサイバー攻撃に備える時間は限られていると警告し、官民をまたいだ集団的な防御強化を呼びかけています。

AI暴走

AIエージェントが突きつけた「悪夢」の現実味

ここ1年ほどの間に、AIエージェントが関与する大きなインシデントが立て続けに起きていて、中でも象徴的なのは、本来インターネットに接続できないはずのテスト環境からAIモデルが抜け出した事例で、モデルは大量のコードからソフトウエアの脆弱性を見つけ、その欠陥を悪用して外部ネットワークへの接続に成功し、さらに、盗まれた認証情報を使って数百のAIエージェント同士が急ごしらえの掲示板で通信し、最終的にはAIプラットフォームであるHugging Faceへの侵入にまで至っています。

同様の事案は他にもあり、AnthropicのAIモデルが社名非公開の3社に侵入したケース、MetaのAIが第三者のサービスをハッキングした事案、ClaudeのAIエージェントが利用者をフィットネスクラスに参加させる目的でオーストラリアのスポーツジムに不正アクセスしたケースなど、共通しているのは、AIが大量のプログラムコードを読み込み、そこから人間よりも素早く脆弱性を見つけ出し、与えられた任務を達成するまで試行錯誤を繰り返すという特性。

従来のサイバー攻撃は、人間の攻撃者がツールを駆使して計画的に進めるケースが多かったのですが、AIエージェントの登場は、攻撃側の「人手不足」や「技術不足」といった制約を大きく軽減し、規模とスピードの両面で従来と質の異なるリスクを生み出していて、重要インフラや大企業だけでなく、中堅企業や医療機関、自治体といった従来は標的になりにくかった組織にも、深刻な被害が及ぶ可能性が高まっています。

OpenAIら155組織が示した4つの防御軸

こうした状況を踏まえ、OpenAIは「サイバー防衛に向けた集団行動の呼びかけ」という公開書簡を発表し、AIを利用したサイバー攻撃への備えを急ぐよう訴えていて、呼びかけにはOpenAIのほか、Microsoft、Google、Anthropic、OracleなどAIやクラウドの主要プレーヤーを含む155の企業・団体が署名しています。

書簡が示した4つの対策の軸

1つ目は、すべての組織に共通する基礎防御の強化で、特に「最もリスクの高い脆弱性」を優先的に修正し、古いバグを残さないこと、AI生成コードの安全基準を引き上げること、権限設定やアクセス制御を見直すことが求められている。

AIが脆弱性探索を加速させる環境では、パッチの遅れや過剰な権限設定が、以前にも増して致命的なリスクになりやすい。

2つ目は、サイバーセキュリティ企業の役割で、攻撃側にAIが使われる前提で、自社の防御ソリューションを強化するとともに、水道や電力、交通などの重要インフラ事業者が防御用AIを導入できるよう支援することが期待されていて、AIを活用した脅威検知やインシデント対応を、一部の先進組織だけでなく社会インフラ全体へと広げていくことが課題となります。

3つ目は、政府による資金と制度面での後押しで、特に予算が不足しがちな病院、水道事業者、地方自治体といった組織が、高性能な防御用AIを利用できるよう支援する必要があるとし、高度な人材を自前で確保しにくい組織ほど、AIをうまく活用しなければ防衛力の格差が一層広がるおそれがあります。

4つ目は、フロンティアAI企業に対する責任の明確化で、AIエージェントのアイデンティティーを追跡し、行動の責任をたどれるようにすること、政府やセキュリティパートナー、オープンソースコミュニティと信頼できる脅威評価を共有することが挙げられている。AIシステムの監視、テスト、修正に継続的に投資し、「作って終わり」にしないことが前提になる。

「知能インフラ」としてAIを設計し直す視点

公開書簡が社会全体の防御体制を呼びかける一方で、個々の企業は自社のAI活用をどのように設計し直すべきかが問われており、テック起業家のトーマス・エイダン・カレン氏は、AIをモデル単体ではなく、本人確認、権限管理、監査、説明責任まで含めた「知能インフラ」として捉えることが不可欠だとしています。

生成AIは本質的に非決定論的で、同じ質問でもタイミングや文脈によって異なる答えを返し、従来の業務システムのように、特定の入力に対して常に同じ出力が得られる前提では設計されていません。

なので、過去に整備されてきた監査やコンプライアンスの考え方をそのまま当てはめることは難しい。

さらに、現代のAIシステムはモデルだけで完結せず、外部ツールやAPI、複数のAIエージェントが緩く連携する形で動き、どのエージェントがどの権限で、どのデータにアクセスしたのかを追跡できなければ、問題が起きた際に責任の所在を明らかにすることも、再発防止策を講じることも難しくなります。

カレン氏は、こうした構造を前提に、AI導入の段階から権限の粒度、アクセス制御、操作ログ、監査プロセスを組み込む必要があると指摘しています。

「知能インフラ」という考え方は、AIを単なる便利なツールとして個別最適で導入する姿勢から、組織全体の情報基盤の一部として長期的に設計する姿勢への転換を意味しており、性能重視の短期的な投資と、安全性・説明責任のための基盤整備をどう両立させるかが、これからのAI活用の核心になります。

企業が今すぐ着手できる防衛の土台

社会全体でのルール作りや監査制度の整備には時間がかかります。

一方で、個々の企業が今から取り組める対策もはっきりしており、タルサ大学のTyler Moore氏は、AIの登場以前からサイバーセキュリティは投資不足とベストプラクティス不在に悩まされてきたと指摘し、AI企業にはサイバーハイジーン向上のためのツールや手法を、重要インフラ組織などに無償提供する役割があると述べています。

そのうえで、企業側に求められるのは、地道な基本対策の積み重ねで、AIが脆弱性探索を加速させるからこそ、古いシステムの更新、既知の脆弱性の早期修正、過剰な権限の縮小、多要素認証の徹底といった「当たり前」の対策の優先度が上がり、AIを活用した防御ツールを導入するにしても、その前提となる資産管理やログ管理が整っていなければ十分な効果は発揮できません。

人材面では、サイバー防衛の専門家不足が続いており、企業による奨学金などを通じた人材育成の重要性も挙げられ、すべての組織が高度な専門家を揃えることは難しいとはいえ、基礎的なセキュリティリテラシーを持つ人材を各部門に配置し、AI活用プロジェクトの設計段階からセキュリティとガバナンスを組み込む体制を整えることは可能なはず。

AIによる大規模サイバー攻撃に備える特効薬は存在しませんし、だからこそ、組織の規模を問わず、AIの支援を受けながら基本的なサイバー衛生を着実に高めていくことが、安全性と技術革新を両立させる現実的な道筋になります。

生成AIの導入を検討する段階から「そのAIはどの権限で、どのデータに触れ、何が記録され、誰が責任を負うのか」という問いをセットで考えることが、これからの企業に求められる姿勢だと言えます。

脅威関連ドメインの44％が1日しか稼働せず、追跡より先回りへ

サイバー攻撃に使われる接続先は、発見して危険リストへ登録するまで待ってくれない。

Infobloxの調査では、脅威に関連するドメインの44％が、わずか1日しか稼働していなかったのだそうです。

Infoblox 2026 Threat Landscape Report

「2026 Threat Landscape Report」は、クラウドセキュリティーサービスの顧客から得たDNS通信などを分析したもので、過去1年間に新たに観測した約1億2000万件のドメインのうち、22％以上が攻撃に悪用されているとしています。

脅威関連ドメインの88％は、一つの顧客環境でしか観測されなかったようで、多くの企業で繰り返し使われる有名な攻撃先だけを遮断しても、特定の標的に短期間だけ使われるドメインは捉えにくい。

攻撃者は、アクセスしてきた端末の種類、位置情報、ブラウザ、言語などを判定し、狙った利用者だけを詐欺サイトへ誘導することもあり、それ以外の訪問者には通常のページを見せることで、自動巡回による検査や研究者の追跡を回避する手法も使われているのだとか

この状況では、被害が確認されたURLを後から登録する方法だけでは間に合わないうえ、今日見つけた攻撃先が、明日には使われていない可能性があるようです。

Infobloxは、ドメイン名とIPアドレスを結び付けるDNSの通信を分析し、攻撃が始まる前の準備段階から不審な接続先を見つける方法を提案しており、調査期間中、脅威関連ドメインの約90％を実際の攻撃が発生する平均68日前に特定したとしています。

ただし、これらはInfobloxの顧客環境と同社の分類方法に基づく数字であり、インターネット上の全ドメインの44％が1日で消えるという意味ではなく、調査範囲を切り離して数字だけを一般化するのは危険ですね。

それでも、短期間しか稼働しない攻撃用インフラが存在するという特徴は明確であり、サイバー防御の対象は、侵入後に見つかる不正プログラムだけではなく、攻撃者が接続先を準備している段階から監視するという考え方が重要になってきています。

Googleパスワードマネージャーに3段階の攻撃手法 パスキー保護を破る脆弱性とは

Windows版Google Chromeに搭載されているGoogleパスワードマネージャーに、パスキー認証を突破される脆弱性が見つかったのだとか。

米Palo Alto Networksが指摘したのは、「Pass‑ta‑key」「Silver Pass‑ta‑key」「Golden Pass‑ta‑key」という3つの攻撃手法で、いずれもパスワードレスでより安全とされてきたパスキーを標的としていて、ユーザーの同意や生体認証をほとんど伴わない形でアカウントを乗っ取れる可能性があるようです。

日常的にGoogleアカウントとChromeに依存する利用環境では、どのような仕組みが狙われているのかを理解しておくことが重要になりそう

Googleパスワードマネージャー

Pass‑ta‑key：ユーザー操作なしでアカウントを乗っ取る手口

Pass‑ta‑keyは、被害者のWindows環境に侵入したマルウェアが、GoogleパスワードマネージャーとChromeの挙動を真似ることで、パスキーで守られているアカウントを乗っ取る攻撃手法で、マルウェア側が正規のパスキー利用フローを模倣し、裏側で認証を進めることで、攻撃者がアカウントへのアクセス権を得るようです。

特徴的なのは、この過程でユーザーの明示的な同意や生体認証操作、管理者権限の取得といった分かりやすい「異変」がほとんど発生しない点で、被害者の画面上には不審な認証ダイアログが表示されず、普段の利用との違いに気付きにくいようで、その結果、マルウェアの侵入にもアカウント乗っ取りにも気付かないまま、攻撃が成立してしまうリスクがあります。

パスキーは本来、フィッシング耐性の高さが評価されていたのですが、OSやブラウザ上での実装にマルウェアが入り込む余地がある場合、ユーザー側の慎重なクリックやURL確認だけでは防ぎきれないケースがあることが、この手口から見えてきます。

Silver Pass‑ta‑key：クラウドに登録されたキーの差し替え

Silver Pass‑ta‑keyは、パスキーそのものではなく、クラウド認証システムに登録されたキーの管理を狙うもので、攻撃者が被害者のクラウド認証環境に介入し、そこに登録されているパスキーを無効化したうえで、自分が制御できる新しいキーを登録することで、アカウントを乗っ取るというもの。

この攻撃が成立すると、攻撃者は被害者が実際に使っている端末を操作する必要がなくなり、被害者に紐づけられたパスキー対応アカウントへ、攻撃者側が用意した環境から直接アクセスできるようになり、端末ごとのマルウェア感染を待つのではなく、アカウントの根本的な「鍵管理」の部分を書き換えるアプローチと言えます。

クラウドベースのパスキー運用は、複数デバイス間でシームレスに認証を共有できる利便性がある一方、その共有基盤を乗っ取られると、単一端末の対策だけでは防御が難しくなりますし、どのデバイスからアクセスされているかよりも、「どのキーが有効として登録されているか」が支配権の分かれ目になる点が、この手法の厄介さ。

Golden Pass‑ta‑key：SDSを奪われると現在と未来のパスキーが危険に

Golden Pass‑ta‑keyは、Googleパスワードマネージャーに保存されたパスキーを復号するためのマスターキーである「security domain secret（SDS）」を盗み出す手口で、Windows版Google Chromeには、クラウド認証システムへの再登録時にSDSを暗号化されていない状態で扱うプロセスが存在しており、この一瞬の平文状態が狙われているようです。

攻撃者は被害者のChromeに対し、クラウド認証システムへの再登録を強制し、その際のシステム動作を監視することで、内部で処理される平文のSDSを抽出できてしまうようで、SDSは保存されているパスキーを復号するための「鍵の鍵」に相当するため、これを取得されると、既に使っているパスキーだけでなく、今後同じSDSで保護されるパスキーも攻撃者側で復号可能になってしまいます。

Palo Alto Networksは、現行のGoogleの実装ではSDSをローテーションしたり失効させたりする仕組みがないことを問題点として挙げており、一度SDSが漏えいしても、新しいSDSに切り替わらない限り、同じマスターキーで保護された状態が続き、攻撃成功後も長期にわたって影響が残り続ける構造となっていて、単発の事故ではなく、将来のパスキー生成・利用にも影を落とす点で、3つの中でも特に深刻度の高い手法といえます。

ユーザー側でできる対処は限定的、実装レベルの修正が不可欠

3つの攻撃手法はいずれも、パスキー認証のUIや日常的な利用行動ではなく、Windows版Chrome上のGoogleパスワードマネージャーとクラウド認証システムの実装や運用の隙を突いており、そのため、一般ユーザーが設定画面の変更や利用の仕方で根本的に防ぐことは難しい。

マルウェアの侵入を防ぐという意味では、従来どおりのOS・ブラウザ・セキュリティソフトの更新や、不審なソフトウェアをインストールしないといった基本的な対策が必要なのですが、Pass‑ta‑keyのように一度侵入を許してしまうと、ユーザーの操作を挟まずに攻撃が進行するケースも想定されます。

また、Silver Pass‑ta‑keyやGolden Pass‑ta‑keyのように、クラウド認証やSDSの扱い方そのものに問題がある場合は、実装側での仕様変更が欠かせないですし、特にSDSのローテーション機能がない現状では、一度漏えいしたマスターキーによる保護が継続するため、サービス提供者側で失効・更新の仕組みを設計し直す必要があります。

パスキーはパスワードに代わる安全な認証手段として普及が進んでいるとはいえ、その安全性はブラウザやOS、クラウド認証基盤の設計と運用に強く依存しており、今回の脆弱性は、ユーザー側の行動だけでは防ぎきれないリスクがあることを改めて示しており、Googleを含むサービス提供側の早急な対応が求められています。

Iが同じ間違いを繰り返す癖を先回りする攻撃者たちの手口

「ブックマークが消えた。ログイン画面はどこ？」。

そんな何気ない一言をAIに投げただけで、実在しないドメインを自信たっぷりに教えられることがあって、困るのは、その嘘の答え方に「癖」があるということ。

同じ質問をすれば、同じ架空の答えが返ってきやすいのですが、この癖に目をつけたのが「ファントム・スクワッティング」という手口。

幻覚

攻撃者はあらかじめAIがよく答えそうな、実在しないドメインを調べ上げ、そこに偽のログインページを用意して待つ。

検索エンジンの代わりにAIへ直接尋ねる人が増えたからこそ、この待ち伏せは成立し、ハルシネーションは本来「AIの欠陥」として語られてきたはずなのですが、ここでは欠陥の再現性そのものが攻撃の設計図になっています。

同じ構造は、コードを書かない一般社員がAIに指示するだけでアプリや分析ツールを作れる場面にも及ぶようで、アプリ開発では外部の「部品」を組み合わせるのが普通で、AIは実在しない部品名を挙げてしまうことがあって、攻撃者はその名前を先回りし、同じ名前のマルウェアを配布サイトに置いておく。

「スロップ・スクワッティング」と呼ばれるこの手口も、狙われているのは人間の不注意ではなく、AIの応答パターンそのもの。

さらに待ち伏せにとどまらない動きも登場しており、2026年7月、ある犯罪グループがうその情報をネット上に大量にばらまき、関連ワードを検索するとAIの要約にまで「詐欺ではありません」と表示されるようにした手口が確認され、警視庁が注意を呼びかけています。

ここでは攻撃者は幻覚を待っていない。

幻覚が起きるように、先に情報の土壌そのものを作りにいっており「これは詐欺ではないか」と疑ってAIに尋ねる、その確認行動自体が裏をかかれる構造になっているのですから、なんとも恐ろしい。

ここまでの3つの手口に共通しているのは、AIの間違え方が「ランダムな失敗」ではなく「予測可能な癖」として扱われているという一点で、人間の不注意を突く古典的な詐欺とは違い、ここで狙われているのはAIの一貫性の方で、だとすれば、ハルシネーションを完全になくすことは、皮肉にもAIを今より不気味な存在にしてしまう可能性が出てきますよね。

同じ質問に毎回違う嘘を返すAIと、同じ質問に毎回同じ嘘を返すAI、どちらが安全なのか判断が難しいところ。

ニチレイへのサイバー攻撃で犯行声明 「ランサムハウス」とは何者か

冷凍食品大手ニチレイがサイバー攻撃を受けてシステム障害に見舞われる中、ハッカー集団「RansomHouse（ランサムハウス）」がネット上で犯行声明を公表しました。

ニチレイは2026年7月22日、犯行声明を確認しているとしつつも「現在は調査中」と説明し、被害の詳細や攻撃手口はまだ明らかにされていません。

食品メーカーの基幹システムが狙われたことで、物流や受発注への影響、さらには消費者の生活への波及も懸念されていて、声明を出したランサムハウスは、これまでにも日本企業を標的にしてきたとされるハッカー集団です。

ハッキング

冷凍食品などで知られるニチレイは、サイバー攻撃を受けてシステム障害が発生し、障害の詳細な内容は公表されていないのですが、企業の基幹システムが影響を受けると、生産や在庫管理、受発注、物流など、事業の根幹に関わる業務が止まりかねません。

こうした状況の中、ハッカー集団「RansomHouse（ランサムハウス）」がネット上に犯行声明を発表し、自らニチレイへの攻撃を名乗り出ています。

ニチレイは2026年7月22日時点で、ランサムハウスによる声明の存在を確認したと説明しているのですが、声明の内容や要求の有無、情報流出があったかどうかについては「現在は調査中」としており、具体的な被害の全容はまだ明らかになっていません。

犯行声明を発表したランサムハウスは、ランサムウェア攻撃などで知られるハッカー集団の一つで、ニチレイへのサイバー攻撃についてインターネット上で自ら関与を主張し、攻撃主体であると名乗りを上げており、過去にもアスクルに被害をもたらした存在でもあり、日本企業を標的とした攻撃がうかがえます。

世界的に見れば、名の知れたトップクラスの集団ではないものの、日本国内では、既に複数の企業が矢面に立たされている状況だで、ニチレイを含む国内企業が被害に遭うたびに、同集団の名前は徐々に知られるようになり、サプライチェーン全体のリスクとしても存在感が増しています。

過去の事例を踏まえると、今回も攻撃対象企業側の発表や捜査機関の調査結果を通じ、攻撃手口や要求内容が徐々に浮かび上がってくるとみられます

システム障害が企業活動と生活者にもたらす不安

ニチレイのように食品の供給を担う大手企業でシステム障害が起きると、取引企業だけでなく、最終的には生活者にも影響が及ぶおそれがあり、受発注システムの停止は、スーパーやコンビニなど小売店への商品供給の遅れや欠品につながりますし、物流網を支える倉庫の在庫情報や配送スケジュールの管理が麻痺すれば、店舗の棚に並ぶ商品構成が変わり、消費者の選択肢が狭まる場面も出てきます。

加えて、サイバー攻撃の内容によっては、企業が保有する情報資産の保護にも不安が広がり、顧客情報や取引情報など、どの範囲のデータに攻撃者がアクセスした可能性があるのかが明らかになるまでは、取引先や消費者の側も状況を見守らざるを得ません。

ニチレイが「調査中」としている現段階では、被害の規模や性質を断定することはできないのですが、食品の安定供給や情報管理への信頼といった日常の前提が、こうした一件をきっかけに揺らぎかねないことは意識しておきたいところ。

ニチレイに対する今回のサイバー攻撃は、食品メーカーに限らず、多くの企業にとって他人事ではない出来事であり、攻撃主体として名乗り出たランサムハウスは、過去にアスクルにも被害を及ぼしたとされるハッカー集団であり、標的は特定の業種にとどまっていません。

サプライチェーンのどこか1社が狙われれば、取引先にも業務停止や情報流出のリスクが波及する可能性があります。

企業でも、自社のシステムが似た手口で狙われた場合、どの業務が止まり、どの情報が危険に晒されるのかを改めて洗い出す必要があるうえ、インシデント発生時に取引先や顧客へどのような情報提供を行うか、どこまで状況を開示できるかといったコミュニケーションの準備も欠かせない。

ニチレイのような大手企業でも「現在は調査中」という段階を経ることになる以上、事前の備えが実際の対応スピードや信頼回復の度合いを左右しますし、今回の事例は、自社のセキュリティ対策やBCP（事業継続計画）を見直すきっかけとして捉えられます。

WordPress「wp2shell」緊急脆弱性に無料チェックツール URL入力だけで影響確認

WordPress本体に、ログイン不要でサイトを乗っ取られる恐れのある緊急脆弱性「wp2shell」が見つかり、影響範囲の広さから各レンタルサーバーが相次いで注意喚起しています。

こうした中、ロケッタが提供するWordPress更新代行AI「PatchOn」は、サイトのURLを入力するだけで、影響を受けるバージョンかどうかと、どの修正版に更新すべきかを約30秒で判定する無料ツール「wp2shell 影響チェック」を公開。

wp2shellチェック

管理画面にすぐ入れない運営者でも、まず「自分のサイトは危ないのか」を素早く確認することができるようですよ。

wp2shell 影響チェック | PatchOn（パッチオン）

ログイン不要で乗っ取られる「wp2shell」とは

wp2shellは、WordPress本体に見つかった2つの脆弱性を組み合わせて悪用する攻撃で、その内容は、SQLインジェクションの脆弱性（CVE-2026-60137）と、REST APIバッチ処理の不備（CVE-2026-63030）で、これらが組み合わさることで、攻撃者はログインや管理者権限を持たない状態でも、外部から任意のコードを実行できるおそれがあるとされています。

深刻度は「緊急」と評価されており、特定のプラグインに依存する問題ではなく、特別な追加機能を入れていない標準構成のWordPressサイトも含め、広い範囲が影響を受けます。

国内では7月19日以降、主要レンタルサーバー各社が次々に注意喚起や対応方針を公表しており、三連休とタイミングが重なったことで、初動が遅れたサイトも少なくないと見られていて、日常的に更新を後回しにしているサイトほど、被害に遭うリスクが高まっています。

影響バージョンと修正版　どのサイトが危ないのか 

影響を受けるのは、WordPress本体の特定バージョンで、SQLインジェクション単体では6.8.0〜6.8.5が対象となり、wp2shell攻撃としては6.9.0〜6.9.4および7.0.0〜7.0.1が含まれます。

これらのバージョンを利用しているサイトは、ログイン不要の攻撃にさらされている可能性があるため、早急な確認と更新が求められ、脆弱性を修正したバージョンとして、7.0.2・6.9.5・6.8.6が既に公開済みだと案内されています。

自動更新を有効にしているサイトであれば、こうした修正版が比較的早く適用されるのですが、自動更新を無効にしている環境では、運営者自身がバージョンを確認し、手動で更新する必要がありますので、今すぐ確認するようにしましょう。

複数のWordPressサイトを抱えていたり、制作会社任せでバージョン情報を把握していなかったりする場合、自分のサイトがどこまで影響範囲に入るのかを把握しづらいので、まずはこうした状況で「バージョンと更新先」を簡単に知るための仕組みが求められていました。

URLを入れるだけ　無料の「wp2shell 影響チェック」 

ロケッタは、この課題に対し、WordPress更新代行AI「PatchOn」の一機能として無料ツール「wp2shell 影響チェック」を公開。

利用方法はシンプルで、対象サイトのURLを入力し、「チェックする」ボタンを押すだけで、およそ30秒後には、そのサイトがwp2shell脆弱性の影響を受けるバージョンかどうか、そしてどの修正版へ更新すべきかが表示されるようになっています。

チェック結果には、判定に用いた「検出シグナル」もあわせて示され、うれしいことに登録不要・無料で利用することができます。

ツール側は対象サイトに対して公開情報の受動的な取得のみを行う設計とされ、攻撃的なアクセスは一切行わないと明記されている一方、バージョン情報を隠しているサイトなどでは判定できないこともあり、その際に「安全」と表示することはないという制限も示されています。

また、サイトが既に侵害されているかどうかを調べる機能は含まれておらず、「自分が管理するサイト」に限った利用が前提となっているので、まず影響の有無と更新先だけを素早く知りたい運営者向けの初動支援ツールと言えます。

自動更新は怖い、手動更新は続かない

今回のwp2shell問題で、レンタルサーバー各社の告知から見えてきた分かれ目は、「修正版が公開されてから、自分のサイトに適用されるまでの時間」だとロケッタは説明しています。

自動更新が有効なサイトでは、修正版が比較的早く当たりやすい一方、「確認せずに自動で更新されるのは怖い」という理由から、自動更新を無効にしている運用も少なくなく、過去のアップデートで表示崩れや不具合を経験したサイトほど、この傾向が強いようです。

結果として「自動更新は怖いが、手動更新は忙しくて続かない」という構造が、更新放置を生み出し、脆弱性にさらされる時間を長くしていると指摘しており、PatchOnは、この構造を変えるためのサービスとして位置づけられています。

ステージング環境で本番と同じ構成を再現し、更新を適用した状態でスクリーンショット比較や主要機能のテストを行い、全ての検査をパスした更新だけを本番サイトへ自動反映し、問題が見つかった場合はAIが壊れる原因を自動修正する。 万一の際には、WordPress管理画面からワンクリックで復元できる仕組みも用意されている。

いまWordPress運営者が取るべき最初の一歩 

ロケッタは、社内検証でWordPress更新時に発生する代表的な不具合82パターンに対し、AIが100％自動修正できたと説明しています。

PatchOnでは、無料プランでも月1回の検査付き自動更新が利用可能で、プラグインはWordPress.orgで公開されています。

今回公開された「wp2shell 影響チェック」は、こうしたサービスの一環として、まず影響の有無を知ってもらうための入口に位置づけられ、WordPressで企業サイトやメディア、ブログを運営している場合、最初の行動として、自サイトのURLをツールに入力し、現状のバージョンが影響範囲に入っているか、どの修正版を目指せばよいかを確認することが重要になります。

そのうえで、自動更新を完全に止めるのではなく、「検査してから自動で更新する」という運用へ切り替える選択肢を持つことで、脆弱性への露出時間を短くしながら、表示崩れなどの不安も抑えられるようになります。

wp2shellのような緊急脆弱性は今後も発生しうるため、「気づいたときだけ慌てて更新する」状態から、日常的に備える体制への移行が問われてきてきます。