【詳細版】「サイト固有の脆弱性」とは？PHP脆弱性（php2shell）との違いと、サイト運営者がすべき対策【2026年10月】

はじめに

2026年10月、ソースネクストやスカイチケットなどで個人情報の漏えいが相次ぎ、ニュースでは「サイト固有の脆弱性（ぜいじゃくせい＝セキュリティ上の弱点）」という言葉がよく使われています。同じ時期に「PHPに重大な脆弱性」という話題も大きく報じられたため、両者は同じ問題なのか、レンタルサーバー会社がPHPを直せば安心なのか、と気になっている方も多いはずです。

👇 本記事でわかる3つの重要ポイント 👇

• 【テーマ1】サイト固有の脆弱性とPHPの脆弱性の違い
• 【テーマ2】AIを使った攻撃と相次ぐ情報漏えいの最新事情
• 【テーマ3】企業サイトと個人ブログの対策チェックリスト

この記事では、2つの脆弱性の違いを「建物の鍵」と「建物の設計」にたとえて整理し、実際の事案や政府・専門機関の注意喚起をもとに、サイトの規模ごとにやるべきことを順番にまとめました。WordPressでブログを運営している方も、自分のサイトに当てはめながら読み進めてください。

結論：サイト固有の脆弱性とPHPの脆弱性は別の問題です

結論から言うと、ニュースの「サイト固有の脆弱性」は、10月21日に騒ぎになったPHPの脆弱性（通称php2shell）とは別の問題です。サーバー会社がPHPを直しても解消しないため、サーバー側の対策とは別に、サイトを作った人・運営する人の側で点検と修正が必要です。

まず、要点を3つにまとめます。

• 別の問題です。PHPの脆弱性は「PHPというプログラムの部品そのものの欠陥」で、レンタルサーバー各社が10月22日ごろまでに修正を当て終えました。一方「サイト固有の脆弱性」は、各サイトが独自に作った仕組み（会員ページ、予約画面、API＝アプリとサーバーをつなぐ窓口など）の作り方や設定の不備です。ソースネクストやスカイチケットの事案はこちらに当たります。
• 運営側の対策は必要です。セキュリティ企業のマクニカは、サイトごとに構造や問題が異なるため外部から一律の対策を示すのは難しく、個々のシステムに合わせた点検や修正が必要だと説明しています。政府・JPCERT/CC・IPA・個人情報保護委員会も、10月に一斉に運営者向けの注意喚起を出しています。
• 個人ブログでまずやるべきことは5つです。①WordPress本体・プラグイン・テーマの更新、②管理画面のパスワード強化と2段階認証、③使っていないプラグインや古いサイトの削除、④PHPのバージョンを8.3以上にすること、⑤問い合わせフォームなどで個人情報をため込まないことです。

なお、7月に話題になった「wp2shell」もWordPress本体の欠陥でした。会員登録や予約のような「独自の仕組み」を持たない普通のブログは、今回のニュースの攻撃の主な標的ではありません。ただし、無差別に弱点を探されている点は同じなので、基本の対策は欠かせません。

先日のPHPの脆弱性「php2shell」とは何だったのか

10月21日に話題になったPHPの脆弱性は、PHPそのものに見つかった深刻な欠陥で、すでに修正版が出ています。レンタルサーバーを使っている場合、この修正はサーバー会社の仕事で、主要各社は対応を終えています。

何が起きたのか

PHPの開発元は2026年10月21日、認証なしで外部からプログラムを実行される（リモートコード実行＝RCE）おそれのある深刻な脆弱性2件を修正した版を公開しました。番号はCVE-2026-109618とCVE-2026-109619で、深刻度はCVSS v4.0（脆弱性の深刻さを表す国際的な点数）でいずれも9.2の「緊急（Critical）」です。

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。カナダのサイバーセキュリティセンターも、8.1以前はPHP開発元からの更新がもう提供されないと注意を促しています。

なぜ大騒ぎになったのか

大騒ぎになった理由は、公開予定日より前に情報が漏れたことと、影響を受けるサイトがとても多いことです。高市首相がXで「今夜に対応して頂きたい大至急のお願い」と投稿し、国家サイバー統括室とIPAも同日に準備を呼びかける異例の事態になりました。

調査会社W3Techsの統計では、サーバー側の言語が判別できたサイトのおよそ7割（2026年10月下旬時点で69%前後）がPHPを使っています。セキュリティ情報をまとめているブログ「piyolog」は、各社の告知で確認できたサービスの一時停止を211組織と数えています。

レンタルサーバー各社の対応

主なレンタルサーバー各社は、10月21日から22日にかけて緊急の対応を行いました。各社の告知などからわかる流れは次のとおりです。

• エックスサーバー：10月21日16時から公式サイト・管理画面を予防的に停止しました（お客様のサイト表示は継続）。PHP 8.2〜8.5は10月22日6時45分、7.4〜8.1は同日12時、5.6〜7.3は同日14時に修正を完了しています。古いPHP 5.1〜5.5は、10月23日13時15分の公式追記の時点では「過半数のサーバーでパッチ適用が完了」の段階でした。その後、きつねコードブログが10月27日に整理したエックスサーバーの告知によれば、10月26日6時20分までにPHP 5.1〜8.5のすべての対象サーバーで対応が完了しています（8.2〜8.5は同じ系列の修正版に更新、5.1〜8.1は修正パッチを適用）。
• ロリポップ：10月22日3時09分ごろから一部サーバーで顧客サイトの表示を停止し、全バージョンのPHPに修正を作成・適用したうえで、同日13時ごろに再開しました。公式の修正版がない古いPHPにも、自社で修正を作成しています。
• ConoHa WING：10月21日19時〜22日10時に緊急メンテナンスを実施しました。
• さくらのレンタルサーバ：21日に緊急メンテナンスを実施し、管理画面で選べる全バージョンへの対応を終えたと告知しています。

海外の評価

海外でも、この脆弱性は「実際に悪用されている危険なもの」と位置づけられています。米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）は10月26日、2件を「悪用が確認された脆弱性（KEV）カタログ」に追加し、連邦機関に10月29日までの対応を求めました。

米国のIT系ニュースサイトBleepingComputerなども、実際の悪用を報じています。英国のサイバーセキュリティ機関NCSCや、AWS（アマゾンのクラウドサービス）なども、すぐに更新するよう勧告しました。

発見にもAIが使われた

この2件の発見自体にも、AIが使われました。CVEの登録情報では、報告者としてセキュリティ企業のWizとCalif.io、さらにOpenAIが挙げられています。Wizは、最先端のAIモデルを脆弱性の発見や修正の検証に使ったと公表しています。

WordPressブログへの影響

レンタルサーバーでWordPressを動かしている場合、PHP本体の修正はサーバー会社の仕事で、すでに済んでいます。ただし、PHP 8.1以前には公式の修正版が出ず、8.2も2026年12月31日でサポートが終わります。管理画面でPHPを8.3以上に切り替えておくのが安全です。

「サイト固有の脆弱性」とは何か

「サイト固有の脆弱性」とは、多くのサイトに共通する部品ではなく、そのサイトが独自に作った仕組みや設定に潜む弱点のことです。共通の修正プログラムが配られないため、サイトごとに点検して直すしかありません。

不正アクセスの手口は3つに分けられる

マクニカのセキュリティ研究センター（瀬治山豊氏）は、ウェブシステムへの不正アクセスの手口を次の3つに整理しています。

1. 共通ソフトウェアの脆弱性：PHP、WordPress、EC-CUBE（ネットショップ構築ソフト）など、多くのサイトが同じ部品を使うため、同じ手口が通用します。CVE番号（脆弱性ごとの世界共通の番号）で管理され、修正パッチが出ます。
2. アカウントや認証の不備：管理画面の弱いパスワードや、盗まれたID・パスワードの悪用です。
3. 個別のサイトの構造、APIの機能、アクセス権の設定の欠陥：これがニュースでいう「サイト固有の脆弱性」です。

マクニカは手法3について、各サイト独自の作り方、アクセス権、設定、秘密情報の扱いなどの不備を突くもので、本来は見られない情報が見えたり、一般の利用者には許されない機能を呼び出せたりする問題だと説明しています。以前はサイトごとに調べる手間がかかるため主流ではありませんでしたが、今回はこうした個別のサイトやAPIの不備を探る動きが具体的に見えてきた、としています。

狙われている不備の具体例

マクニカ、JPCERT/CC、個人情報保護委員会の資料から、狙われている不備の例を挙げます。

• 必要以上の情報を返すAPI：画面には名前しか出ないのに、裏ではパスワードや住所まで送っている。
• 他人の情報が見えてしまう設計：URLや会員番号を書き換えると、別人のページが表示される。専門用語ではIDORやBOLAと呼ばれ、「認可（その人に見る権利があるかの確認）」が抜けている状態です。
• 会員向け機能にログインなしでアクセスできる。
• 大量アクセスの制限（レートリミット）がない、または会員IDが連番で推測しやすい。
• スマホアプリの中に秘密の鍵（APIキー）を埋め込んでいる：JPCERT/CCは、攻撃者がAndroidアプリを解析してAPIの接続先やキーを取り出していた痕跡を確認しています。
• 管理画面が外部から誰でも開ける状態や、使っていない古いAPIや検証用の環境が残っている。

比較表でわかる両者の違い

2つの脆弱性のいちばんの違いは、「欠陥がどこにあり、誰が直すのか」です。PHPの脆弱性は共通部品の欠陥なので開発元とサーバー会社が直し、サイト固有の脆弱性はそのサイトの作り手と運営者が直します。

項目	PHPの脆弱性（php2shell）	サイト固有の脆弱性
たとえると	建物に使われた「既製品の鍵」そのものの欠陥	建物ごとの「設計ミス」（裏口が開けっぱなし、他人の部屋の合鍵で入れるなど）
欠陥がある場所	PHPという共通部品（多くのサイトに共通）	そのサイトが独自に作ったプログラム・設定・API
見分け方	CVE番号（CVE-2026-109618など）が付き、世界共通で情報が出る	番号はなく、サイトごとに違う。公表もされにくい
直し方	開発元の修正版を当てる（パッチ適用）	そのサイトの作り手が点検し、プログラムや設定を直す
誰が直すか（レンタルサーバーの場合）	サーバー会社（今回はすでに完了）	サイト運営者・制作会社
共通ソフトの更新で解消するか	する	しない（マクニカ瀬治山氏も、共通ソフトの更新だけでは解消できないと指摘）
2026年の代表例	php2shell（10月）、WordPressの「wp2shell」（7月）	ソースネクスト、スカイチケットのバス予約ページ、各種の予約・会員サイト

よくある誤解：「PHPで作ったサイトの欠陥＝PHPの脆弱性」ではない

PHPで書かれたサイトに欠陥があっても、それがPHPの脆弱性とは限りません。PHPは道具（プログラミング言語）であり、その道具で作り手が書いたプログラムに「他人のデータを見せてしまう」ミスがあれば、それはサイト固有の脆弱性です。

この場合、PHPを最新にしても直りません。逆に、Java・Python・Node.jsなど別の言語で作られたサイトにも、同じ種類の欠陥は起こります。

実際の漏えい事案で分かっている原因

公表された事案を見ると、PHPのような共通ソフトの欠陥ではなく、自社システムの設計やデータの持ち方に問題があったケースが目立ちます。ただし、原因が公表されていない事案のほうが多いのが実情です。

ソースネクスト（10月15日公表）

ソースネクストでは、10月9日10時ごろから不正アクセスがあり、「会員情報取得API」を不正に利用されて、最大22,519,960件の情報が流出した可能性があります。対象はメールアドレス、パスワード、氏名、住所、電話番号、生年月日など13項目です（クレジットカード情報は含まれないとされています）。

ITmedia NEWSによると、同社は暗号化されたパスワードを元に戻すための鍵にアクセスできるシステム（API）が不正アクセスを受けたと説明し、パスワードが元に戻された状態で外部に流出したことを確認しています。piyologによれば、ハッシュ化（元に戻せない形での保存）に移行していなかった理由について、広報は当該システムの開発時期が古いためと説明しています。

APIを不正利用できた具体的な原因（認可の不備かどうかなど）は公表されていません。いずれにせよ、PHPのような共通ソフトの欠陥ではなく、自社システムの設計やデータの持ち方の問題です。

スカイチケット（アドベンチャー、10月9日公表）

旅行予約サイト「skyticket（スカイチケット）」を運営するアドベンチャーは、経路の異なる3件の不正アクセスを公表しました。

1. 10月2〜4日、一部の管理機能を不正に操作され、他のサーバーやクラウド上のデータに不正アクセスされた（約1,464万件、うち約413万件にハッシュ化されたパスワードを含む）。
2. 9月20日、業務管理システムの脆弱性を悪用された（17,780件、返金先の口座情報を含む）。
3. 8月3日〜10月1日、バスの予約完了ページがログインしなくても表示できる状態になっており、第三者に機械的に閲覧された（約1万2,000予約）。

このうち3つ目は、典型的な「サイト固有の脆弱性」です。予約番号さえわかれば誰でも開ける画面は、番号を順番に試すだけで次々に読まれてしまいます。

観光列車・図書館・大学の事案

被害は大企業のサービスだけではありません。あいの風とやま鉄道の観光列車「一万三千尺物語」では、座席管理システムに9月2日〜8日に複数回の不正アクセスがあり、1,409名分の氏名・住所などが漏えいしたおそれがあります（9月15日公表）。原因は調査中とされています。

国際文化会館図書室の蔵書検索システム（OPAC）にも9月23〜25日に不正アクセスがあり、一部利用者のパスワードなどが漏えいした可能性があります。大学の施設予約では、東海大学山中湖セミナーハウスの予約サイト（外部委託）で、274名分の宿泊予約情報が漏えいした可能性が8月5日に公表されています。

原因がわからない事案が大半

マクニカが7月以降の81事案を分析したところ、原因の内訳は次のとおりでした。

• 共通ソフトなどの脆弱性：9件（11.1%）
• 認証情報の悪用：4件（4.9%）
• サイトの設定・アクセス制御の不備：3件（3.7%）
• 公表文から原因が読み取れない：65件（80.2%）

被害の規模と広がり

ウェブシステムを経由した個人情報の漏えいは、2026年に入って急増しており、狙われるサイトの種類も広がっています。小さなサイトでも「関係ない」とは言えない状況です。

マクニカの集計では、ウェブシステム経由の個人情報漏えいの公表事案は、2024年が62件、2025年が84件、2026年は10月6日時点で119件でした。時事通信の報道では、10月26日までに216件（昨年の2.6倍）に達し、10月だけで101件とされています。

標的は、ECサイト（ネットショップ）から、会員向けサービス、業務システム、図書館の蔵書検索、観光列車の座席予約、大学のセミナーハウスの施設予約、公演チケットの払い戻し管理へと広がっています。マクニカは、公開されたウェブシステム、特に個人情報を扱うサイトに手当たり次第、無差別に攻撃が仕掛けられていると分析しています。

氏名や連絡先など、単体では悪用しにくい情報だけが漏れる事案も多くあります。マクニカは、詐欺やフィッシング（偽メールなどでだます手口）で相手を信用させるための材料集めの可能性を挙げています。

サイバーセキュリティクラウドによると、9月にウェブサイト1つあたりが受けた攻撃は2万8,253件で、前年同月の2.4倍でした。ECサイトを狙うSQLインジェクション（データベースを不正に操作する攻撃）に使われたIPアドレスの数も、前月より87%増えています。

AIを使った攻撃の国内外の動き

攻撃者がAIを使っている痕跡は国内外で見つかっていますが、個々の漏えい事案とAIの関係はまだ断定されていません。確かなのは、これまで手間がかかって後回しにされていた「サイトごとの弱点探し」が、速く広く行われるようになったことです。

国内で確認されていること

JPCERT/CCは10月15日、攻撃に使われたサーバーの調査で、攻撃者がAIを利用して既知の脆弱性のスキャン（自動での弱点探し）やAPI経由の攻撃を行っていたことを確認したと公表しました。10月23日には注意喚起に、AIを使ったペネトレーションテスト（模擬攻撃による安全性の検査）の基盤（Cairn、CyberStrikeAI、ARTEXなど）を悪用した攻撃の試みを「ケースE」として追加しています。

GMOサイバーセキュリティbyイエラエ（GMOサイバー犯罪対策センターの福森大喜氏による公式ブログ）は10月19日、攻撃元のインフラでAI自律型ペネトレーションテストシステム「ARTEX」の使用を確認したと公表しました。ほぼ日本だけを狙うそのインフラ1台は日本企業約20社を標的とし、そのうち9社は同じ業種のサイトでした。さらに、9〜10月に漏えいを公表した企業のうち8社が含まれていたとしています。日本企業を狙うAI利用の攻撃インフラは、別に6台見つかっています。

サイバーセキュリティクラウドは10月9日付のレポートで、マクニカが公開した2件のIPアドレスを起点に、9月18日〜10月8日の観測データを分析しました。IPアドレスが違ってもリクエストの中で同じ識別子が使い回されていたことから、同一とみられる攻撃者が約40分間で326のIPアドレスを使い分け、1,200件を超えるアクセスを行っていたとしています。応答を見ながら手を変えていたことから「AIエージェントまたはそれに近い仕組み」の可能性を指摘していますが、直接の痕跡ではなく推測だと明記しています。

一方でマクニカは、一連の事案でAIが使われたと断定できるログや痕跡は確認されていないとしつつ、AIの活用を否定するほうが難しいとも述べています。AIによるゼロデイ（まだ知られていない脆弱性）の発見は、現時点では確認されていないとしています。実際に起きているのは、アクセス権や設定、認証といった、より基礎的な不備の高速かつ広範囲な探索です。

政府の動き

政府や専門機関も、10月に入って相次いで動いています。

• 10月7日：個人情報保護委員会が注意喚起
• 10月8日：JPCERT/CCと警察庁が注意喚起
• 10月9日：国家サイバー統括室・総務省・経済産業省・IPA・金融庁が注意喚起
• 10月16日：IPAが「不正アクセス特別相談窓口」を開設
• 10月23日：経済産業大臣がIPAへのホワイトハッカー（防御側の技術者）チーム設置を表明
• 10月26日：初の関係閣僚会議を開催

報道によると、10月26日の会議で高市首相は「アクセス無害化措置も含め、あらゆる対処オプションを戦略的に選択し、実行する」と述べ、来週中をめどに緊急対策パッケージをまとめるよう指示しました。Impress Watchによれば、IPAの人材と高性能AIを使った「模擬的な攻撃テスト」の前倒しも指示されています。

海外の動き

海外でも、AIを使った攻撃の増加が報告されています。

• Google脅威インテリジェンスグループ（GTIG）は、実際に悪用された脆弱性が2025年の月平均10.5件から、2026年は月18件に増えたとしています。AIの研究エージェントが見つけた脆弱性が、公表から4日以内に悪用された事例も報告しています。
• Check Pointの「AI Security Report 2026」は、AIが攻撃手順を自律的に実行し、数十のセッションで数千のコマンドを生成した侵入事例を記録しています。
• CrowdStrikeは10月28日、AIエージェントで偵察・侵入・データ窃取を行う、これまで報告されていなかった攻撃者4グループを特定したと発表しました。
• Cloud Security Allianceは、オランダのDIVDが9月21日に自律型AIエージェントによる侵入を受けた事案を、7月のHugging Faceの事案に続く公表事例として分析しています。
• マクニカの調査では、2026年7〜9月を中心に13の国・地域で類似の事例99件を確認しました（韓国30件、フランス11件、ポーランド8件）。日本だけが狙われているのかどうかは分かっていません。

ウェブアプリの危険度ランキングの国際標準である「OWASP Top 10:2025」でも、1位は引き続き「アクセス制御の不備（Broken Access Control）」です。今回の手口と、ぴたりと重なります。

何が変わったのか

これまで「手間がかかるので後回しにされていた」サイトごとの弱点探しが、AIによって安く、速く、大量にできるようになりました。セキュリティの専門家である徳丸浩氏が「攻撃と防御のパワーバランスが崩れた」と表現しているのは、このことです。「うちは小さいサイトだから狙われない」という前提は、もう通用しません。

サイト運営者の責任範囲と専門機関が求める対策

レンタルサーバーを使っていても、サーバー会社がすべてを守ってくれるわけではありません。どこまでが自分の責任かを知り、政府や専門機関が共通して求めている対策を押さえることが出発点です。

責任の分かれ目（共有責任モデル）

レンタルサーバーを借りている場合、責任はおおむね次のように分かれます。

• サーバー会社の責任：サーバー機器、OS、PHP本体、ウェブサーバー（Apacheなど）、サーバー側のWAF（不正な通信を止める防火壁のような仕組み）の提供
• 利用者（運営者）の責任：WordPress本体・プラグイン・テーマの更新、管理画面のパスワード、どのPHPバージョンを選ぶか、自分で作ったプログラムや設定、保存している個人情報の管理、不要なサイトの削除

VPSやクラウド（AWSなど）で自分でPHPを入れている場合は、PHPの更新も利用者の責任になります。

政府・専門機関が共通して求めていること

piyologが各機関の注意喚起を横断して整理したところ、共通する項目は次のとおりでした。

1. 直近1か月のログを点検する：IPAは、まず直近1か月、その後3か月と、段階的に範囲を広げるよう勧めています。
2. 脆弱性に対応し、不要な公開を止める：使っていないシステム・機能・管理画面の公開を停止します。
3. APIのアクセス制御を見直す：個人情報保護委員会は、認証（本人確認）に加えて、認可（そのユーザーがそのデータにアクセスする権限を持つかの確認）を毎回行う仕組みを求めています。あわせて、レートリミット、会員IDのランダム化（UUIDなど）、不要な情報を応答に含めない設計も求めています。
4. 認証と権限を見直す：多要素認証の導入と、管理者権限の最小化です。
5. 保有データを減らす：国家サイバー統括室は、持っている情報が少なければ被害の拡大を抑えられるとしています。
6. 検知と初動の体制を整える：委託先も含めて管理します。

漏えいが起きたときの法的義務

個人情報保護法では、不正アクセスによる漏えい（またはそのおそれ）は、1人分でも個人情報保護委員会への報告と本人への通知の対象になります。1,000人を超える漏えいも同様です。

報告は「速報」（おおむね3〜5日以内）と「確報」（原則30日以内、不正アクセスなどの場合は60日以内）の2段階です。個人ブログでも、問い合わせフォームやメルマガ登録で他人の個人情報を扱っていれば、「個人情報取扱事業者」に当たる場合があります。ここで紹介したのは一般的な情報であり、個人の状況によって扱いが異なるため、具体的な判断は個人情報保護委員会などの公的機関や専門家にご相談ください。

企業サイト・会員サイト向けの対策チェックリスト

会員登録や予約などの独自機能を持つサイトでは、「何を公開しているか」を把握することから始め、認可の点検と監視体制まで順番に進めます。優先順に並べると次のとおりです。

1. 棚卸し：公開しているウェブシステム、スマホアプリ、API、管理画面、検証環境、委託先が運営するサイトと、それぞれが持つ個人情報の種類と件数を一覧にします（マクニカ・IPAが最初の手順として推奨）。
2. 被害確認：直近1か月のアクセスログを点検します。同じIPアドレスからのAPIへの大量アクセス、403・404・503エラーの急増、管理機能への不審なアクセス、データベースの高負荷を確認し、JPCERT/CCの注意喚起（JPCERT-AT-2026-0030）に載っているIPアドレスとも照合します。
3. 認可の点検：URLや会員IDを書き換えて他人の情報が見えないか、ログインなしで会員ページやAPIが使えないか、APIが必要以上の項目を返していないかを確認します（OWASP API Security Top 10の1位「BOLA」に相当）。
4. アプリに秘密を埋め込まない：APIキーや認証情報が、アプリやブラウザ側のコードに入っていないか確認します。
5. レートリミットとWAF：短時間の大量取得を制限し、検知できるようにします。
6. 管理画面の保護：外部への公開をやめるかIPアドレスで制限し、多要素認証を導入し、弱いパスワードを廃止します。
7. 脆弱性診断・ペネトレーションテスト：専門家による模擬攻撃を、管理画面や重要な機能も対象に含めて実施します。マクニカは、管理画面が診断の対象から外されがちだと指摘しています。
8. パスワードの保存方式：元に戻せる形の暗号化ではなく、ハッシュ化（bcryptなど）で保存します。
9. データの最小化：不要な個人情報や、備考欄に入った想定外の情報を削除します。サービスを終えるときは、サーバーを止めるだけでなくAPIキーも破棄します。
10. 共通ソフトの更新：PHP（8.3以上）、CMS、フレームワーク、Metabase（データ分析ツール）などのツールを最新にします。
11. 監視と初動：誰がアラートを見て、誰に連絡し、どう止めるかまで決めて訓練します。個人情報保護委員会への速報（3〜5日）の手順も確認しておきます。
12. 設計段階からの対策：IPA「安全なウェブサイトの作り方」の「1.11 アクセス制御や認可制御の欠落」と、OWASP Top 10:2025をもとに安全なプログラムの書き方を徹底し、委託先にも要件として示します。
13. 困ったときの相談先：IPAの「不正アクセス特別相談窓口」に相談します。

個人ブログ・小規模サイト（WordPress）向けの対策チェックリスト

レンタルサーバーでWordPressブログを運営し、会員登録や予約などの独自機能がない場合は、次の順で取り組めば十分な水準になります。どれも管理画面から自分でできる作業です。

1. WordPress本体・プラグイン・テーマを最新にする：7月の「wp2shell」（CVE-2026-63030／CVE-2026-60137）はWordPress本体の欠陥で、プラグインなしの標準的なサイトでも、ログインなしで乗っ取られるおそれがありました。修正版は7.0.2、6.9.5、6.8.6です。管理画面の「ダッシュボード」→「更新」で確認し、自動更新を有効にしておきます。
2. PHPのバージョンを確認する：レンタルサーバーの管理画面で8.3以上を選びます（8.1以前は公式の修正なし、8.2は年末でサポート終了）。切り替える前にバックアップを取ります。
3. 管理者ログインを守る：長く使い回していないパスワードにし、2段階認証のプラグインを導入します。ユーザー一覧に身に覚えのない管理者アカウントがないかも確認します（wp2shellによる侵害の痕跡として報告されています）。
4. 使わないものを消す：無効化しているだけのプラグインやテーマ、昔作って放置しているHTMLサイトや旧ブログ、テスト用のサイトを削除します。古いものほど狙われます。
5. 個人情報をため込まない：問い合わせフォームのプラグインが、送信内容をサーバー内に保存していないか確認し、不要なら保存しない設定にします。保存した情報は定期的に削除します。
6. サーバー会社の機能を使う：WAFの設定、自動バックアップ、海外からの管理画面アクセス制限（エックスサーバーなどで提供）をオンにします。
7. バックアップを確認する：万一改ざんされても元に戻せるよう、定期的なバックアップが取れているか確かめます。
8. 異変に気づく：見覚えのない記事やリンク、知らないファイル、サイトが急に重いなどの変化があれば、サーバー会社に相談し、パスワードを変更します。

手作りのHTMLサイトは大丈夫？

HTMLだけで作った静的なページ（プログラムが動かず、入力フォームもないもの）は、今回のような「サイト固有の脆弱性」が生じにくい構造です。

ただし、同じサーバー内に古いCGIやPHPのフォーム、昔のブログなどが残っていると、そこが入口になります。使っていないものは削除しておきましょう。

ニュースを読むときに知っておきたい注意点

今回の一連の事案は、まだ調査中のことが多く、報道や分析の中には推定を含むものもあります。情報を受け取るときは、次の点に気をつけてください。

• 「AIが使われた」の確度：JPCERT/CCとイエラエは攻撃インフラでのAI利用を確認していますが、マクニカや国家サイバー統括室は、個々の漏えい事案とAIの関係を断定できないとしています。「AIで弱点探索」は有力な見方ですが、すべての事案に当てはまるとは限りません。
• 原因が公表されない事案が多い：マクニカの分析では8割の事案で原因が読み取れず、ソースネクストも脆弱性の具体的な中身は公表していません（10月下旬時点、第三者による調査中）。この記事の「サイト固有」という分類にも、公表文からの推定が含まれます。
• 10月26日の閣僚会議の詳細：時事通信は手口の分析が報告されたと報じていますが、官邸の議事資料は確認できていません。緊急対策パッケージも、2026年10月28日時点ではまだ公表されていません。
• PHPの別の脆弱性：PHPプロジェクトは、別のリモートコード実行の脆弱性CVE-2026-115560について、修正版が出るまで設定の変更（session.upload_progress.enabled=0）で回避するよう案内しています。レンタルサーバーの利用者は、各社の告知を確認してください。
• 数値の細部：停止した組織の数や各社の完了時刻など一部の数値は、報道や解説ブログを経由した情報で、公式発表と細部が異なる可能性があります。

よくある質問

レンタルサーバー会社がPHPを修正したので、もう安全ですか？

PHPの脆弱性（php2shell）については、主要なレンタルサーバー各社が修正を終えています。ただし、サイト固有の脆弱性はPHPの修正では直りません。WordPressの更新や管理画面の保護など、運営者側の対策は別に必要です。

会員機能のない普通のブログでも狙われますか？

今回のニュースの攻撃の主な標的は、会員登録や予約など個人情報を扱う独自の仕組みを持つサイトです。ただし、公開されているサイトは無差別に弱点を探されています。古いプラグインや放置したサイトが入口になることもあるため、基本の対策は欠かせません。

PHPのバージョンはどれを選べばよいですか？

8.3以上が安全です。8.1以前には公式の修正版が出ず、8.2も2026年12月31日でサポートが終わります。切り替えでサイトの表示が崩れることもあるので、事前にバックアップを取ってから変更してください。

問い合わせフォームしかない個人ブログでも、漏えいしたら報告が必要ですか？

問い合わせフォームなどで他人の個人情報を扱っていれば、個人情報取扱事業者に当たる場合があり、不正アクセスによる漏えいは1人分でも報告と本人への通知の対象になり得ます。扱いは状況によって異なるため、心配な場合は個人情報保護委員会などに相談してください。

「サイト固有の脆弱性」は自分で見つけられますか？

URLの番号を書き換えて他人の情報が見えないか、ログインなしで会員ページが開けないかといった基本的な確認は、運営者自身でもできます。独自のシステムやアプリを持つ場合は、専門家による脆弱性診断を受けるのが確実です。

まとめ

ニュースでいう「サイト固有の脆弱性」は、10月に騒ぎになったPHPの脆弱性（php2shell）とは別の問題です。PHPの欠陥は「既製品の鍵」の不具合で、サーバー会社がすでに直しました。一方、サイト固有の脆弱性は「建物ごとの設計ミス」で、サイトを作った人や運営する人が点検して直すしかありません。

AIによって、サイトごとの弱点探しが安く速く大量にできるようになり、小さなサイトでも油断はできなくなりました。企業サイトなら棚卸しと認可の点検から、個人ブログならWordPressとプラグインの更新、PHPを8.3以上にすること、使わないものの削除から始めるのが近道です。

まずは今日、WordPressの管理画面で「ダッシュボード」→「更新」を開き、本体とプラグインが最新になっているか、そしてユーザー一覧に見覚えのない管理者がいないかを確認してみてください。

参考リスト

• CISA Adds Two Known Exploited Vulnerabilities to Catalog（CISA）
• Alert – AL26-026 – Critical vulnerabilities impacting PHP – CVE-2026-109618 and CVE-2026-109619（カナダ サイバーセキュリティセンター）
• Critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619: what you need to know（Red Sift）
• CISA confirms PHP2Shell under attack as researchers clock successful exploits（The Register）
• 【高市総理も注意喚起】インターネット崩壊危機？PHP重大脆弱性でWebサイト緊急停止（ビジネス+IT）
• 予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ（エックスサーバー）
• PHP2Shell 国内レンタルサーバー各社の対応状況（jinrai.co.jp）
• Usage statistics of server-side programming languages for websites（W3Techs）
• 重点確認のIPアドレスを提示 ～ マクニカ、相次ぐWebシステムからの情報漏えいの被害傾向と攻撃手法を公表（ScanNetSecurity）
• ソースネクストに不正アクセス、22,519,960件の会員情報が流出した可能性（ScanNetSecurity）
• スカイチケット、不正アクセスで最大約1,464万件の情報流出か（TRAICY）
• skyticketへの不正アクセス 経路の異なる3件の解説（issoh.co.jp）
• JPCERT/CC、国内組織への不正アクセスに関する注意喚起を公開 API悪用などへの対策を推奨（ScanNetSecurity）
• 連続不正アクセスの実態判明 Androidアプリを解析してAPIに侵入か（＠IT）
• wp2shell Aftermath: The First Critical Unauthenticated WordPress Core RCE in Nearly a Decade（Wordfence）
• wp2shell (CVE-2026-63030, CVE-2026-60137): Frequently asked questions（Tenable）