PHPの脆弱性で移行を考えたら｜画面はそのまま、クラウドへ移す判断と進め方

「PHPに緊急の脆弱性が出たと聞いたけれど、うちのシステムは何年も前に作ったきりで、誰に聞けばいいのかも分からない」——古いPHPのシステムを抱える会社から、こうした声を聞きます。パッチを当てて済むなら、それが一番です。ただ、パッチを当てられない・当てても次が続かないシステムもあります。

この記事では、パッチの次の判断として「作り直してクラウドへ移す」場合の考え方を整理します。

先に、要点をまとめます。

PHPのセキュリティチームは2026年10月21日、緊急度の高い脆弱性2件を修正した8.5.12・8.4.27・8.3.36・8.2.35を公開しました。 まず行うのは、現在の保守会社やサーバー会社と連絡を取り、修正版を当てられるかを確認することです。
PHPの公式サポートは8.2〜8.5の4つで、8.1以前はすでに終了しています。 8.2も2026年12月31日で終わります。終了した版を使っている、またはサポート中の版に上げると動かなくなるシステムは、移行を検討する段階です。
移行は「画面と機能を変えずに、土台だけを入れ替える」と範囲を決めると進めやすくなります。 デザインの刷新や機能の追加は、移行が終わってから第2期で行います。

まずはここから。 サーバーの管理画面か、システムを作った会社への問い合わせで、使っているPHPのバージョンを確認してください。8.1以前かどうかで、次にすることが変わります。

2026年10月22日時点で、php.netの発表と報道を確認した情報です。対応状況は更新されることがあるため、判断の前には本文中の公式ページをご確認ください。

今回のPHPの脆弱性では何が起きていますか？

PHP本体に、ログインしていない第三者から任意のコードを実行されるおそれがある脆弱性が2件見つかり、2026年10月21日に修正版が公開されました。

php.netの発表では、2件ともCVSS v4.0（脆弱性の深刻度を表す共通の指標）で9.2とされています。修正版は2026年10月21日14時（協定世界時。日本時間では23時）に公開されました。

サポート中の版	修正版
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

対象は、Webのリクエストを処理しているPHP全般です。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが挙げられています。なかでもmod_phpは、アプリケーションのコードが動く前に攻撃が成立する例が示されており、公式は最も危険度が高いとしています。

報道では、識別番号はCVE-2026-109618とCVE-2026-109619で、研究者の間では「php2shell」と呼ばれています。ITmedia NEWSの記事やpiyologのまとめによると、詳細は修正版の公開前に流出しており、影響はPHP 5以降の広い範囲に及ぶ可能性があると指摘されています。修正版の公開後には、セキュリティ企業のwatchTowrが、2件を狙った攻撃の試みを観測したと報告しています。公式は「完全な回避策はなく、更新だけが安全な選択」と説明しています。設定変更による軽減策も示されていますが、完全に防げるものではないとされています。

自社のシステムやホームページがPHPで動いているなら、修正版をいつ、誰が当てるかを確認するのが最初の対応です。

自社のシステムは移行を考えるべきですか？

サポート中の版で、修正版を当てて動作を確かめられる体制があれば、移行は急ぎません。8.1以前の版を使っている、または当ててくれる人がいない場合は、移行を考える段階です。

既存システムを移行したいについて相談する老朽化した業務システム、限界がきたSaaS、連絡の取れない開発会社が作ったシステムを、業務を止めずに引き取って作り変える受託開発既存システムを移行したいを見る →

自社の状態	次の一手
PHP 8.3〜8.5で、保守会社や社内の担当者がいる	修正版（8.3.36・8.4.27・8.5.12）を当てて、主要な画面の動作を確認する
PHP 8.2で、保守会社がいる	修正版（8.2.35）を当てる。2026年12月31日のサポート終了までに、版を上げるか移行するかを決める
PHP 8.1以前、または版を上げると動かなくなる	公式の修正版は出ていない。当面の手当てを保守会社と相談しつつ、移行を検討する
作った会社と連絡が取れない、直せる人がいない	サーバーのPHPを更新したあと、動かなくなっても直せない。サーバー会社に更新の予定を確認しつつ、移行の調査から始める
WordPressやEC-CUBEなどのパッケージで作ったサイト	脆弱性はPHP本体にあるため、サーバーのPHPの更新が必要。パッケージ本体の更新とは別に確認する

PHPのサポート方針では、各版は最初の2年間にすべての不具合と脆弱性が、その後の2年間は重大な脆弱性だけが修正され、4年が過ぎるとサポートが終わります。2026年10月時点のサポート期限は次のとおりです。

版	セキュリティ修正の期限
PHP 8.1以前	終了済み
PHP 8.2	2026年12月31日
PHP 8.3	2027年12月31日
PHP 8.4	2028年12月31日
PHP 8.5	2029年12月31日

今回、PHP 8.1以前には正式な修正版は出ていません。公式は、7.4・8.0・8.1向けに、ソースコードから自分でビルドする人のための最小限の修正だけを公開し、それ以外はLinuxディストリビューションやサポート販売会社に問い合わせるか、サポート中の版へ上げるよう案内しています。7.3以前には、この最小限の修正もありません。

レンタルサーバーやLinuxディストリビューションによっては、古い版向けに独自に修正を取り込んでいる場合があります。契約しているサーバー会社の案内も確認してください。ただし、こうした個別の対応は今回限りの手当てで、次に脆弱性が見つかったときにも同じ対応があるとは限りません。

同じ10月21日にはNode.jsも11件の脆弱性を修正しており、Next.jsも8月と9月に緊急の修正版を出しています。修正版が続く背景と、保守の契約で決めておくことは、Node.js・Next.jsの脆弱性修正が続く理由で扱っています。

パッチを当てて使い続けることと、移行は何が違いますか？

パッチは「今の穴をふさぐ」対応で、移行は「修正が届き続ける土台に乗り換える」対応です。古い版のまま使い続ける限り、今回のような告知のたびに同じ判断を迫られます。

✖ よくある思い込み	〇実際の条件
パッチを当てれば当面は安全	サポート中の8.2〜8.5なら当てられる。8.1以前には正式な修正版が出ず、今回もソース向けの最小限の修正にとどまった
8.2なら、まだ大丈夫	8.2のサポートは2026年12月31日で終わる
PHPの版を上げれば済む	古いフレームワークや部品が、新しい版で動かない場合がある
移行するなら、デザインも機能も作り直し	画面と機能をそのまま移す進め方がある
資料がないと移行できない	動いている画面・データベース・ソースコードから調べられる

PHPのまま新しい版へ上げるのが一番小さな対応になるシステムもあります。フレームワークが新しい版に対応していて、作った会社が保守を続けている場合です。この作業は現在の保守会社に相談するのが近道です。

ゼットリンカーが担当するのは、その先の作り直し（リプレース）です。パッチの適用やPHPの版上げの作業はお受けしていません。作り直しを勧める条件は、次のどれかに当てはまる場合です。

使っているフレームワークがサポートを終えていて、新しいPHPで動かない
作った会社と連絡が取れず、ソースコードを直せる人がいない
レンタルサーバーで動いていて、サーバー会社が古いPHPの提供を終えると動かなくなる
今後も機能を足していく予定があり、古い土台のままでは直すたびに手間が増える

移行先のクラウド構成はどう選びますか？

システムの規模、すでに契約しているクラウド、社内のログインの仕組みで選びます。ゼットリンカーが提案する構成は次の3つです。

構成	合う条件	確認しておくこと
Supabase・Vercel・Next.js	社内システムや会員サイトなど小〜中規模。サーバーの管理を自社で持ちたくない	データベースがPostgreSQLになるため、今がMySQLならデータの変換が必要
AWS・Next.js（またはPython）	すでにAWSを使っている、データ量や夜間の一括処理が多い、社内規程でAWSを指定している	今がMySQLなら、MySQLのまま使う選択肢がある。運用の設計に工数がかかる
Azure・Next.js（またはPython）	Microsoft 365を使っていて、社員のアカウントでログインさせたい。社内規程でAzureを指定している	今がMySQLなら、MySQLのまま使う選択肢がある。運用の設計に工数がかかる

Supabase（データベースと認証をまとめて提供するサービス）とVercel（Next.jsの公開に使うサービス）の組み合わせは、サーバーの更新作業を自社で持たずに済むのが特徴です。サーバーのOSや実行環境の修正はサービス側が行うため、今回のような告知のたびに自社でサーバーを更新する作業はなくなります。アプリケーションが使う部品の更新は、移行後も保守として続けます。構成の詳細はNext.js・Supabase・Vercelで業務システムを作るで扱っています。

AWSやAzureは、使える部品が多いぶん、どの部品を組み合わせるかを設計する必要があります。すでに契約がある、社内の規程で決まっているといった理由がある場合に向きます。費用の比べ方はVercelとAWSの費用比較をご覧ください。

画面を作る部分はNext.jsを使います。画面の裏で動く処理は、帳票の作成、CSVの取り込み、夜間の集計など一括処理が中心ならPythonを選ぶことがあります。画面の操作が中心のシステムなら、Next.jsだけで組めます。

なぜ画面を変えずに、そのまま移すのですか？

確認することが「前と同じに動くか」の一点に絞れるからです。画面も機能も変えると、新旧を並べて比べる確かめ方が使えなくなり、確認と相談の量が増えます。

ゼットリンカーは、10年間運用されてきたPHP製の士業向けマッチングプラットフォーム（企業名は非公開）を、Next.js・Supabase・Vercelの構成へ移行しました。10年分の業務データを欠損なく引き継ぎ、業務を一日も止めずに切り替えています。詳しくは実績ページをご覧ください。

この案件では、移行と同時に、デザイン会社と組んだ画面の作り直し、新しい機能の追加、10年分の機能の棚卸しを並行して進めました。今後10年を見据えた基盤として作り直す方針だったため、この進め方を選んでいます。

一方、脆弱性をきっかけに移行を急ぐ場合は、範囲を絞ると、確認と相談の量を減らせます。画面と機能をそのまま移すと、次の利点があります。

確認の基準がはっきりする：今の画面で操作した結果と、新しいシステムの結果を並べて比べるだけで、正しく動いているかが分かります
操作の説明がほとんど要らない：画面が同じなので、社員やお客様は今までどおりの手順で使えます
決めることが減る：「この画面をどう変えるか」の相談がなくなり、確認待ちで止まる時間が減ります

移行の第1期で外し、第2期に回すものの例です。

第1期（移行）で行うこと	第2期（移行後）に回すこと
今の画面・項目・操作の順番をそのまま再現する	デザインの刷新
今ある機能をそのまま移す	新しい機能の追加
今の帳票を同じレイアウトで出す	帳票のレイアウト変更
今のデータをすべて移し、照合する	業務の流れや承認の手順の見直し
今のURLをそのまま使う	権限の分け方の見直し

ただし、移行のときに変えざるを得ないものもあります。

パスワードの保存方式：古い方式で保存されている場合、利用者に再設定をお願いするか、次回ログイン時に新しい方式へ置き換えます
安全でない仕様：入力値をそのままデータベースへ渡しているなど、危険な作りは同じ動きのまま安全な書き方に直します
メールの送信：サーバーから直接送っている場合、メール配信サービス経由に切り替えます
アップロードされたファイル：サーバーの中に保存している場合、クラウドのファイル置き場へ移します

いずれも、利用者から見た画面や操作はできるだけ変えずに対応します。

仕様書がなくても移行できますか？

できます。動いている画面、データベース、ソースコードを調べて、移行に必要な一覧をこちらで作ります。ソースコードが手元にない場合も、画面とデータベースから調べ始められます。

調査のためにご用意いただきたいものは次のとおりです。

本番のURLと、管理画面に入れるアカウント
サーバーとデータベースに入るための情報（レンタルサーバーの管理画面など）
ソースコード（あれば）
日々の業務で使っている画面と、外に出している帳票の例

調査では、画面一覧、機能一覧、データベースの項目の一覧、外部のサービスとの連携の一覧を作ります。この一覧が、移行範囲の合意と見積もりの根拠になります。作った人がいない状態からの調べ方は、仕様書や担当者がいないシステムを引き継ぐ手順で扱っています。

移行はどんな順番で進みますか？

調査で移す範囲を決め、構成を選び、作ってから今のシステムと結果を比べます。データ移行は本番の前に練習し、切り替えたあとも元に戻せる状態を残します。

現状の調査：画面・機能・データ・連携を一覧にする
移す範囲の合意：第1期に含めるもの、第2期に回すものを決める
構成の選定：3つの構成から、規模と社内の条件に合うものを選ぶ
開発：今の画面と機能を新しい構成で作る
今のシステムとの比べ合わせ：同じ操作をして、表示・計算結果・帳票が一致するかを確かめる
データ移行の練習：本番のデータのコピーで移行を試し、件数・金額の合計・コードの対応を照合する
切り替え：利用の少ない時間帯に切り替え、問題があれば元のシステムに戻せる手順を用意しておく

5番目の比べ合わせは、画面をそのまま移すからこそ使える確かめ方です。既存の処理と同じ結果になるかを検証する方法は、AIでレガシー刷新を進める方法でも扱っています。データの照合項目はレガシーシステム刷新の進め方をご覧ください。

移行が終わるまで、今のシステムはどう守りますか？

移行には調査から切り替えまで一定の期間がかかります。その間は、今のシステムの保守会社やサーバー会社と、次の対応ができるかを相談してください。

修正版の適用：サポート中の版なら、修正版を当てる。8.1以前なら、サーバー会社やディストリビューションが独自の修正を出していないかを確認する
公式の軽減策の検討：php.netの発表には、すぐに更新できない場合の設定変更（アップロードの進捗表示機能を止める、送信できるデータの上限を下げるなど）が示されています。完全には防げないとされているため、更新や移行までのつなぎとして扱います
WAFの設定：WAF（Webアプリケーションへの攻撃を手前で止める仕組み）を、サーバー会社のオプションなどで有効にする
管理画面の接続元の制限：管理画面に社内のネットワークからしか入れないようにする
使っていない機能の停止：昔のキャンペーンページや使われていない問い合わせフォームを止める
バックアップの確認：データベースとアップロードされたファイルのバックアップが取れていて、戻せるかを確かめる

ゼットリンカーはこれらの作業はお受けしていませんが、移行の調査の中で、今のシステムで気になった箇所はお伝えします。古いシステムで確認したい項目は古いシステムのセキュリティを見直す、バックアップはバックアップから復旧できるかを確認するにまとめています。

発注の前に何を決めておけばよいですか？

期限、移す範囲、クラウドの指定、データの範囲、止めてよい時間、移行後の保守の6つです。決まっていない項目は、調査のあとに一緒に決められます。

決めること	確認の例
期限	PHP 8.2のサポート終了、サーバー契約の更新月、繁忙期を避けたい時期
移す範囲	第1期は画面と機能をそのまま移す方針でよいか
クラウドの指定	社内規程でAWSやAzureが決まっているか、Microsoft 365のアカウントでログインさせたいか
データの範囲	何年分のデータを移すか、古いデータは読み取り専用で残すか
止めてよい時間	切り替えのときに、システムを止めてよい時間帯と長さ
移行後の保守	移行後の不具合対応や改修を、どこに頼むか

社内で稟議を通す場合は、この表に「今のシステムで修正版が当てられるか」と「誰が直せるか」を書き添えると、移行が必要な理由を説明しやすくなります。

費用と期間はどう見積もりますか？

画面の数、データベースの項目の数、外部のサービスとの連携の数、一括処理の数、移すデータの量で決まります。調査で一覧ができると、工程ごとに積み上げて見積もれます。

見積もりでは、開発とは別に次の作業を工数として置きます。

今のソースコードの解析と、その処理が今も必要かの確認
データの変換（MySQLからPostgreSQLへ移す場合など）と照合
今のシステムとの比べ合わせ
切り替えの練習と、元に戻す手順の準備

ゼットリンカーは、要件定義・契約後のすり合わせ・開発・テスト・バッファの時間を積み上げて見積もります。初回相談・お見積もりは無料です。Next.jsへ移す場合の工程と費用の考え方は、PHPリプレイス費用と手順｜Next.js移行すべきかの判断基準でも扱っています。見積書の読み方はシステム開発の見積書の読み方をご覧ください。

よくある質問

Q. 今回のPHPの脆弱性は、パッチを当てれば解決しますか？

サポート中のPHP 8.2〜8.5なら、8.5.12・8.4.27・8.3.36・8.2.35へ更新することが対応になります。8.1以前の版には正式な修正版が出ておらず、7.4〜8.1向けにソースへの最小限の修正が公開されただけです。サーバー会社の対応を確認したうえで、版を上げるか移行するかを決めてください。

Q. PHPのまま新しい版に上げるのと、作り直すのはどちらがよいですか？

フレームワークが新しい版に対応していて、保守を続けてくれる会社がいるなら、版を上げるほうが小さな対応です。フレームワークがサポートを終えている、直せる人がいない場合は、作り直しを比べてください。

Q. 仕様書や資料がなくても依頼できますか？

依頼できます。本番のURL、管理画面、サーバーやデータベースに入る情報があれば、画面とデータから調べ始められます。ソースコードがあれば、調査はより早く進みます。

Q. 移行の間、システムやサイトは止まりますか？

移行の作業中は今のシステムを使い続けられます。止まるのは切り替えのときだけで、利用の少ない時間帯に行い、止める時間はご相談のうえで決めます。

Q. ドメインやURLは変わりますか？

変えずに移行できます。今のURLをそのまま使えば、ブックマークや検索結果のリンクも同じ場所につながります。

Q. WordPressで作ったホームページも影響を受けますか？

今回の脆弱性はPHP本体にあるため、WordPressのサイトも、サーバーのPHPを修正版に更新する必要があります。WordPress本体やプラグインの更新だけでは対応になりません。サイトの作り直しはこの記事の対象外ですが、WordPressの上に独自の業務機能を作り込んでいて、PHPを上げると動かなくなる場合はご相談ください。

PHPシステムの移行を相談する

ご相談の際は、次の4つを分かる範囲でお知らせください。分からない項目は空欄のままで構いません。

システムのURLと、何に使っているか
使っているPHPのバージョン（分からなければ「不明」）
使っている人数（社員だけか、お客様も使うか）
作った会社と連絡が取れるか

お問い合わせには2営業日以内にご返信します。ゼットリンカーは賠償責任保険に加入しています。作り直しで納品するソースコードはお客様にお渡しし、将来ほかの会社へ保守を引き継げる形にします。

なお、パッチの適用やPHPの版上げの作業はお受けしていません。作り直しを前提にした調査と移行のご相談を承ります。整理の段階であれば、リプレースの検討シートとAI相談用プロンプトも使えます。