2026年10月22日時点の確認です。前日10月21日の夜、PHPの開発元が2件の重大な脆弱性を修正するセキュリティリリースを公開しました。セキュリティ業界では php2shell と呼ばれています。番号は CVE-2026-109618 と CVE-2026-109619 で、評価はいずれも CVSS v4.0 の 9.2 です。
結論から書きます。株式会社テバククリエイトのWEBサイト制作とWEBシステム開発では、PHPを使っていません。当社がこの構成で作り、公開しているサイトとシステムに、今回の脆弱性は当たりません。PHPの更新作業も不要です。
自社のVPSやクラウドでPHPを動かしている管理者の方には、後半で公式の修正版の入れ方をまとめています。WordPressやプラグインを更新しても、この問題は直りません。直すのはPHPそのものです。
何が公開されたか
PHP公式は、2026年10月21日に PHP 8.5.12、8.4.27、8.3.36、8.2.35 を公開し、認証されていない第三者から遠隔でコードを実行され得る2件を修正した、と説明しています。欧州のENISAは、修正版の公開を日本時間10月21日22時40分頃（13:40 UTC）としています。当初の予定は10月22日でしたが、脆弱性番号が先に出回ったため、PHP財団の説明では公開が1日早まりました。
2件の中身は、PHP公式とPHP財団が次のように分けています。
- CVE-2026-109618。リクエスト処理の途中でメモリ不足が起きると、PHPが中途半端な内部データを正しいデータとして扱ってしまう問題です。
- CVE-2026-109619。異常終了のタイミングによって、前のリクエストの内部状態が同じ作業プロセスに残り、次のリクエストがそれを使ってしまう問題です。
どちらも、個別のWEBアプリの書き方ではなく、ほぼすべてのリクエストが通るPHP本体のメモリ管理とエラー処理にあります。そのため、アプリ側の修正だけでは閉じません。
公開の時点で、PHP財団は、出回っていた実証コードに実際に動くものは確認できなかったとしています。一方で、セキュリティ企業からは攻撃の試みが観測されたとの報告もあります。PHPをインターネットに出している場合は、修正版へ更新する必要があります。公開前に出回った評価「10.0」は誤りで、PHP財団は実際の評価を 9.2 としています。
影響があるもの
PHP公式が対象だとしているのは、Webのリクエストを処理するPHPです。
- PHP-FPM
- Apache の mod_php。公式は、ここが最もリスクが高いとしています。初期設定のまま、認証のないリクエストで、アプリのコードが動く前に攻撃が成立する例が示されています
- php-cgi
- FrankenPHP
- LiteSpeed
WordPress、Laravel、EC-CUBEのようにPHPの上で動く仕組みは、アプリの出来とは別に対象です。見た目がPHPのサイトでなくても、製品や機器の内部でPHPが動いていれば対象になり得ます。ENISAもその点を注意しています。
ログインなしで、そのPHPプロセスの権限を使ってサーバー上でプログラムを実行される可能性があります。
当社の制作・開発が対象外である理由
PHPをWebサーバーとして動かしていないシステムは、今回の対象外です。株式会社テバククリエイトのWEB制作とシステム開発はこちらです。
案件で使う技術は、React、Svelte、Node.js、Go と、AWS・GCP・Cloudflare です。このコーポレートサイトも SvelteKit で作り、Cloudflare 上で公開しています。ページの表示も、お問い合わせフォームの受付も、PHPでは動いていません。
次の支援も、PHPのWeb実行環境の上では動いていません。
- LINE公式アカウントの構築運用
- Googleマップの運用支援（MEO）
- 映像制作、ドローン空撮、360°カメラ撮影
神戸市中央区（元町）から納品しているこれらのサイトとシステムについて、今回のPHP更新を当社側で行う必要はありません。
当社が作っていないPHPサイトを別に持っている場合
分けてお伝えします。以前からあるWordPress、他社が入ったレンタルサーバーのPHP、社内に残っている別システムは、当社の納品物ではありません。それらがPHPでリクエストを受けているなら、今回の対象です。
管理しているのが自社なら、次の手順で修正版を入れてください。どのサーバーがPHPか分からない場合は、お問い合わせ で切り分けから相談できます。
自社でPHPを管理している方向けの更新手順
ここからは、サーバーの更新権限を自分たちで持っている方向けです。当社が納品したサイトに、この作業は不要です。
作業の要点は4つです。
- Webで実際に動いているPHPの版を確認する
- 同じ系統の修正版を入れる
- PHPのプロセスをすべて入れ直す
- Web経由の版表示が修正版になったことを確認する
同じ系統の中の更新（たとえば 8.3.35 から 8.3.36）なら、通常はアプリのコード修正は不要です。8.1以前から 8.3 へ系統をまたぐときは、非推奨になった機能の確認が別に必要です。作業前に、いまの php.ini とWebサーバーの設定を控えてください。
入れる版
| いまの系統 | 入れる版 |
|---|---|
| PHP 8.5.0〜8.5.11 | 8.5.12 |
| PHP 8.4.0〜8.4.26 | 8.4.27 |
| PHP 8.3.0〜8.3.35 | 8.3.36 |
| PHP 8.2.0〜8.2.34 | 8.2.35 |
| PHP 8.1以前 | 公式の修正リリースなし |
PHP 8.2 は 2026年12月31日でセキュリティ更新が終わります。8.2.35 は今回の修正版ですが、その後は 8.3 以降へ移す計画が必要です。
8.1、8.0、7.4 には、ソースから自分でビルドしている人向けの最小バックポートが公式リポジトリにあります。通常のリリース版はありません。それより古い系統は、PHPプロジェクトからの修正版がありません。サポートされている修正版へ移してください。
Windows版とソースのダウンロードは PHP公式のDownloads です。
1. 動いている版を確認する
ターミナルの php -v は、画面に出しているPHPと違うことがあります。コマンド用、PHP-FPM、Apacheモジュールを別々に見てください。系統の数字は、実際に入っているものに読み替えます。
php -v
php-fpm8.3 -vWeb経由は、確認用に phpinfo を一時的に置き、バージョンと Server API を見て、すぐにファイルを削除してください。置きっぱなしにしないでください。レンタルサーバーの管理画面にPHPバージョンが出る場合は、そこでも確認します。
2. パッケージで入れている場合（Debian / Ubuntu）
更新候補が修正版になっていることを見てから入れます。候補が古いままなら、同じコマンドを繰り返しても直りません。配布元のセキュリティ告知を確認してください。パッケージ名は、使っている系統に合わせます。
sudo apt update
apt-cache policy php8.3-fpm
sudo apt install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
sudo systemctl restart php8.3-fpm
php-fpm8.3 -vmbstring や xml など、関連パッケージも同じ系統のまま揃えてください。Apache の mod_php を使っている場合は、PHPだけでなくWebサーバーも再起動します。
sudo systemctl restart apache23. パッケージで入れている場合（RHEL / AlmaLinux / Rocky / Amazon Linux）
dnf list --installed 'php*'
sudo dnf update php php-cli php-fpm php-common
sudo systemctl restart php-fpm
php -v表示が 8.2.35、8.3.36、8.4.27、8.5.12 のどれかになっていなければ、完了ではありません。PHP公式は、2026年10月21日の時点で、ボランティア運営の rpms.remirepo.net にはその日の更新が載らない、と案内しています。Remi を使っている場合は、パッケージの版が修正版になってから再起動してください。Amazon Linux については、AWSが更新パッケージの目標を2026年10月22日としていました。入ったかどうかは、バージョン表示で判断します。
4. Docker / コンテナの場合
コンテナを再起動しただけでは、中のPHPは古いままです。イメージを修正版のタグで取り直し、コンテナを作り直します。公式イメージは 8.5.12、8.4.27、8.3.36、8.2.35 へ更新されています。
Dockerfile では、系統を飛ばさないよう版まで指定します。latest は 8.5 系を指すため、いま 8.3 で動かしている環境を latest へ上げないでください。
FROM php:8.3.36-fpm反映の例です。サービス名は環境に合わせて読み替えます。
docker compose build --pull
docker compose up -d --force-recreate
docker compose exec web php -v5. Windows の場合
Downloads から、いまと同じ系統の修正版を取ります。IIS の FastCGI やコマンド用は Non Thread Safe、Apache にモジュールとして載せる場合は Thread Safe です。この区別はダウンロードページに書かれています。
展開した中身で、いまのPHPのフォルダを置き換えます。php.ini は残します。IIS または Apache を再起動し、php -v とサイトの表示を確認します。
6. ソースから自分でビルドしている場合
サポート中の系統は、Downloads のソース（8.5.12、8.4.27、8.3.36、8.2.35）を、普段と同じ configure の内容でビルドし直します。8.1、8.0、7.4 で、すでに自分でビルドしている場合だけ、上の公式バックポートを同じやり方でビルドします。
初めてソースから入れる手順は、拡張モジュールの有無で変わるため、この記事では書きません。パッケージか公式バイナリを使ってください。
7. 共有レンタルサーバーの場合
利用者がPHP本体を差し替えられないことがほとんどです。管理画面でPHPの系統を選べても、修正が入ったビルドを置いているのは事業者です。
- 利用中のサーバー会社のメンテナンス告知を確認する
- 管理画面のPHPバージョンが、上の修正版になっているか見る
- なっていなければ、「8.3.36、8.4.27、8.5.12、8.2.35 のどれかですか」とサポートへ聞く
- WordPressやプラグインだけ更新して終わらない
8. 入れたあとの確認
- コマンド用と、Webに出しているPHPの両方が修正版である
- PHP-FPM や Apache を再起動し、古いプロセスが残っていない
- コンテナはイメージを取り直して作り直した
- cron やキューが、別のパスの php を呼んでいない
- トップページ、管理画面、フォーム送信が動く
- 確認用の phpinfo を削除した
今日中に入れられない場合、PHP公式は「更新だけが完全な対策で、設定変更は特定の経路の露出を下げるだけで安全にはならない」としています。一時的な設定は 公式のセキュリティ告知 を見てください。ENISAは、すぐ直せないときは公開ネットワークから切り離すことも選択肢に挙げています。
よくある質問
当社が作ったサイトは、今回の対象ですか
対象外です。株式会社テバククリエイトのWEBサイト制作とWEBシステム開発ではPHPを使っていません。このコーポレートサイトも SvelteKit と Cloudflare で公開しています。
WordPressやプラグインを更新すれば直りますか
直りません。脆弱性はPHP本体にあります。Webに出しているPHPを、同じ系統の修正版（8.5.12、8.4.27、8.3.36、8.2.35）にする必要があります。
共有レンタルサーバーでも、自分で修正版を入れられますか
多くの場合は入れられません。PHP本体の更新はサーバー事業者の作業です。メンテナンス告知と、管理画面のバージョン表示を確認してください。
コンテナを再起動すれば反映されますか
再起動だけでは古いままです。修正版のイメージを取り直し、コンテナを作り直してから、中の php -v を確認してください。
出典
事実関係は、2026年10月22日に次を確認して書きました。
- PHP公式のセキュリティ告知（2026年10月21日）
- PHP Foundation「Today's PHP Security Release」
- GitHub Advisory GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- GitHub Advisory GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- ENISAほかの共同声明
- IPA「PHPのセキュリティリリース公開予定について」（2026年10月21日の事前告知）
- 公式Dockerイメージの更新（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）
IPAのページは、リリース前の準備を求める告知です。2026年10月22日に確認した時点では、修正版の版番号までは書かれていませんでした。入れる版はPHP公式の告知を基準にしてください。
神戸でシステム開発・制作をご検討なら
神戸でシステム開発をするなら、株式会社テバククリエイトにご相談ください。兵庫県神戸市中央区海岸通（元町エリア）を拠点に、要件の整理から公開後の保守まで一貫して対応します。兵庫県内は訪問での打ち合わせが可能です。
