外部に公開しているもののうち、いま更新が止まっているのはどれですか。この質問に即答できる会社は、思ったより少ないはずです。サイト本体は制作会社が見ているが、途中で入れた分析ツールは誰が入れたか分からない。サーバーのPHPは上げたいが、上げると何が壊れるか試していない。2026年6月1日から10月8日までに公表・報道された漏えい事案を集計した調査資料を原因別に見ると、この「数えられていない公開資産」が一定の割合を占めています。数字を分解したうえで、更新が止まる理由と、棚卸しの進め方に落とします。
25件は、4つの層に分かれて起きていた
集計の母数は176件です。公式発表が確認できたもの114件と、報道のみで公式が未確認のもの62件の合計で、対象期間は2026年6月1日から10月8日まで。このうち脆弱性の悪用が原因とされたものが25件、全体の14%でした。人的ミス28件、認証情報の窃取やアカウント乗っ取り27件に次ぐ規模で、原因不明の60件を除いた116件の中では主要な区分のひとつになります。公開情報だけを積み上げた資料なので網羅性に限界があり、小規模な事案は拾いきれていない可能性がある点は先に書いておきます。
25件を「どこが古かったのか」で並べると、起きている層が4つに分かれます。ひとつ目は基盤に組み込まれた第三者製のソフトで、ISP向けのメールシステムに組み込まれていたソフトのゼロデイ脆弱性を悪用された事案（最大約1,422万件）や、画像共有サービスの画像サーバーで任意のコマンドを実行された事案（約2,362万件）が公表されています。
ふたつ目は境界の機器です。行政機関のシステムでは、ネットワーク接続機器の脆弱性を利用して侵入され、保守事業者のアカウントが使われたことが公表されました（約24.6万件）。3つ目が社内向けに立てた分析系のツールで、BIツールの脆弱性が原因とされた事案が複数あります（約44万件、約17万件）。採用応募の仕組みで分析ツールの脆弱性が原因とされた事案もありました。
4つ目が、いちばん数の多いサイト・ECの層です。1ページ分のSQLインジェクションを突かれた事案（約5.5万件）、サイトのプラグインの脆弱性から不正プログラムを置かれた事案、ECの決済アプリやペイメントアプリを改ざんされた事案が複数並びます。報道のみで公式が未確認のものには、WordPressの脆弱性を悪用されたとされる事案や、ECパッケージ用の決済プラグインの脆弱性を突かれたとされる事案も含まれています。
公表文に出てくる「修正の適用前」という言い方
この25件を読んでいて目につくのは、原因の記述に使われている言葉です。「更新を適用していなかった」「修正の適用前に侵入された」。どちらも実際に公表されている表現で、脆弱性そのものは既知で、修正も出ていたという状況を指します。
もうひとつ別の型もあります。更新の有無ではなく、作ったときの設計に起因するものです。生命保険会社の事案では、調査結果としてアクセスや照会の制御の不足、短時間の大量照会を監視・制御する機能の不足、設計レビューと侵入テストでの想定不足が挙げられました。玩具メーカーのアプリでは開発段階での認証機能の設計・実装上の不備、学習サービスでは機能の仕様の不備が原因とされています。この型は、更新をかけても直りません。「最新版かどうか」だけを見ていると、まるごと抜け落ちる層です。
公開資産を層ごとに数える
数えるときに効くのは、資産の種類ごとに「なぜ止まるのか」と「どこを見れば分かるのか」を対にしておくことです。理由が分かっていないと、同じものがまた止まります。
| 公開資産の種類 | 更新が止まりやすい理由 | 最初に見る場所 |
|---|---|---|
| CMS本体とプラグイン・テーマ | 過去に更新で表示や機能が壊れた。改変して使っている | 管理画面の更新一覧、テーマとプラグインの最終更新日 |
| 会員向け機能や申込フォーム | 作った会社との契約が切れている。設計起因の不備は更新で直らない | 公開URLの一覧、認証なしで到達できる画面 |
| 分析ツール・BIツール | 担当者が個別に立てた。使っていないのに動き続けている | 稼働中のサブドメイン、用途不明のサーバー |
| PHPやデータベースなどの基盤ソフト | 上げると古いプラグインやフレームワークが動かない | サーバー管理画面のバージョン表示、サポート終了の告知 |
| リモート接続や境界の機器 | 止めると業務が止まるため作業時間が取れない | 保守の委託先と、保守用アカウントの一覧 |
| 決済・外部連携のプラグイン | 本体の更新と別系統。動いているので触らない | 決済代行会社からの告知、プラグインの提供元 |
3行目は実務でいちばん見落とされます。検証のために立てたサブドメインや、入れたまま使っていないツールは、誰のものでもないため更新の担当が決まりません。棚卸しの第一歩は、サーバーに生きているドメインとサブドメインを全部書き出すことです。
EC-CUBE 4.0.2のバージョンアップは、テスト環境で戻せなくなった
ここからは更新が止まる理由を、実際に手を入れた側から書きます。止まっている理由は、たいてい怠慢ではありません。上げると壊れるからです。
EC-CUBE 4.0.2 で動いていた通販サイトで、PHPを7.3から7.4へ上げたいという相談を受けた案件があります。EC-CUBEには対応関係があり、PHP7.4に対応するには4.1.0以上、PHP8.1なら4.2系が必要で、4.1系と4.2系には互換性がありません。つまり「PHPを上げる」は「ECパッケージをメジャーバージョンアップする」と同義でした。このサイトは独自プラグインと直接のカスタマイズが多く、テスト環境でのバージョンアップが復元不能な状態に至りました。
そこで方針を変えて、古いPHPが動くサーバーへ移して延命する形にしました。このサイトには売却の期限が決まっていたため、恒久対応より延命が事業計画に合っていたという判断です。移行では別の問題も出ました。決済プラグインの 3GPSMDK.properties にある CA_CERT_FILE と、log4php.properties のログ出力先に、サーバー固有の絶対パスがハードコードされていたのです。移行直後、クレジットカード決済が全滅して代金引換だけが通る状態になりました。キャリア決済は決済代行会社が分かれており、ドコモとauは決済プラグイン側、ソフトバンクは別の決済事業者の管理画面という切り分けも必要でした。
この案件では、元の環境を消さずに別のサブドメインで並行稼働させています。切り戻せる状態を保ったまま検証を続けられるため、失敗の可能性が読めない移行では有効でした。ただし延命には期限があります。実際、移した元のサーバー会社はその後にPHP7.3から8.1への強制的な引き上げを実施しました。延命策は時間を買う手段で、解決ではありません。
「昨年は動いていたのに」はコードではなく環境が変わっている
CakePHPで作られた物件検索サイトから、昨年は動いていた画像処理が今年になって動かない、という相談を受けたこともあります。コードは変わっていないという前提が置ける以上、疑うのは環境です。調べると、共用レンタルサーバー側でPHPが8.0に引き上げられていて、その環境の画像処理ライブラリが古く、処理が通らなくなっていました。
共用サーバーでは、PHPの拡張ライブラリの更新はサーバー管理者にしかできません。利用者側で解決する手段がない、という結論になります。提示した案は3つで、事業者に打診する（見込みは薄い）、VPSへ移す（費用が大きい）、コントロールパネルからPHPを7.4に下げる（すぐ効くが暫定）。採ったのは3つ目でしたが、非推奨のバージョンは告知なく廃止される可能性があるため、暫定措置である旨を明記して終えています。あわせて、CakePHPを共用サーバーで動かす場合はPHPの実行モードを「モジュール」にする必要がある点も確認しました。
この2件が示しているのは、更新の判断が「やる・やらない」の二択ではないということです。バージョンを上げる、環境を移して延命する、下げて時間を作る。どれを選んでも期限は来ます。選択肢ごとの壊れ方はPHP8.2にしたら動かなくなったもの一覧と、上げる前に見る箇所とレンタルサーバーのPHPバージョンを変える手順と事前確認に分けて書いています。
上げる前に控える6行と、同居サイトの巻き込み
PHPとWordPressをまとめて最新化する作業は、手順を固定できる部分が多くあります。実際に回している順番は次の通りです。
- 現状のPHPバージョン、コア・テーマ・プラグインのバージョンを一覧で控える
- データベースとファイルのバックアップを取る
- プラグインとテーマを先に最新化し、そのあとにコアを更新する（逆順だと互換性のエラーが出やすい）
- サーバー管理画面でPHPのバージョンを上げる
- フロントと管理画面の主要ページを巡回し、PHP警告とFatal errorを確認する
WP_DEBUG_LOGで非推奨の警告を拾い、必要なら該当プラグインを差し替える
ここで見落としやすいのが、作業前の確認です。PHPのバージョンはサーバーまたはドメイン単位で適用されるため、同じサーバーに別のサイトが同居していると、そちらを巻き込んで壊します。対象が1サイトだという前提を置かず、同居しているサイトの有無を先に確認してください。更新でサイトが落ちたときの戻し方はプラグイン更新でサイトが落ちた時、FTPだけで戻した記録に実例があります。
当社でWordPressの不具合修正として対応したのは323件、サーバー移行は39件です。この中で「更新できないまま放置されていた」ものの理由は、テーマを直接編集している、プラグインを改変して使っている、フレームワークが特定バージョンに依存している、のだいたい3つに収まります。いずれも最初に作った時点で決まっていて、あとから直すほうが費用がかかる構造です。
数えて、判定して、扱いを決める
棚卸しは3段階で終わります。まず数える。生きているドメインとサブドメイン、外部に公開しているアプリと管理画面、サーバー上で動いているソフトを全部書き出します。次に更新できるかを判定する。更新を当てられるもの、当てると壊れるもの、提供元が更新を出していないもの、に分けます。残ったものの扱いを決めるのが3段目です。公開を止める、外部から到達できない場所へ移す、延命の期限を決めて移行の予算を立てる、のいずれかになります。
いちばんよくないのは、判定しないまま「後で見る」に置くことです。調査資料の中で、原因が公表されず「不正アクセス」とだけ記録された事案が73件あります。経路が分からないと復旧の範囲も決められないという話は「原因不明」が3件に1件。漏えい調査でログが足りないと起きることに書きました。数えていない資産は、事故のあとに探すことになります。更新と監視を継続的に回す体制が必要なら、保守の対応内容をご確認ください。
よくある質問
更新すると壊れる機能があります。どう判断すればよいですか
壊れる場所が分かっているなら、先に代替案の費用を出すところからになります。改変したプラグインに依存しているのであれば、同等の機能をテーマ側に自前で実装し直す、別のプラグインへ置き換える、その機能自体をやめる、という3つの比較です。費用は壊れている範囲によって変わるため一律には言えませんが、「更新できない理由」を資産ごとに文章で残しておくと、判断が人に依存しなくなります。担当者が代わったときに効いてきます。
使っていない古いサブドメインは、消すだけでよいですか
消すのが最も確実です。ただし、消す前に何が動いていたかを控えてください。別のサイトから読み込まれているファイルが置かれていることがあり、消した翌日に本番側の表示が崩れる場合があります。公開を止めるだけでよいか、ファイルごと削除するかは、他からの参照があるかどうかで決まります。
最新版にしていれば、脆弱性を突かれることはないのですか
更新だけでは埋まらない層があります。公表されている事案には、修正が出ていない段階で悪用されたものや、設計・仕様の不備が原因とされたものが含まれます。更新は必要な作業ですが、外部から到達できる画面を減らす、認証なしで使える機能を見直す、異常な量の照会に気づける仕組みを持つ、といった別軸の対策と組み合わせる前提になります。
