PHP脆弱性で見えたWebサイト保守の課題｜更新状況・連絡先・対応予定の確認方法

2026年10月、PHPに遠隔からのコード実行につながる複数の脆弱性が公表されました。自社のWebサイトを制作会社や保守会社に任せている企業では、「うちのサイトは対象なのか」「誰に聞けばよいのか」という確認から始めることになります。

この記事は、Webサイトの制作・保守を外部に任せている企業の情シス、総務、広報・Web担当、事業責任者に向けたものです。更新の担当と保守窓口をたどる順序、「対応済み」という回答の確かめ方、次の緊急時に向けて平時から確認しておく項目を扱います。PHPの修正手順や侵害調査の方法は扱いません。技術的な対応を急いでいる場合は、先にPHP公式・IPA・JPCERT/CC・契約しているサーバー提供元の案内を確認し、技術担当者や保守会社へ相談してください。

今回の件は、公表と注意喚起と追加案内の日付が分かれています。

• 10月21日：PHP公式がセキュリティアドバイザリを出し、CVE-2026-109618・CVE-2026-109619を修正した 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開しました（PHP公式 2026年ニュースアーカイブ）
• 10月22日：IPAとJPCERT/CCが国内向けに対策を案内しました（IPA「PHPの脆弱性対策について」、JPCERT/CC「PHPにおける複数の脆弱性に関する注意喚起」）
• 10月23日：PHP公式が、セッションのアップロード進捗機能に関する追加の案内を出しました。別の識別番号（CVE-2026-115560）に関わるもので、特殊な設定とアプリケーションの組み合わせで起きると説明されています

PHP公式は、今回の2件の脆弱性について、緩和策では完全には防げず、修正版への更新が唯一の安全な選択肢だとしています。JPCERT/CCは、修正版の適用とあわせて侵害の有無を調査するよう呼びかけ、痕跡が見つからなくても攻撃を受けていないとは断定できないと注意しています。

ここで押さえておきたいのは、修正の適用と侵害の有無の調査は別の作業だということです。また、サイトが一時的に止まったことと攻撃を受けたことは同じではありません。具体的な修正・緩和・調査の内容は、上記の公式情報と技術担当者に委ねてください。この記事で扱う確認項目の準備や定期確認の開始を、技術対応より先に回す必要はありません。

「古いPHPだから危ない」「新しいPHPだから大丈夫」という判断は、どちらも早すぎます。

PHP公式は、8.1以前の系列にはPHPプロジェクトからの更新が出ないとしつつ、一部のLinuxディストリビューションや長期サポートの提供元が修正を取り込んでいること、7.4・8.0・8.1向けに最小限のソース修正を用意したことも案内しています。実際に、さくらインターネットは10月22日、同社のレンタルサーバ・マネージドサーバ等について、コントロールパネルで選べる旧系列を含むPHPで対応を完了したと告知し、あわせてサポート期間内のPHPへの移行検討を案内しています（さくらインターネット「PHPの脆弱性への対応状況について」）。これは同社が対象として挙げたサービスと時点に限った報告で、ほかの事業者や契約にそのまま当てはまるものではありません。

一方で、新しい系列に更新していても、CMSやプラグインの脆弱性、修正前に攻撃を受けていなかったかは別に確かめる必要があります。PHPの各系列には、通常の不具合修正が続く期間と、重大なセキュリティ修正のみの期間があります（PHP公式「Supported Versions」、10月26日確認時点で8.2系のセキュリティ修正は2026年12月31日まで）。上流のサポート期間と、契約先がどこまで支援するかも別々に確認します。

確認の対象を分けると、聞く相手と根拠が見えてきます。

確認する対象	主に聞く相手	確認の根拠
サーバー上のPHPの修正	サーバー提供元、サーバー管理を担う保守会社	対象サービス・日付が書かれた告知や報告
サイト・CMSの動作	制作会社・保守会社	動作確認の実施日と範囲
侵害の有無の調査	技術・セキュリティの担当者や専門事業者	調査の範囲と未確認の事項
誰が何を担うか	自社の発注担当、契約先	契約書・保守仕様・見積書

実際の分担は契約によって違います。「サーバー会社だから」「制作会社だから」と業者の種類だけで決めず、契約書と保守仕様で確かめてください。

たとえば、次のような場面を考えます（編集上の例です）。サイトを作ったときの担当者の名刺にメールを送ったが返事がなく、後から退職していたと分かった。社内にも当時の経緯を知る人がいない。

このとき頼りになるのは、担当個人の記憶ではなく、会社と契約の記録です。次の順にたどります。

1. 自社の記録を確かめる：契約書、発注書、請求書、保守費の支払い記録、引継ぎ資料、過去のメール。毎月の請求が続いていれば、請求元が契約先を示す手がかりになります
2. 契約先企業の正式な窓口へ問い合わせる：代表電話や問い合わせ窓口から、後任の担当者や組織としての窓口を尋ねます
3. サーバーとドメインの契約者を確かめる：自社名義か制作会社名義か、管理画面のアカウントを誰が持っているか。提供元への問い合わせは、原則として契約者が行います
4. 自社の責任者を決める：連絡がつかない、または契約先で対応できない場合に、別の技術支援へ相談するかを判断する人を社内で決めます

担当者が退職しただけで、契約先が義務に違反しているとは言えません。保守の範囲と連絡手順は、まず契約内容で確かめます。また、契約関係が確認できない相手に管理画面のパスワードや秘密鍵を渡したり、メールや質問票で集めたりしないでください。権限の確認と受け渡しは、契約者と正式な窓口の間で行います。

緊急時に慌てて窓口を探さずにすむよう、平時に確認しておきたい項目を6つの領域に分けました。委託先管理の全体の流れ（選定・契約・運用・更新・終了）は、情報セキュリティ委託先管理とは？必要性から実務の進め方までで説明しています。ここではWebサイトの保守に絞ります。

確認領域	確認する内容	裏付け・次の行動
対象サイトと環境	対象URL、利用しているサーバーサービス、構成を把握している担当	構成資料の保管場所と確認日（資料の中身は表に書かない）
更新の担当	PHPやCMSの更新を誰が行い、提供元の告知を誰が見るか	直近の更新日と報告
保守契約の範囲	サーバー・PHP・サイト・CMSのどこまでが契約内か、緊急時の連絡手順	契約書・保守仕様の該当箇所
組織としての窓口	主窓口、代替窓口、自社側の責任者、担当変更時の連絡方法	個人名だけでなく部署や代表窓口も控える
更新できない理由	互換性、ソースや資料の所在、保守の終了、人員・予算	理由ごとに必要な調査・見積もり
対応予定と判断	対応の担当、予算判断が必要か、対応完了予定日（未定なら予定日を決める期限）、完了を確かめる根拠、再確認日	決まっていない項目は「未定」と残す

これは編集上の確認例で、公的機関が定めた必須項目や、脆弱性の有無を判定する票ではありません。「更新できない理由」の欄は、相手を責めるためではなく、次に何の調査や予算が必要かを見えるようにするためのものです。

確認の頻度は、年に一度の見直しに加えて、サーバーの移転、保守会社の変更、担当者の交代といった変化があったときにも行うと、窓口の情報が古くなりにくくなります。年次確認と変更時の確認の分け方は、委託先管理は年1回で足りる？AI・SaaS・再委託の変更確認を解説で詳しく紹介しています。

保守会社から「対応済みです」と一行のメールが届いた場面を考えます（編集上の例です）。この回答が、サーバー上のPHPの修正を指すのか、サイトの動作確認まで含むのか、侵害の有無の調査を含むのかは、文面だけでは分かりません。

返ってきた回答は、たとえば次のように分けて記録すると、何が残っているかが見えます（記事内の分類例で、特定のツールの画面項目ではありません）。

• 調査中
• 提供元が対象環境の修正を案内している
• 更新・移行を計画中
• 窓口不明・連絡がつかない

あわせて残したいのは、対象サービス、該当するCVE、対応内容、対応日、根拠（告知のURLや報告書）、サイトの動作確認と侵害調査の範囲、まだ確認できていない事項です。

次のような飛躍には注意します。

• 保守契約がある → 修正済み
• 回答があった → 安全
• 回答がない → 影響なし

未解決の事項には、担当、次の行動、予定日、判断する人を残します。待つことが危険な状況では、回答期限まで待たずに電話などで直接連絡してください。記録は、こうした連絡の内容と判断を後からたどれるようにするためのもので、緊急の連絡の代わりにはなりません。

古い環境が見つかり、すぐには更新できないと分かったとき、「更新するか閉鎖するか」の二択で考える必要はありません。

IPAは、長期間更新していないシステムでは改修や動作確認が必要になるほか、資料やノウハウの不足、担当者の不在、保守契約の終了などで対策が難しくなると説明しています。そのうえで、システム担当者だけでなく事業責任者や経営層も含めて、更新・移行とその後の維持に必要な人員・予算・保守体制を確保できるかを検討するよう案内しています。見通しが立たない場合は、保守を受けられる製品への移行、機能の縮小、公開の終了、システムの廃止も含めて検討し、更新までの間は暫定策を講じることにも触れています（IPA「PHPの脆弱性対策について」）。

判断の材料として残しておきたいのは次の内容です。

• サイトの事業上の役割と、止まった場合の影響
• 取りうる選択肢（更新、移行、機能の縮小、公開の終了）
• 各選択肢の実施条件と、必要な支援・見積もり
• 更新までの暫定措置
• 判断の期限と、判断する人（技術担当者と事業責任者・予算判断者）
• 問い合わせフォームなどを使っている利用者への影響と代替手段

予算がないことは、放置の理由ではなく判断が必要な事項です。どの選択肢を取るかは、環境と事業への影響を踏まえて、技術担当者と事業責任者が決めます。

マモリスは、繰り返し発生するチェックシート業務（作成・依頼・回収・確認・差し戻し・証跡保管）を扱うサービスです。Webサイトの保守や脆弱性対応を代行するものではなく、PHPのバージョンや脆弱性を検出する機能もありません。扱えるのは、ここまでの確認を相手に依頼し、回答と根拠を確かめて記録する部分です。

進め方の例です。

1. 確認する対象サイトと相手を絞る
2. 上の表から項目を選び、設問として作る（選択式、テキスト、URL、ファイル添付などの形式を使えます）
3. 連絡先が分かっている制作会社・保守会社へ回答を依頼する。回答者はログイン不要で回答できます
4. 回答状況を一覧で把握し、期限前のリマインドメールの自動送信や一括催促を使う
5. 回答と根拠を確認し、不足があればコメントを残して差し戻す
6. 回答履歴・確認履歴を残し、毎年など繰り返し依頼で再確認する

窓口が分からない相手には、まず社内の担当者に「契約先と窓口の調査」を依頼する形になります。マモリスが保守会社や担当者を探し出すことはできません。また、繰り返し依頼は毎週・毎月・毎年の定期確認のためのもので、緊急時の即時通知や常時の監視ではありません。未解決事項の次の行動や予定日は回答やコメントに残せますが、予定日の管理は社内の予定表などと組み合わせてください。

最初は「主窓口と代替窓口」「保守契約の範囲」「直近の更新日」のような2〜3項目から始めると、相手の負担も小さく、回答の確かめ方も決めやすくなります。複数社への依頼・回収の進め方は、チェックシートの回収管理｜依頼前の準備から確認完了まで、管理表の記入例で詳しく説明しています。

保守窓口と更新担当の確認を、少数の設問で依頼から回答確認まで試す場合は、マモリスの無料登録から始められます。

Q1. レンタルサーバーの「対応済み」通知があれば、自社での確認は不要ですか。

通知の対象サービスと対象CVEが、自社の契約と一致しているかを確かめてください。提供元が利用者側の緊急対応は不要と案内している例もありますが、それはサーバー上のPHPについての話です。CMSやプラグインの状態、修正前に攻撃を受けていなかったかは別に確認が必要です。通知のURLと確認日を残しておくと、後から説明しやすくなります。

Q2. 古いPHPが残っていたら、すぐ閉鎖するしかないのですか。

一律ではありません。提供元が修正を取り込んでいる場合もあり、バージョン番号だけでは判断できません。IPAは、更新・移行が終わるまで暫定策を講じ、有効な暫定策が難しい場合は外部からのアクセス遮断やサービスの一時停止が必要かを判断するよう案内しています。継続・移行・縮小・公開終了のどれを選ぶかは、技術担当者と事業責任者が事業への影響を踏まえて決めます。

Q3. 制作会社の担当者が退職していたら、どこへ確認すればよいですか。

契約書・発注書・請求書から契約先の企業を確かめ、その会社の代表窓口に後任や組織としての窓口を尋ねます。あわせて、サーバーとドメインの契約者が誰かを確認してください。契約関係が確認できない相手に、管理画面のパスワードなどを渡さないよう注意します。

Q4. マモリスでPHPの利用状況や修正を自動で検出できますか。

できません。マモリスで扱えるのは、制作会社・保守会社へ確認を依頼し、回答と根拠を確認して記録する運用です。技術的な調査や修正は、技術担当者や保守会社が行います。

• PHP公式 2026年ニュースアーカイブ（10月21日 Security advisory、10月23日 Informational advisory）
• PHP公式「Supported Versions」
• IPA「PHPの脆弱性対策について」（2026年10月22日）
• JPCERT/CC「PHPにおける複数の脆弱性に関する注意喚起」（2026年10月22日）
• さくらインターネット「PHPの脆弱性への対応状況について」（2026年10月22日）