第１ 本記事の対象と結論
１ 対象と基準日
令和８年１０月２１日，PHPの開発チームは，認証を受けていない第三者による遠隔コード実行につながり得る二つの重大な脆弱性（CVE-2026-109618及びCVE-2026-109619。発見者等は「PHP2Shell」と呼んでいる）を修正した版を公開した。
本記事は，修正版を適用する前の期間に，脆弱な版のPHPで個人データを扱うウェブサイトを運営していた事業者が，個人情報の保護に関する法律（以下「個人情報保護法」という。）２６条による個人情報保護委員会への報告と本人への通知をしなければならないかを整理するものである。
基準日は令和８年１０月２３日である。
条文はe-Gov法令検索で現行の版（個人情報保護法は令和８年１０月１日施行の版，同法施行規則は令和８年６月１４日施行の版）を確認し，個人情報保護委員会のガイドライン（通則編）は令和８年６月一部改正の版，Ｑ＆Ａは令和７年７月１日更新の版によった。
PHPの修正版と更新手順は，PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認，バックアップ，互換性試験及び復旧手順で扱っている。
２ 結論
①漏えい等報告の対象は，個人データの漏えい等が「発生し、又は発生したおそれがある事態」であり，脆弱なソフトウェアを使っていたことそのものではない。
②個人情報保護委員会がサイバー攻撃について「おそれ」に当たり得る例として挙げるのは，窃取の痕跡，情報を窃取するマルウェアの感染，指令サーバーへの通信，入力ページの改ざんの痕跡，第三者からの根拠のある連絡といった具体的な兆候である。
③したがって，本記事では，侵入の痕跡を調べても見つからず，第三者からの連絡もないときは，脆弱な版を使っていたことだけを理由に直ちに報告対象になるとまではいえないと考える。
ただし，今回の脆弱性は攻撃の痕跡が残らない場合があるとされているので，調べた範囲と判断の理由を記録しておく必要がある。
④侵入の痕跡がある場合は，不正の目的による行為による漏えい等のおそれ（施行規則７条３号）に当たり得るので，知った時点から概ね３～５日以内の速報，６０日以内の確報及び本人への通知が必要になる。
⑤レンタルサーバーやクラウドの事業者が個人データを取り扱わない契約になっている場合でも，報告義務を負うのはサービスを利用してサイトを運営する事業者である。
⑥報告の要否とは別に，修正ソフトウェアを適用しなかったことは，安全管理措置（個人情報保護法２３条）の問題になり得る。
第２ 今回の脆弱性で報告の判断に関係する点
PHPの開発チームの発表によれば，二つの脆弱性はPHP本体にあり，ウェブのリクエストを処理する全てのPHPの環境が危険の対象とされている。
CVE-2026-109619のアドバイザリは，確認された影響として，遠隔コード実行のほかに，メモリーの内容の開示を挙げている。
発見者の一つであるWizは，開示されたメモリーにパスワード，認証用のトークン，APIキー及び証明書が含まれ得ると説明している。
また，Cloudflareは，脆弱性の情報が正式な公開日より前に流出し，攻撃の通信を観測したとしている。
JPCERT/CCは，令和８年１０月２２日の注意喚起で，攻撃を受けた可能性を調べるために，過去のHTTPの応答で不自然に長い又は異常な形式のセッションのCookieが設定されていないか，不審なmultipart/form-data形式のリクエストの前後にPHPのメモリー上限に関するエラーやHTTP 500のエラーがないか，PHPのワーカーの予期しない異常終了や頻繁な再起動の痕跡がないかを確認するよう挙げている。
そのうえで，「上述の痕跡が確認されない場合でも、本脆弱性を悪用した攻撃を受けていないと断定することはできません。」としている。
このように，今回の脆弱性では，痕跡が見つからないことと攻撃を受けていないことが同じではない点に注意を要する。
第３ 報告・通知の対象となる事態
１ 個人情報保護法２６条と施行規則７条
個人情報保護法２６条１項は，個人データの漏えい，滅失，毀損その他の個人データの安全の確保に係る事態であって，個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定めるものが生じたときに，個人情報保護委員会への報告を義務付けている。
同条２項は，その場合に，本人への通知も義務付けている。
個人情報保護法施行規則７条は，対象となる事態を次の４つとしている。
①要配慮個人情報が含まれる個人データの漏えい等が発生し，又は発生したおそれがある事態（１号）
②不正に利用されることにより財産的被害が生じるおそれがある個人データの漏えい等が発生し，又は発生したおそれがある事態（２号）
③不正の目的をもって行われたおそれがある個人情報取扱事業者に対する行為による個人データ（取得しようとしている個人情報で個人データとして取り扱われる予定のものを含む。）の漏えい等が発生し，又は発生したおそれがある事態（３号）
④個人データに係る本人の数が千人を超える漏えい等が発生し，又は発生したおそれがある事態（４号）
外部からの攻撃による漏えい等は，主に３号の問題になる。
３号は人数を問わないので，問合せフォームに入力された数件の個人情報でも対象になり得る。
２ 「おそれ」の意味
ガイドライン（通則編）３－５－３－１は，「おそれ」について，「その時点で判明している事実関係に基づいて個別の事案ごとに蓋然性を考慮して判断することになる。」とし，さらに，「漏えい等が発生したおそれについては、その時点で判明している事実関係からして、漏えい等が疑われるものの漏えい等が生じた確証がない場合がこれに該当する。」としている。
つまり，漏えいが確実になるまで報告を待ってよいわけではない一方，漏えい等が疑われる事実関係があることが前提になる。
３ サイバー攻撃について示された例
同じ節は，サイバー攻撃の事案で「漏えい」が発生したおそれがある事態に当たり得る例として，次の５つを挙げている。
①個人データを格納しているサーバや，そのサーバにアクセス権限を持つ端末で，外部からの不正アクセスによりデータが窃取された痕跡が認められた場合
②同じサーバや端末で，情報を窃取する振る舞いが判明しているマルウェアの感染が確認された場合
③マルウェアに感染したコンピュータを制御するサーバ（C&Cサーバ）が使っているものとして知られているIPアドレス・FQDNへの通信が確認された場合
④個人情報を取得するウェブページのファイルを保存しているサーバ等で，入力された情報を窃取するような改ざんの痕跡が確認された場合
⑤不正検知を行う公的機関，セキュリティ・サービス・プロバイダ，専門家等の第三者から，漏えいのおそれについて一定の根拠に基づく連絡を受けた場合
４ マルウェアを検知しただけでは直ちに「おそれ」とはしない
個人情報保護委員会のＱ＆Ａ（Ｑ６－17）は，上の②について，「単にマルウェアを検知したことをもって直ちに漏えいのおそれがあると判断するものではなく、防御システムによるマルウェアの実行抑制の状況、外部通信の遮断状況等についても考慮することになります。」と回答している。
Ｑ＆Ａには，ソフトウェアの脆弱性があったこと自体を正面から扱った問は見当たらない。
第４ PHP2Shellの場面への当てはめ
１ 調べても痕跡が見つからない場合
ガイドラインの例は，いずれも窃取の痕跡や感染の確認といった具体的な兆候を前提にしている。
また，Ｑ６－17は，マルウェアを検知した場合でさえ，実行の抑制や外部通信の遮断の状況を考慮するとしている。
そうすると，本記事では，JPCERT/CCが挙げる痕跡を調べても見つからず，第三者からの連絡もなく，ほかに漏えい等を疑わせる事実もないときは，修正前の版を使っていたことだけで直ちに施行規則７条３号の「おそれ」に当たるとまではいえないと考える。
もっとも，今回の脆弱性は痕跡が残らない場合があるとされている。
どのログを，いつからいつまで，どの方法で調べたか，調べられなかった範囲は何か，その時点で判明していた事実から報告不要と判断した理由は何かを記録しておくべきである。
報告対象事態に当たらない場合でも，個人情報保護委員会への任意の報告はできる（ガイドライン３－５－３－１（※１），Ｑ６－18）。
後に痕跡や外部からの連絡が見つかれば，その時点で改めて判断し，その時点を「知った」時点として期限を数えることになる。
２ 侵入の痕跡が見つかった場合
不審なプロセスの実行，不審なファイルの作成，外部への不審な通信，個人データの入ったデータベースへの異常なアクセス等，侵入をうかがわせる痕跡が見つかった場合は，前記①から④までの例に近い事態になる。
個人データを扱うサーバや，問合せフォーム等の入力ページを置いたサーバで痕跡が見つかれば，施行規則７条３号の「おそれ」に当たり得る。
要配慮個人情報が含まれていれば１号，本人の数が千人を超え得るなら４号にも当たり得る。
３ ログが残っておらず判定できない場合
ログを保存していなかった，保存期間が過ぎていた等で，攻撃を受けたかどうかを判定できない場合もある。
Ｑ＆Ａ（Ｑ６－２）は，設定ミスで個人データが閲覧できる状態になっていた場面について，第三者が閲覧していないことを確認できれば漏えいに当たらないとしつつ，アクセスログ等が確認できない場合には，漏えい（又は漏えいのおそれ）に当たり得るとしている。
脆弱性の場面と事実関係は異なるが，確認の手段がないことが，漏えいがなかったことの根拠にならない点は共通する。
判定できないときは，攻撃の通信が観測されていた期間，サイトの構成，扱っていた個人データの内容等を踏まえて，専門家の意見も得て個別に判断することになる。
４ メモリーの開示とパスワード
今回の脆弱性はメモリーの内容の開示を伴うとされており，ログインのIDとパスワードやセッションの情報が漏れることもあり得る。
施行規則７条２号の財産的被害のおそれについて，ガイドラインは，送金や決済の機能のあるウェブサービスのログインIDとパスワードの組合せを含む個人データが漏えいした場合を報告を要する例に挙げている。
また，Ｑ６－15は，漏えい等を知った時点で財産的被害が生じるおそれがあれば，その後の被害防止の措置でおそれがなくなっても報告対象になるとしている。
会員の決済機能等を持つサイトで痕跡が見つかった場合は，２号にも当たらないかを検討する必要がある。
５ 第三者から連絡を受けた場合
セキュリティ事業者や公的機関から，自社のサイトが攻撃を受けている等の根拠のある連絡を受けた場合は，前記⑤の例に当たり得る。
連絡を受けた部署が担当部署に回さないうちにも，期限の起算点が進むことがある（次の第５の１）。
第５ 報告・通知の期限と内容
１ 速報
ガイドライン３－５－３－３は，速報の時期について，「「速やか」の日数の目安については、個別の事案によるものの、個人情報取扱事業者が当該事態を知った時点から概ね3～5日以内である。」としている。
「知った」時点は，法人の場合，いずれかの部署が知った時点が基準とされ，Ｑ＆Ａ（Ｑ６－24）は，部署内のある従業者が知った時点で「部署が知った」と考えられるとしている。
速報では，その時点で把握している事項を報告すれば足りる。
２ 確報
施行規則８条２項は，確報の期限を，事態を知った日から３０日以内とし，３号の事態（不正の目的による行為による漏えい等）については６０日以内としている。
ガイドライン３－５－３－４によれば，期限の算定には土日・祝日も含め，末日が土日，祝日又は年末年始の閉庁日のときはその翌日が期限となる。
確報の時点で一部の事項が判明していなければ，その時点で把握している内容を報告し，判明次第追完する。
個人情報保護委員会は，漏えい等報告と本人通知の制度を解説する動画を令和６年に公開している（動画の表示によれば令和４年３月時点の内容）。
３ 本人への通知
施行規則１０条は，報告対象事態を知った後，「当該事態の状況に応じて速やかに」，本人の権利利益を保護するために必要な範囲で，概要，個人データの項目，原因，二次被害又はそのおそれの有無と内容，その他参考となる事項を本人に通知するよう定めている。
ガイドライン３－５－４－２は，漏えい等のおそれが生じたものの事案がほとんど判明しておらず，通知しても本人が身を守る措置を講じる見込みがなく，かえって混乱が生じるおそれがある場合等には，その時点で通知する必要があるとはいえないとしつつ，状況に応じて速やかに通知すべきことに変わりはないとしている。
連絡先が分からない等で通知が困難な場合は，事案の公表や問合せ窓口の設置等の代替措置によることができる（ガイドライン３－５－４－５）。
パスワードが漏れたおそれがある場合は，本人がパスワードを変更できるよう，その旨を通知に含めることが考えられる。
第６ レンタルサーバー・クラウド・保守会社が関わる場合
１ サービス事業者側への攻撃も対象になり得る
ガイドライン３－５－３－１は，施行規則７条３号の不正行為の相手方である「当該個人情報取扱事業者」に，個人データの取扱いの委託先と，個人データを扱うために利用している第三者のサービスの提供者も含まれるとしている。
Ｑ＆Ａ（Ｑ６－16）は，その例として，入力フォーム作成ツールやストレージサービスの提供事業者等を挙げている。
サイトを置いているサービスの側でPHPが悪用された場合も，サイトを運営する事業者の報告対象事態になり得る。
２ サービス事業者が個人データを取り扱わない場合
Ｑ＆Ａ（Ｑ７－53）は，契約条項でクラウドサービスの提供事業者がサーバに保存された個人データを取り扱わない旨が定められ，適切にアクセス制御が行われている場合等には，その利用は個人データの提供に当たらないとしている。
そのうえで，Ｑ６－22は，このような場合に報告対象となる漏えい等が発生したときは，サービスを利用する事業者が報告義務を負い，報告を提供事業者に代行させることはできるとしている。
提供事業者は報告義務を負わないが，契約等に基づいて利用する事業者に通知する等の対応が求められる。
レンタルサーバーで運営するサイトでは，サーバー会社が対応してくれるはずと待つのではなく，自社で状況を問い合わせ，報告の要否を判断する必要がある。
３ 保守会社とパッチの適用
Ｑ＆Ａ（Ｑ７－55）は，単純なハードウェア・ソフトウェアの保守サービスだけを行い，契約で個人データを取り扱わない旨が定められ，適切にアクセス制御が行われている場合等には，個人データの提供に当たらないとし，その例として，システム修正パッチを配布し，適用する場合を挙げている。
他方，保守会社が個人データを取り扱う委託先に当たる場合は，委託先も報告義務を負うが，委託元に必要な事項を通知すれば報告義務と本人への通知義務を免れる（ガイドライン３－５－３－５，３－５－４－１）。
この通知の目安も，委託先が事態を知った時点から概ね３～５日以内とされている。
第７ 報告とは別に問われる安全管理措置
ガイドライン（通則編）の技術的安全管理措置（１０－６）は，外部からの不正アクセス等の防止の手法の例として，ソフトウェア等を最新の状態にすることを挙げ，Ｑ＆Ａ（Ｑ１０－20）も，ミドルウェア等へのセキュリティ対策用修正ソフトウェアの適用を挙げている。
個人情報保護委員会の「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」（令和８年１０月７日改訂）は，報告された事案の類型として，脆弱性が放置された事例と，脆弱性への対応が遅れた事例を挙げ，こうした問題への措置が十分でない場合，安全管理措置等の違反と判断される可能性があるとしている。
同じ資料は，システム業者との間で導入の契約しか結んでおらず，セキュリティ対策の保守契約を結んでいなかった例も挙げている。
修正版の公開を知りながら適用を遅らせた期間に被害が生じれば，報告の要否とは別に，安全管理措置の不備として問われ得る。
第８ 事業者が確認すること
①使っているPHPの完全な版番号と，修正版（8.5.12，8.4.27，8.3.36又は8.2.35以上）又はサーバー会社が修正を取り込んだ版を適用した日時
②JPCERT/CCが挙げる痕跡（セッションのCookieの異常，multipart形式のリクエストとメモリー上限のエラー，ワーカーの異常終了等）を調べた範囲と結果
③ログの保存の有無と保存期間，調べられなかった範囲
④サイトで扱う個人データの種類（問合せフォームの入力内容，会員のID・パスワード，要配慮個人情報の有無）と本人の数
⑤サーバー会社・保守会社との契約で，個人データを取り扱うか，事故の通知の取決めがあるか
⑥報告不要と判断した場合の理由と判断日，後に痕跡等が見つかったときに改めて判断する担当者
⑦報告対象と判断した場合の速報（概ね３～５日以内）・確報（６０日以内）の期限と本人への通知の準備
第９ 関連記事
①PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認，バックアップ，互換性試験及び復旧手順
②クラウド事業者がランサムウェア被害を受けたとき，利用者に漏えい等報告義務はあるか―施行規則７条３号，滅失・毀損とバックアップ
③情報漏洩が相次ぐ今，企業の信頼を守る法務の備え―平時の体制，発覚後の初動，報告・通知・公表
④個人情報保護委員会が示した不正アクセス９類型―API，クラウド，グループ会社，個人領域及びログ管理
⑤情報漏えいのフォレンジック報告書をどう読むか―調査範囲，ログ欠落及び「痕跡なし」の限界
第１０ 出典
１ 法令
①個人情報の保護に関する法律２３条・２６条（e-Gov法令検索。令和８年１０月１日施行の版。令和８年１０月２２日確認）https://laws.e-gov.go.jp/law/415AC0000000057
②個人情報の保護に関する法律施行規則７条～１０条（e-Gov法令検索。令和８年６月１４日施行の版。令和８年１０月２２日確認）https://laws.e-gov.go.jp/law/428M60020000003
２ 個人情報保護委員会の資料
①「個人情報の保護に関する法律についてのガイドライン（通則編）」（平成２８年１１月，令和８年６月一部改正）３－５－３－１～３－５－３－５，３－５－４，１０－６（令和８年１０月２２日確認）https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
②「『個人情報の保護に関する法律についてのガイドライン』に関するＱ＆Ａ」（令和７年７月１日更新）Ｑ６－２，Ｑ６－15～６－18，Ｑ６－22，Ｑ６－24，Ｑ７－53，Ｑ７－55，Ｑ１０－20（令和８年１０月２２日確認）https://www.ppc.go.jp/personalinfo/faq/APPI_QA/
③「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」（令和６年１２月１１日，令和８年１０月７日改訂）https://www.ppc.go.jp/files/pdf/261007_warning.pdf
④個人情報保護委員会「マンガで学ぶ令和2年改正個人情報保護法「漏えい等報告・本人通知」編」（YouTube，令和６年９月１０日公開）https://www.youtube.com/watch?v=xbskQPWIcXA
３ PHPの脆弱性に関する資料
①PHP「News Archive 2026」（令和８年１０月２１日のセキュリティアドバイザリ。令和８年１０月２２日確認）https://www.php.net/archive/2026.php
②php/php-src「RCE via stale global state」（CVE-2026-109619。令和８年１０月２２日確認）https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
③JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（令和８年１０月２２日）https://www.jpcert.or.jp/at/2026/at260033.html
④Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」（令和８年１０月２２日確認）https://www.wiz.io/blog/php2shell-php-rce
⑤Cloudflare「Cloudflare deploys protections against php2shell vulnerability」（令和８年１０月２１日）https://blog.cloudflare.com/php-vulnerabilities-waf-protection