相次ぐ情報漏えいの原因は、エンジニアでもシステムでもなく組織構造にある

  • セキュリティ
  • 組織
  • PHP

相次ぐ情報漏えいの原因は、エンジニアの技量や古いシステムではなく、変更と停止を決断できない組織の体制にある。2026年10月のPHP2Shellでは、修正版の公開前に停止した会社と、不正なプログラムを確認した後も半日動かし続けた会社があった。

PHPの開発チームは10月20日、深刻度「緊急」の脆弱性2件を翌21日の日本時間23時に修正すると予告し、内容は伏せたまま全利用者に更新の準備を求めた1。21日の昼過ぎから国内のWebサービスは相次いで停止し、さくらインターネットは13時に一部サービスの機能を停止した2。首相と国家サイバー統括室はXで、修正版をすぐに適用できない場合はWebサイトの一時停止も有効な手段だと呼びかけた。脆弱性管理のサービスyamoryを運営するアシュアードの集計では、X上で確認できた停止の告知は23日14時の時点で502件に上る3。各社の対応はWebセキュリティ診断センターの一覧にまとまっている。

同週、GMOインターネットのFX自動売買向けVPS「お名前.com デスクトップクラウド」では、不正なプログラムの確認から全サーバーの停止まで半日を要し、その間に利用者の損失が出た。同社の公表によれば、19日に顧客からの問い合わせで調査を始め、20日に顧客のサーバーで不正なプログラムの設置を確認し、21日4時に全プラン26,739台を停止した4。22日の第2報では、サーバー内に保存されていた取引口座のログイン情報が第三者に取得され、不正に利用された可能性があると認めている5。朝日新聞が報じた神奈川県の男性の口座では21日に約2秒で400万円超が消え、その後の取引を含めた損害は600万円を超えた6。愛知県の女性はサーバーが停止した後の22日未明に意図しない取引を繰り返され、430万円余りの資金がほぼ底をついたという。

修正版の公開を待たずに停止できた組織には、停止の損失と攻撃の被害を比べてその日のうちに決断する権限があった。半日動かし続けた組織には、技術ではなくこの権限が欠けていた。相次ぐ情報漏えいの原因も同じところにある。

停止を決断できた体制

筆者が確認したなかで、日本で最も早く停止を決断したサービスは保育ICTサービスのコドモンであった。同社は対応後にどういった動きで決断したかをまとめた記事を公開しているため、こちらから引用する7。同社は21日9時1分に脆弱性情報を把握し、13時台に停止した。経営メンバーは午前のうちに夜間の計画停止の方針を承認し、社長や営業部門の執行役員まで即時停止に合意していた。修正方法が広まって23時より前に攻撃が成立すると分かった昼過ぎ、同社はその権限で即時停止を決断した。「お客さまへの影響よりも攻撃を受けた場合の被害のほうがはるかに大きいと判断した」と同社は説明する。自社のどこにPHPがあるかを把握する体制と、損失と被害を比べて決断する経営が情報の把握から3時間半で動いた。

不動産ポータルでは競合3社が同じ夜にそろって停止したが、停止した時刻は3社で違った。LIFULL HOME'Sは21日20時から緊急メンテナンスに入り、告知に理由はPHPの脆弱性だと明記した8。SUUMOは修正版が公開された21日23時にメンテナンスを始め、告知の理由は「サービス向上およびシステム安定化」とだけ書いた。アットホームも21日夜に各種サービスを停止したが、告知は22日に出て、23日夕方になっても路線図検索やアプリの一部は停止したままだった9。PHPの名を出した会社は1社だけだが、競合3社が同じ夜にそろって停止した以上、原因はPHP2Shellだ。Amazonは公表の4日前からハニーポットで攻撃の試行を観測しており10、Cloudflareによれば修正版の公開から45分で数万件、翌日には数百万件の攻撃が観測された11。20時に停止した会社と23時に停止した会社では、攻撃が成立しうる状態でサービスを動かした時間が3時間違う。

GMOは不正なプログラムを確認した後も半日サーバーを動かし続け、その間に利用者の損失が出た。同社は20日18時30分の時点で「システムメンテナンス」の告知を掲載し、契約中のサーバーはメンテナンス中も利用できると案内していた12。同社は翌21日4時に全サーバーを停止し、22日夕方に取引口座の認証情報が盗まれた可能性を利用者に伝えた。利用者の口座の資金は、この間の21日と22日に消えた。同じグループのGMOリサーチ&AIは、その2週間前の10月5日にアンケートサイトinfoQの脆弱性を突かれ、会員全件にあたる個人情報の持ち出しを公表したばかりだった13。侵入経路は調査中なので、ここで技術の優劣は論じない。顧客の資産に直結するサービスで不正なプログラムを確認してから全停止まで半日かかり、その判断の間に損失が出たという事実を論じる。

サポートの切れたPHP 8.1以前を使っていた組織には、停止以外の選択肢がなかった。修正版は8.2以降にだけ出て、8.1以前に公式の修正版はない1。残る選択肢は数か月かかるバージョンアップか、それまで停止し続けるかの2つで、停止を決断できない組織は攻撃を受けるのを待つしかなかった。

事故のたびに原因は現場の技量か古いシステムに求められるが、修正版の公開後まで動けなかった組織のエンジニアがバージョンアップのやり方を知らなかったわけではない。停止してよいという決断を、必要な速さで引き出せない組織の中にいただけだ。

既知の脆弱性から侵入される事故は、2026年7月以降の国内でも繰り返し起きている。デジタル庁は9月11日、政府共通の業務環境GSSから約24.6万件の個人情報が漏えいした可能性を公表した14。侵入口は外部からの保守に使っていたVPN機器だった。デジタル庁は脆弱性の存在を事前に把握しながら、緊急度の高い他の脆弱性から順に対応している最中に悪用されたと説明している。侵入者は保守用のアカウントを奪って大量のファイルにアクセスし、6月25日の検知から不正アクセスと判明するまでに2週間を要した。警察庁の集計でも、2026年上半期のランサムウェアの被害報告は123件で半期として過去最多となり、侵入経路はVPN機器が約5割を占める15。攻撃者は未修正の脆弱性や漏えいした認証情報を使って入ってくるのであって、未知の手口で入ってくるのではない。2021年に電子カルテを暗号化された徳島県の半田病院から2026年のGSSまで、侵入口は修正方法が公表されていた既知の穴である。

被害の規模も計画停止と比べられる大きさではなくなった。IDCフロンティアは10月7日、クラウド基盤の一部がランサムウェアに侵害され、495の企業や自治体のデータは取り出しと復元が困難だと公表した16。大阪公立大学では10月2日、仮想化基盤に侵入されて約500台のサーバーが止まり、復元に必要なバックアップの多くも暗号化された17。1週間の全面休講の後、在学生や卒業生ら少なくとも13万人分の個人情報が外部に出たかどうかを調べている。

原因は、日本企業が長年「正しいやり方」として積み上げてきた開発・運用の体制にある。この体制は変更をリスクとして扱い、影響範囲を小さくすることを開発の目的にし、リリースには稟議と計画停止の調整を求めてきた。運用・保守は開発の付属物として予算を削られてきた。その下では脆弱性対応やバージョンアップ、緊急停止が「やってはいけないこと」の側に分類され、先送りのたびに次の変更は大きく、高くなる。この体制がシステムを変更する能力を奪ってきたのであり、解決の責任も経営にある。

人間の判断より速い悪用

脆弱性はソフトウェアが公開された後に見つかる。ソフトウェアは書かれた時点の知識と前提で作られるのに対し、攻撃側の知識は公開後も増え続けるからだ。脆弱性の多くは、書いた時点では誰も問題と認識していなかった箇所から、後から判明する知識の差分として現れる。2014年に見つかったShellshockは、UNIX系OSの標準シェルbashに1989年から存在していた欠陥だった。2021年のLog4Shellでは、JavaのログライブラリLog4jが2013年から備えていた外部サーバーを参照する機能そのものが攻撃経路になった。PHP2Shellも同じで、PHPがWebリクエストを受け取る最も基本的な経路に十数年前から存在していた欠陥が2026年になって見つかり、PHP 5以降のすべての環境が対象になり得た。

後から見つかる理由起きること
攻撃技術の進歩ファジングやAIによる自動探索が、昔からあった弱点を後から見つける
前提の変化安全とされた暗号方式が計算機の性能向上で破られ、閉域網を前提に作られたシステムがインターネットにつながる
依存の継承自分たちが書いていないライブラリやランタイムの欠陥を、使っているだけで引き継ぐ
検証の非対称テストは期待どおりに動くかを確かめるが、攻撃者は想定外の入力で何が起きるかだけを探す

供給側の修正が遅れた理由も、組織の意思決定にあった。PHP Foundationは修正版の公開と同じ日に、脆弱性の兆候を2024年の外部監査の時点で把握していたと明かした18。互換性を壊す案やDoSの危険を増やす案など複数の修正案の間で、合意制で動く少人数のセキュリティチームが決めきれず、作業は数か月にわたって止まっては再開した。同財団はこれを「構造的な失敗」と呼び、意思決定を多数決に改めると表明している。利用者の側で停止を決断できなかった組織と供給者の側で修正を決断できなかった組織は、同じ理由で遅れた。

使う側の組織には、出荷時に欠陥のない部品を選ぶ力ではなく、出荷後に出続ける修正を取り込み続ける能力が求められる。Node.jsのアプリケーションはnpm経由で数百から数千のパッケージに依存するのが普通で、2025年9月には週に合計20億回ダウンロードされる人気パッケージ群が乗っ取られた19。自分たちが書いていない部品の欠陥は、使っているだけで引き継ぐ。

その修正は人間が処理できる量を超えて出る。脆弱性に付与される識別子CVEは、2026年8月4日から10月3日までの2か月間だけで27,489件が登録された20。1日あたり450件で、2024年の年間登録数の3分の2が2か月で出た計算になる。発見の側にはAIが入った。Anthropicが4月に始めたProject Glasswingでは、同社のモデルが26,153件の脆弱性を見つけた。脆弱性情報を扱うVulnCheckが9月に集計したところ、開発元に報告できたのは1割に満たず、修正が確認できたのは202件だった21。見つける速さに対して、検証して直す側の人間が律速になっている。

公表から悪用までの時間は人間の会議より短くなった。Radwareが9月に公表した2026年上半期の報告書では、脆弱性の公表から最初の攻撃までの平均は2024年の53日から2025年の21.5日に縮み、2026年7月にはマイナス8時間に転じた22。公表の当日かそれ以前に悪用される割合は8割を超える。Google傘下のMandiantの年次報告でも、侵入の32%は脆弱性の悪用が入口で6年連続の首位となり、初期侵入を担うグループが次のグループに環境を引き渡すまでの時間は2022年の8時間超から2025年には22秒に縮んだ23。PHP2Shellで公表の4日前から攻撃の試行が始まり、修正版の公開から45分で数万件に達した経過も、この傾向の一例に過ぎない。

攻撃の自動化は国内でも観測されている。JPCERT/CCは10月9日、国内で相次ぐ不正アクセスについて注意喚起を出し、23日の更新でAIを用いたペネトレーションテスト基盤を悪用した攻撃を手口の1つに加えた24。公開されたWebアプリケーションに対して、さまざまな脆弱性の探索と悪用の試行や設定ファイルの窃取を自動で行うものだ。マクニカの集計では、国内法人のWebシステムからの個人情報漏えいの公表は2024年の62件、2025年の84件に対し、2026年は10月6日までに119件に達し、うち81件が7月以降に集中している25。攻撃コードの生成から標的の探索や侵入、内部での展開までが自動で連鎖する以上、防御側は人数の上限のない攻撃者が公表と同時に動き始める前提で判断しなければならない。

判断に数日かかる体制は、技術がどれだけ優れていても構造的に間に合わない。既知の脆弱性から侵入される事故は昔から同じ形で起きていたが、今は修正が人間の処理能力を超える量で出て、公表から悪用までの時間が人間の会議より短くなった。人間が会議を招集し、影響範囲を調べ、停止の是非を稟議にかけている間に攻撃は終わっている。

変更を悪とみなす体制

システム開発の仕事の大半はシステムが完成した後に始まる。業務システムの寿命は10年を超えることが珍しくなく、その間にはOSやミドルウェアの更新やライブラリの差し替え、脆弱性対応、法改正への追随が続く。ライフサイクル全体で見れば、作る工程は2割に過ぎず、残りの8割は動かし続ける工程だ。経済産業省のDXレポートも、企業のIT関連費用の約8割が既存システムの維持・運営に充てられていると指摘した26。

日本企業の多くはこの8割を「保守」と呼んで開発の付属物として扱ってきた。予算は開発プロジェクトに付き、完成と同時に体制は縮小され、保守は最小限の人数と費用で壊れたら直す仕事になる。脆弱性対応はまさにこの8割の側で発生する。

その間にシステムが動く言語ランタイムは勝手に古くなる。PHPやNode.js、Ruby、Perlといった言語ランタイムのサポート期間はおおむね1バージョンあたり2年半から4年で、過ぎれば修正版が出なくなる。10年使うシステムは途中で2回から3回のメジャーバージョンアップを迫られる計算だ。

同じ脆弱性対応でもサポート期間内と切れた後では費用が桁違いになる。サポート期間内であれば、脆弱性対応は数時間のパッチ適用で済み、挙動も変わらない。サポートが切れた後では、同じ対応が言語仕様の非互換を潰して依存ライブラリを総入れ替えし、全機能を再テストする数か月のプロジェクトに化ける。その間にまた新しい脆弱性が出る。PHP2ShellでPHP 8.1以前を使っていた組織はこの状況に置かれ、パッチはなくバージョンアップには数か月かかるから、停止するしかなかった。国内に残るPHP 5系や7系、Perl CGI、古いRailsアプリケーションの多くも、先送りを重ねるうちに変更のコストが払えない大きさに膨らんだものだ。放置は現状維持ではない。

動いているシステムに手を入れる作業には、作業そのものとは別のコストがかかる。

コスト内容
サービスを停止するコスト計画停止の日程を顧客や関係部署と調整し、告知し、業務への影響を吸収する
壊れていないことを確かめるコストテスト環境で検証し、本番で動作確認する
社内の承認を得るコスト変更管理の委員会にかけ、稟議を回し、関係者の合意を取る

日本企業の開発・運用体制はこの3つを徹底的に重くする方向で作られてきた。変更管理の手続きは変更起因の障害を防ぐためにあり、計画停止の事前通知は顧客への配慮である。プルリクエストを小さく分割して既存の挙動に触れないよう修正を局所化する習慣も、レビューしやすく事故を起こしにくい。どれもそれ自体は正しい。

問題は、これらすべてが「変更は悪いことである」という前提の上に積み上げられていることだ。変更を減らして影響を閉じ込めることが目的になった組織では、変更のコストを下げる仕組みに投資されない。自動テストは整備されず、デプロイは手順書と目視に頼り、システムの全体像を知る人間は減っていく。影響範囲を小さくすることだけを目的にした開発が続けば、フレームワークの更新やアーキテクチャの見直しのような影響範囲の大きい修正は永遠に行われない。日本企業が典型的にやってきたことは、ほぼすべてがこのアンチパターンに該当する。

3つのコストはどれも前回の変更からの経過時間に比例して膨らむので、ここに複利が働く。長く触っていないシステムほど差分は大きく、停止時間は長く、承認は重い。重いから先送りし、先送りするから次はさらに重くなる。その間にシステムを理解していた担当者が去り、テストコードは腐る。変更起因の障害を防ぐために設計された体制が、変更そのものを最も危険な行為に変えている。デジタル庁で把握済みの脆弱性が順番待ちになっていた事情も、PHP2Shellで修正版の公開前に停止を決断できなかった組織の内側も、同じ複利の中にある。

変更のコストを下げる道具

変更を日常の小さな単位に分ければ、停止の調整と承認は要らなくなる。DependabotやRenovateのようなツールは、依存ライブラリの更新を検知して自動でプルリクエストを作り、CIで自動テストが通れば本番に反映する。ただし前提は自動テストの存在で、テストがなければ壊れていないことを確かめるコストが消えず、自動更新は成立しない。DORAの調査が繰り返し示してきたように、デプロイ頻度が高い組織ほど変更失敗率も低い27。頻繁に変えるから安全なのであって、変えないから安全なのではない。

下のレイヤを手放せば、対応すべき変更の量は大きく減る。クラウド事業者が提供するデータベースやアプリケーションの実行基盤を使えば、OSやミドルウェア、ランタイムの脆弱性対応は事業者側で行われる。PHP2Shellでも、さくらインターネットは自社が提供するPHPに修正を適用し、利用者は手を動かす必要がなかった2。Cloudflareは修正版の公開より約9時間早く独自のWAFルールを無料プランを含む全利用者に配信し、配下のサイトへの攻撃を遮断し始めた28。責任共有モデルの境界より上、つまりアプリケーションのコードと依存ライブラリ、ランタイムのメジャーバージョンの選択は自社に残る。

手放すことは手抜きではない。AIによって何でも自前でできるように見える時代だからこそ、意図的に自社で持たないと決断する部分を作り、人間の判断が必要な場面を減らすことが設計になる。24時間動く攻撃側に対して人間が全レイヤを見張る体制は成立しない以上、見張らなくてよいレイヤを増やすしかない。

WAFは修正ではなく、修正版を適用するまでの時間を買う手段である。アプリケーションの手前で攻撃パターンを遮断する仕組みなので、Cloudflareは修正版の公開前から攻撃を遮断できた。ただしWAFは3つのコストのどれも払わずに時間を買うだけで、脆弱性は残る。「WAFがあるから大丈夫」がパッチ適用とバージョンアップの先送りを正当化する口実になった組織が最も危うい。

どの道具を選んでも、いつサービスを停止するかやテストと自動化にいくら投資するか、どのレイヤを手放すか、どこまでのリスクを受け入れるかという判断は残る。これらの判断は経営にしかできない。

損失の見え方の非対称

現場が停止を決断できない理由は、損失の見え方の非対称にある。計画停止の損失は見える。1時間停止すれば売上がいくら減り、顧客対応に何人かかり、誰の責任になるかが分かる。侵害による損失は見えない。いつ起きるか分からず、起きるまで金額も決まらず、誰の責任かも曖昧だ。確実な損失と不確実な損失を天秤にかければ、個人としては「今回は見送る」が常に合理的な選択になる。個人の合理が積み重なって会社の不合理が生まれるのであって、担当者の怠慢が原因ではない。

見えない損失は小さくない。IDCフロンティアの顧客495社は自前のバックアップがなければデータを失った。大阪公立大学は1週間授業を止め、GMOの利用者は自分の口座から数百万円を失った。警察庁のアンケートでは、ランサムウェアの被害組織のうち復旧に総額1,000万円以上を要した割合が6割を占め、1か月未満で復旧できた組織は5割に満たない15。計画停止なら数時間で済んだ作業を先送りした結果、計画外の停止が数週間から数か月続く。

多くの組織は侵害を受けたことに自分で気づいてもいない。Mandiantの報告では、2025年に侵害を自力で検知できた組織は52%で、残りは外部からの通知で知った23。マクニカが7月以降の国内81件の公表文を分析したところ、65件は侵入の原因を分類できるだけの説明がなかった25。漏えいを公表した時点で、自社がどこから入られたかを説明できない組織が8割を占める。ログを取っていない、取っていても見ていない、異常を判断する基準がない組織の「うちは被害に遭っていない」は、検知できていないことの裏返しに過ぎない。

パッチを当てても、適用前に侵入した攻撃者は追い出せない。PHP2Shellでは公表前から攻撃が始まっていたため、JPCERT/CCは修正版の適用と同時に適用前の侵害がないかの確認を求めた1。GMOの事故では、サーバーを停止した後にも利用者の口座から資金が消えた。盗まれた認証情報は利用者が自分で変えるまで有効であり続ける。侵入者がWebシェルや別の侵入経路を仕込み、ログから痕跡を消すのは難しい作業ではないので、パッチ適用で安心した組織の内側に攻撃者はそのまま残る。修正版が出た後の数か月が最も危険であり、確認できる体制のない組織はJPCERT/CCの要請に応えようがない。

「うちには盗まれて困るデータがない」という見積もりも誤っている。JPCERT/CCの注意喚起は、BIツールや従業員向けの管理システムのように不特定多数の利用を想定していないシステムが侵害され、内部の情報が漏えいする例を挙げている24。乗っ取られたサーバーは、保存しているデータとは関係なく、ほかの組織への攻撃の踏み台やフィッシングサイトの置き場、マルウェアの配布元として使われる。被害者ではなく加害側のインフラとして社名が出た時点で取引先からの信用は失われ、場合によっては法的な責任も問われる。

攻撃されるリスクの大きさを正確に認識する責任は、エンジニア組織ではなく経営層にある。経営層は少なくとも次のことを数字で答えられなければならない。

  • 自社のどのシステムがインターネットに面しているか
  • どのシステムがサポート切れの部品で動いているか
  • 侵害されたときに何日停止し、いくら失うか
  • 誰に報告義務が生じるか

これらを数字で把握していない経営者は、リスクを受け入れているのではなく、リスクを知らないだけである。知らないリスクは管理できない。

各社が合理的に先送りを重ねた結果が、経済産業省が2018年に「2025年の崖」と呼んだ産業規模の技術的負債だ。同省はレガシーシステムの放置による経済損失を2025年以降に最大で年間12兆円と試算した26。DXレポートが開発側から見た負債と、本稿が攻撃者側から見ている脆弱性は同じものである。エンジニア組織の問題は会社の問題であり、会社の問題は産業の問題になっている。

損切りする側に立つ経営

経営は個々の脆弱性に対応するかどうかを決断するのではない。変更を減らし続けて負債を複利で増やす側に自社を置くか、変更を日常にして能力を複利で積み上げる側に置くかを決断する。前者にいる限り、どれだけ優秀なエンジニアを雇っても間に合わない。

計画停止という確実な損失を起きるかどうか分からない侵害より先に取る理由は、攻める側と守る側の非対称にある。ペネトレーションテストや脆弱性診断は、依頼者の同意の範囲、責任ある開示、不正アクセス禁止法によって縛られている。本物の攻撃者は何にも縛られず、時間も選ばない。攻撃されてから対処するのでは構造的に勝てない以上、攻撃される前に自ら診断を依頼し、見つかった弱点は被害が出る前に処理するしかない。サービスの停止や古いシステムの廃棄、作り直しはどれも損失を伴うが、被害が出てからでは遅い。

守る側には社会的な責任もある。企業は利用者の個人情報と通信の秘密を預かっており、個人情報保護法は漏えい時に監督機関への報告と本人への通知を義務づけている。企業がその義務を負う相手は利用者と社会だ。計画停止で失った売上は翌月に取り戻せるが、漏えいした情報と失った社会的信用は戻らない。「承認が下りなかった」「停止の調整がつかなかった」は、社内では通っても社会には通らない。損切りの根拠は金額の比較ではなく、預かっている側としての責任である。

ただし守る側にも節度が要る。WAFやログ監視も通信内容を検査する行為なので、通信の秘密との関係で正当な業務の範囲に収めなければならない。守る側に求められる倫理は、節度の内側で被害が出る前に動くことだ。

緊急時の権限は事前に委譲しておく。誰が何を停止してよいかを事前に決断し、緊急変更の枠と定期メンテナンスの時間帯を契約とSLAに織り込み、稟議なしで停止や変更ができる範囲を定めておけば、当日は実行するだけで済む。コドモンは即時停止の権限を午前のうちに社長まで合意していたので、3時間半で停止できた。

変更する能力には恒常的に投資する。自動テストやCI/CD、依存の自動更新や構成管理、検知の仕組みは、動かし続ける8割の期間を支える基盤である。だから運用費として毎年の予算に組み込み、開発とセキュリティの予算を分けない。両者は同じ能力を使う同じ仕事だからだ。

リスクは可視化して定期的に報告する。サポート切れの部品で動くシステムの一覧や未対応の重大な脆弱性、侵害時に想定される停止日数と損失額、報告義務の有無を金額と期限つきで取締役会に上げ、対応しないと判断するならそれを明示的な経営判断として記録に残す。経済産業省とIPAの「サイバーセキュリティ経営ガイドライン」が経営者に求めているのも、要するにこのことだ29。

2026年10月21日に修正版の公開を待たずにサービスを停止した組織は、特別な技術ではなく、自社のどこにPHPがあるかを把握して停止の損失と攻撃される被害を比べ、経営がその日のうちに決断する体制を持っていた。次の脆弱性が公表された日に同じ決断ができるかどうかは、今日までに経営が作ってきた体制で決まる。

出典

  1. JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日） ↩ ↩2 ↩3

  2. さくらインターネット「【重要】PHPの脆弱性に関する当社の対応状況について」 ↩ ↩2

  3. マイナビニュース「PHPの重大な脆弱性、国内で500件超のサービス停止告知、約6割は再開確認できず」（2026年10月23日） ↩

  4. お名前.com「【重要】[お名前.com デスクトップクラウド]第三者による不正アクセスに関するお詫びとお知らせ（2026年10月21日 4:00時点）」。第1報は、サーバー内の情報が閲覧された可能性に触れる一方、クレジットカード情報を含む決済情報は同社では保持していないとしている。 ↩

  5. お名前.com「【重要】「お名前.com デスクトップクラウド」への不正アクセスに関するお詫びとお知らせ（第2報）」（2026年10月22日）。MT4/MT5などの取引ツールと取引口座の認証情報を閲覧された可能性があるとして、同サービス以外の端末からのパスワード変更と、取引履歴と残高の確認を利用者に求めた。 ↩

  6. 朝日新聞「2秒で失った400万円」（2026年10月23日） ↩

  7. コドモン Product Team Blog「PHP2Shellへの対応を振り返って」（2026年10月23日） ↩

  8. LIFULL「10月23日17時更新：主要サービス・サイト再開のお知らせ」 ↩

  9. アットホーム「各種サービス緊急システムメンテナンスのお知らせ」（2026年10月22日） ↩

  10. Amazon Threat Intelligence, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot" ↩

  11. GIGAZINE「CloudflareがPHP2Shellの悪用試行件数を報告」（2026年10月23日） ↩

  12. piyolog「お名前.com デスクトップクラウドへの不正アクセスについてまとめてみた」（2026年10月23日）。20日18時30分時点のメンテナンス告知の文面と、OANDA証券など取引業者各社の注意喚起がまとまっている。 ↩

  13. ScanNetSecurity「GMOリサーチ&AI 運営のアンケートサイト『infoQ』に不正アクセス、89万4,082件の個人情報外部持ち出しを確認」（2026年10月19日） ↩

  14. piyolog「デジタル庁のガバメントソリューションサービス（GSS）への不正アクセスについてまとめてみた」（2026年9月11日）。デジタル庁は、悪用された脆弱性は公表時のCVSSで「中」程度で、公表時の深刻度に応じた一般的な対応より早く対処を進めていたと説明している。検知から公表までは2か月半である。 ↩

  15. 警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（2026年9月）。侵入経路と復旧の費用・期間は被害組織へのアンケートによる。被害組織の約6割は中小企業である。 ↩ ↩2

  16. IDCフロンティア「IDCFクラウドの一部システムへの第三者からの不正アクセスによる障害について」（2026年10月8日）。対象は東日本リージョン1の4ゾーンで、同社はデータの復元は顧客自身のバックアップからのみ可能との見解を示した。 ↩

  17. ビジネス+IT「大阪公立大学、ランサムウェア攻撃でサーバー500台停止、13万人分の個人情報流出か」（2026年10月） ↩

  18. The PHP Foundation, "Today's PHP Security Release and How We're Strengthening PHP Security"（2026年10月21日）。原文では "a structural failure, caused by both the security team's decision process and its lack of resources" と表現している。 ↩

  19. Semgrep, "chalk, debug and color on npm compromised in new supply chain attack"（2025年9月） ↩

  20. Jerry Gamblin, "Decision Models vs. CVE Data"（2026年10月）。2026年8月4日から10月3日までに283のCNAから登録されたCVEを全件対象にした分析で、件数はその母数である。 ↩

  21. VulnCheck, "Anthropic Glasswing: Receipts"（2026年9月8日）。Anthropicが開示した一覧に載ったのは2,736件で、修正済み202件、開発元に報告済みだが修正未確認が2,096件、取り下げが245件である。 ↩

  22. Radware, "H1 2026 Global Threat Report"（プレスリリース、2026年9月9日）。マイナス8時間の数値は、報告書を伝えたSiliconANGLEの記事による。Zero Day Clockの7月23日時点のデータである。 ↩

  23. Google Cloud / Mandiant, "M-Trends 2026"（2026年）。2025年の調査を集計したもので、侵入から検知までの中央値は14日である。 ↩ ↩2

  24. JPCERT/CC「（随時更新）直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月9日、23日更新）。手口はケースAからEに分けられ、AIを用いたペネトレーションテスト基盤の悪用はケースEとして23日に追加された。国家サイバー統括室は10月14日に各府省庁の注意喚起の一覧を出している。 ↩ ↩2

  25. マクニカ「WEBシステムからの個人情報漏洩が止まらない――2026年の事案を分析する」（2026年10月7日）。集計対象は国内法人が運営するWebシステムを通じた個人情報の窃取・漏えい事案で、ランサムウェアやリスト型攻撃は除いている。 ↩ ↩2

  26. 経済産業省「DXレポート 〜ITシステム『2025年の崖』の克服とDXの本格的な展開〜」（2018年9月） ↩ ↩2

  27. DORA, "DORA Research" ↩

  28. PPC Land, "Cloudflare blocks php2shell exploits 9 hours before PHP flaws went public" ↩

  29. 経済産業省・IPA「サイバーセキュリティ経営ガイドライン」 ↩