ホームページの保守契約、脆弱性対応は含まれている？ 誰が・いつまでに・何をするかを決める確認リスト

2026年10月に何があったか（2026年11月時点）

この節の内容は、あとで変わる可能性があります。日付・バージョンは2026年11月6日時点で、各公式ページで確かめたものです。

• PHP（通称 PHP2shell）：認証なしで遠隔からコードを実行されるおそれがある、と PHP の公式が案内しています。IPA と JPCERT/CC が注意喚起を出し、JPCERT/CC は悪用を試みる通信の観測が相次いでいること、10月29日の更新では、あるファイアウォール製品の特定バージョンで侵害の成功を示唆する痕跡を確認したという報告にも触れています。WordPress.org は「WordPress 固有の問題ではなく、PHP のアプリを動かすすべてのサーバーが影響を受ける」と説明し、WordPress の更新は必要なく予定もないとしています。つまり、必要なのは WordPress 本体ではなく、サーバーの PHP の更新です。
• Next.js：Critical の2件は、どちらも特定の機能や動かす環境の条件に当たるサイトで、認証なしで遠隔からコードを実行されるおそれがあるものです。このうち use cache の件について、公式は、App Router と Cache Components を使うアプリなら、同じような関数がなくてもすぐに更新するよう勧めています。11月3日には11月のセキュリティリリース（16.4.5、15.5.29）も出ています。
• Node.js：Brotli という圧縮形式の処理に関わる修正を含みます。攻撃者が送ったデータをアプリが展開すると、停止やメモリの内容の漏えい、遠隔からのコード実行につながり得る、とされています。

あわせて、サポート期限も近づいています。PHP 8.2 のセキュリティ修正は2026年12月31日まで、Next.js 15 のセキュリティリリースは2027年1月31日までです。PHP 8.1 以前は、すでに PHP プロジェクトからの更新がありません。

まず「自社サイトが何で動いているか」を控える

ニュースを見て最初に困るのは、「うちは対象なのか」が分からないことです。IPA の「安全なウェブサイト運営にむけて」も、使っているソフトウェアの名前やバージョンを控えておくよう勧めています。

制作会社に頼んで、次の4つを1枚の表にしてもらいましょう。

• サイト・仕組みの名前（コーポレートサイト、予約フォーム など）
• 使っている技術と、そのバージョン（PHP 8.3、Next.js 16.4 など）
• 動いている場所（レンタルサーバー、クラウド、制作会社のサーバー）
• 更新する担当（サーバー会社・制作会社・自社のどれか）

この表があれば、次にニュースが出たとき、対象かどうかを数分で判断できます。表はバージョンを上げるたびに更新してもらう、と決めておきます。

誰の仕事か：3つの層で担当が分かれる

サイトは、ざっくり3つの層でできています。層ごとに、更新する人が違うことがよくあります。

気をつけたいのは、層の「すき間」です。たとえばレンタルサーバーには、PHP の細かな修正はサーバー会社が当てても、PHP 8.2 から 8.3 へ上げる切り替えは契約者が管理画面で行う、という分け方のサービスがあります。その「契約者」が自社なのか、制作会社なのかが決まっていないと、誰も手を付けないまま期限が過ぎます。

どちらが担当になるかは、契約しだいです。自社の契約書と、サーバーの契約者が誰の名義かを確かめておきましょう。

いつまでに直すか：深刻度と悪用の状況で決める

すべての更新をすぐに当てる必要はありません。かといって、毎回「急ぎで」と頼むと、費用も手間もふくらみます。そこで、深刻度と悪用されているかどうかの2つで、対応の期限をあらかじめ決めておくのがおすすめです。

深刻度は、CVSS という共通の物差しで表されることが多く、9.0〜10.0 が Critical、7.0〜8.9 が High です。

次の表は、目安の一例です。正解は会社やサイトによって違うので、制作会社と話し合って決めてください。

「悪用が確認されている」かどうかは、JPCERT/CC や IPA の注意喚起、米国 CISA が悪用を確認した脆弱性をまとめた一覧（KEV カタログ）などで分かります。今回の PHP は、注意喚起が出ており、IPA によると KEV にも登録されました。

なお、更新すると表示や動きが変わることがあります。JPCERT/CC も、十分なテストをしたうえで速やかに適用するよう呼びかけています。急ぐときほど、確認の手順も一緒に決めておきます。

サポート期限という「見えない期日」

脆弱性のニュースより見落とされやすいのが、サポート期限です。期限を過ぎた版には、セキュリティの修正が出ません。Node.js の公式も、本番では LTS（長期サポート）の版だけを使うよう案内しています。

期限が切れる前のバージョンアップは、ニュースのたびの更新より作業が大きく、費用もかかります。直前に慌てないよう、次のように決めておきます。

• 使っている技術のサポート期限を、先ほどの表に書き足す
• 期限の半年前に、制作会社から見積もりをもらう
• バージョンアップを、毎年の予算に入れておく

保守契約の内容で確かめる12項目

今の保守契約に、次のことが書かれているかを確かめてみてください。IPA の資料も、委託先と約束したことは文書に残すよう勧めています。

1. 保守の対象（どのサイト・仕組みか）
2. 使っている技術とバージョンの表を、誰が持ち、いつ更新するか
3. サーバー・アプリの部品・判断の、それぞれの担当
4. 脆弱性の情報を、誰が見て、自社に知らせるか
5. 深刻度ごとの対応期限
6. 月額の費用に含まれる作業と、別に見積もる作業の境目
7. 夜間・休日の連絡先と、対応するかどうか
8. 更新の前後に、何を確かめるか（表示・フォーム・決済など）
9. サポート期限の把握と、バージョンアップの相談の時期
10. 公開を止める判断を、自社の誰が下すか
11. バックアップの場所と期間、そこから戻す手順を試しているか
12. 管理画面のアカウントと権限、改ざんや不正なログインに気づく仕組み

答えがあいまいな項目は、責めるのではなく「一緒に決めたい」と伝えるのが近道です。制作会社にとっても、決まっていたほうが動きやすくなります。

万一、情報が漏れたら：報告の期限と判断する人

個人情報が漏れた、または漏れたおそれがあるときは、個人情報保護委員会への報告と本人への通知が必要になる場合があります。報告の対象は、要配慮個人情報が含まれるとき、財産的被害が生じるおそれがあるとき、不正の目的をもって行われた漏えい等のとき、1,000人を超えるときの4つです（おそれがある場合を含みます）。

個人情報保護委員会は、速報を発覚から速やかに（概ね3〜5日以内）、確報を30日以内（不正な目的のおそれがある場合は60日以内）に行うよう案内しています。短い期間で動くには、次を先に決めておく必要があります。

• 制作会社やサーバー会社から、最初の連絡を受ける人
• 公開を止めるか、どこまで調べるかを判断する人
• 報告や通知の文面を確かめる人（必要なら弁護士など）

まとめ

• ニュースのたびに慌てないために、使っている技術とバージョンの表を作り、担当を決める
• 深刻度と悪用の状況で、対応の期限をあらかじめ決めておく
• サポート期限を予算の計画に入れ、契約で「誰が・いつまでに・何を」を文書にしておく

MODS BASE でも、サイトの保守の取り決めづくりや、今の契約の見直しのご相談を受けています。気になる点があれば、お気軽にお問い合わせください。

参考

• Next.js Security Update for Upstream Vulnerabilities（Next.js、2026年10月14日）
• November 2026 Security Release（Next.js）
• PHP: News Archive - 2026（PHP）
• Wednesday, October 21, 2026 Security Releases（Node.js）
• PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)（IPA）
• PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起（JPCERT/CC）
• Critical PHP Security Release（WordPress.org）
• Supported Versions（PHP）
• Support Policy（Next.js）
• Node.js Releases（Node.js）
• Common Vulnerability Scoring System version 4.0: Specification Document（FIRST）
• 安全なウェブサイト運営にむけて～企業ウェブサイトのための脆弱性対応ガイド～（IPA、2021年3月、PDF）
• 漏えい等報告・本人への通知の義務化について（個人情報保護委員会）
• 漏えい等の対応とお役立ち資料（個人情報保護委員会）