PHPの脆弱性への対処法【タイプ1】WordPressで作ったWebサイトをレンタルサーバーで運営している
PHP本体を上げるのは、レンタルサーバー会社の仕事です。
あなたがサーバーに入って作業することはありません。
ただ、あなたにしかできないことが1つあります。
レンタルサーバーの管理画面で「サイトに設定しているPHPのバージョン」を確かめることです。
WordPressの管理画面ではないので注意してください。
多くのレンタルサーバーでは、PHPのバージョンを利用者が管理画面で選ぶ仕組みになっています。
サーバー会社はPHPを修正版に入れ替えますが、利用者が選んだバージョンを勝手には変えないのが一般的です。
8.1以前（7.4など）を選んだままだと、サポートが終わったバージョンのまま動き続けます。
PHP 8.3以上になっていた場合
今やることはありません。
サーバー会社のお知らせで、修正版の適用が済んだかだけ見ておけばOKです。
PHP 8.2になっていた場合
今回の修正版は届きますが、8.2は2026年12月31日でサポートが終わります。
年内に、下の手順で8.3以上へ切り替えてください。
PHP 8.1以前になっていた場合
今すぐ8.3以上に切り替えます。
ただし、切り替えるとプラグインやテーマが動かなくなることがあるので、次の順番でやると安全です。
- バックアップを取る（サーバー会社の自動バックアップがあれば、取得日時を確認するだけでもOK）
- WordPress本体・プラグイン・テーマを最新にする
- レンタルサーバーの管理画面でPHPを切り替える
- トップページ、問い合わせフォーム、ログイン画面を開いて確認する
- 表示がおかしければ、PHPを元のバージョンに戻す
不具合の多くは、古いプラグインが新しいPHPに対応していないことで起きます。
手順2を先にやっておくだけで、かなり避けられます。
PHPの脆弱性への対処法【タイプ2】制作会社に作ってもらったサイトを持っている
自分で作っていなくても、サイトの持ち主はあなたです。
何もしないで待つのは危険です。
制作会社や保守の担当者に、次の文面をそのまま送ってください。
PHPの重大な脆弱性（CVE-2026-109618／CVE-2026-109619）について、弊社サイトの対応状況を教えてください。
１．サイトで使っているPHPのバージョン
２．修正版（8.5.12／8.4.27／8.3.36／8.2.35）への更新は済んでいるか、済んでいなければ予定日
３．PHP 8.1以前の場合、今後の対応方針
2〜3日たっても返事が来なければ、それ自体が「サーバーを誰も見ていない」というサインです。
その場合は、別の会社に保守を頼むことも考えてください。
PHPの脆弱性への対処法【タイプ3】1ユーザーとして、PHPが使われているであろうサービスを使っている
PHPを上げるのはサービス側の仕事です。
基本は何もしなくて大丈夫です。
ただ、どこかのサービスが被害に遭っても困らないように、普段の対策だけ見直しておきましょう。
- パスワードを使い回さない
- 2段階認証を有効にする
- 「脆弱性対応のためパスワードを再設定してください」というメールのリンクは踏まない
ログインは、ブックマークや公式アプリからしてください。
PHPの脆弱性への対処法【タイプ4】Laravelなどで開発し、AWSなどで運用している
「AWSを使っているから、AWSが直してくれる」とは限りません。
AWSが面倒を見る範囲はサービスによって違い、その上で動くPHPは利用者の担当、というのが基本です。
- EC2・Lightsail（サーバーを丸ごと借りる。Laravel Forge経由も含む）→ 自分で上げる
- ECS・Fargate（Dockerコンテナで動かす）→ 自分でイメージを作り直す（タイプ5）
- Elastic Beanstalk → AWSが修正版入りの環境を出したら、それに更新する（自動更新の設定があれば、週1回のメンテナンス時間に適用される）
- Lambda（Bref・Laravel Vaporなど）→ LambdaにはPHPの公式の実行環境が無いので、AWSの自動更新は効かない。提供元が修正版を出したら取り込んで、デプロイし直す
- Laravel Cloudなど、PHPの更新まで提供元がやるサービス → 提供元のお知らせを待つ
さくらのVPSやConoHa VPSなど、AWS以外のサーバーでも考え方は同じです。
PHPを自分で修正版に上げる手順
8.3なら8.3のまま修正版になるだけなので、アプリのコードの修正は要りません。
OSのパッケージ管理で修正版を入れて、PHP-FPM（Webサーバーの裏でPHPを動かす仕組み）を再起動します。
手順はOSやサーバーの構成によって違います。
次はUbuntuでPHP 8.3を使っている場合の一例で、サーバーにSSHでログインして実行します。
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
Amazon Linuxなら sudo dnf upgrade と sudo systemctl restart php-fpm です。
なお、Ubuntuの標準パッケージは、番号を変えずに修正だけ取り込みます。
その場合は php -v の番号ではなく、「Ubuntu Security Notices」でCVE番号を検索して、修正済みかを確かめてください。
Laravel Octaneを使っているなら、Octaneもプロセスごと再起動します（supervisorなどからrestart）。
OctaneはWebのリクエストを直接処理していて、php artisan octane:reload だけでは古いPHPのまま動き続けることがあるからです。
FrankenPHPで動かしているなら、PHPがFrankenPHPの中に組み込まれているので、FrankenPHP本体の修正版が出たら入れ替えてください。
2026年10月22日2時の時点ではまだ出ていないので、それまでは下の回避策を入れておきます。
キューワーカーやHorizonも、ついでに再起動しておくと確実です。
開発に使っているPCのPHPは、外から攻撃される場所にはないので急ぎではありませんが、ついでに上げておきましょう。
PHPの修正版がまだ届かないときの回避策
OSのパッケージに修正版が届くまで、数時間〜数日かかることがあります。
その間は、PHP公式が出している回避策の設定を入れて、2つの脆弱性の入口を狭めておきます。
- post_max_size：1回に受け付ける送信データの大きさを小さくする（大きなデータを送りつけてメモリ不足を起こさせる攻撃を減らす）
- session.upload_progress.enabled：ファイルアップロードの進み具合を記録する機能を止める（CVE-2026-109619の、確認済みの入口になっている機能）
post_max_size = 8M
session.upload_progress.enabled = 0
php.iniに書いて、PHP-FPMを再起動します。
ファイルアップロードを使うサイトは post_max_size を32Mにして、upload_max_filesize はそれより小さくします。
もう1つ、memory_limit（PHPが使えるメモリの上限）を外します。
CVE-2026-109618は、主にメモリの上限に達して処理が途中で止まったときに起きるからです。
この設定はphp.iniではなく、PHP-FPMのプール設定（www.confなど）に書きます。
こうするとアプリ側から書き換えられません。
php_admin_value[memory_limit] = -1
Apacheにmod_phpで組み込んでいる場合は、Apacheの設定に php_admin_value memory_limit -1 と書きます。
ほかの設定で上限が付け直されていないかも確かめてください。
なお、上限を外すと、処理が暴走したときにサーバーのメモリを使い切るおそれがあります。
修正版を入れたら、元の値に戻しておきましょう。
PHP 8.5を使っているなら、fatal_error_backtraces = 0（エラー時に詳しい記録を出す機能を止める）も加えます。
ただ、公式も「回避策は一部の攻撃を減らすだけ。完全な対策は更新だけ」としています。
修正版が届いたら、すぐに上げてください。
PHPの脆弱性への対処法【タイプ5】Dockerで開発・運用している
Dockerを使っている場合、PHPはサーバーやPCではなく、イメージの中に入っています。
サーバーで apt を実行しても、コンテナの中のPHPは古いままです。
やることは、イメージの作り直しです。
docker composeを使っている場合は、プロジェクトのフォルダでターミナルから次を実行します。
docker compose build --pull --no-cache
docker compose up -d
--pull で最新のベースイメージを取り直します。
本番がECS・Fargateなら、作り直したイメージでデプロイし直します。
開発用のLaravel Sailも作り直します（こちらは急ぎではありません）。
Sailは公式のPHPイメージではなく、Ubuntuに別の配布元からPHPを入れる作りです。
その配布元には2026年10月22日2時の時点で修正版が入っているので、今作り直せば修正版になります。
注意点は2つです。
- Dockerfileで
php:8.3.35-fpm のように番号まで固定しているなら、修正版の番号に書き換える - 公式イメージに修正版が反映されるまで、時間差がある
今回は、PHPの修正版の公開から3時間ほどたった2026年10月22日2時前に、Docker公式のPHPイメージにも修正版が反映されました。
次に脆弱性が出たときも同じ時間差が出るので、反映されるまでの間は、タイプ4の「PHPの修正版がまだ届かないときの回避策」の設定をイメージに追加して（php.iniを足す形で）、デプロイしておきます。
反映されたら作り直して、コンテナの中で php -v を実行し、修正版の番号になっているか必ず確かめてください。
なお、同じ日にNode.jsにも脆弱性が見つかっています。
Node.jsを使っている人は、Node.jsの脆弱性への対処法もあわせて確認してください。
PHPの脆弱性対応のついでに、自分で作ったアプリのセキュリティも点検する
今回はPHP本体の脆弱性でしたが、ほかの部分は大丈夫といえそうですか？
- APIキーやパスワードが、GitHubやブラウザから見える場所に置かれていない
- URLの数字を変えても、他人のデータは見えない
- ログインしていない人は、管理用のページを開けない
1つでも自信がなければ、点検しておくのがおすすめです。
AIに貼るだけで、こうした項目を12個まとめて点検し、問題があれば直すところまで進められるプロンプトを用意しました。
僕の公式LINEではこれを無料で配っているので、よかったら使ってください。
SiiDの公式LINEを追加して「セキュリティ」と送ると、無料で受け取れます。
PHPの脆弱性（CVE-2026-109618・109619）に関する出典
AIプログラミングスクール「SiiD」について
AIプログラミングスクール「SiiD」は、未経験からITエンジニア転職を目指す方向けのオンラインスクールです。
SiiDの特徴
- 現役エンジニアでYouTube登録者約13万人の「セイト先生」が代表兼主任講師
- 採用側の実務知見（2,000人以上の選考・150名以上のエンジニア採用）にもとづく指導
- 生成AIを取り入れた学習設計と、実務レベルのフルスタックWeb開発スキル
- Workship CAREER（株式会社GIG）と連携した無料の転職伴走支援
- 経済産業省認定のReスキル講座で、給付金の条件を満たせば実質105,600円〜
- 学割あり（35%オフ）
こんな方におすすめ
- 未経験・文系・社会人からITエンジニア転職を本気で目指したい方
- 独学に限界を感じている方
- 費用を抑えながら実務スキルと転職サポートを両立したい方
「未経験だから」とあきらめる必要はありません。採用する側を知り尽くしたプロが、給付金で負担を抑えながら内定まで伴走します。
