安全と会社での利用

PHPの脆弱性（CVE-⁠2026-⁠109618・109619）⁠｜自分のPHPのバージョン確認と、いまやること

2026年10月21日に、PHPの開発元が、認証なしで外から任意のコードを実行されるおそれのある重大な脆弱性2件の修正版を公開しました。 修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。8.1以前には、開発元の公式の修正版がありません。

この記事は、2026年10月23日の時点で読んだ公式の情報をもとにしています。 サーバー会社の対応や公的機関の案内は更新が続いているため、この記事も更新します。自分で使うときは、必ず下の公式資料の最新の版を開き直してください。

会社のサイトやWordPressをレンタルサーバーやVPSで動かしている人が、いま確かめることは3つです。PHPのバージョン、サーバー会社が出している対応のお知らせ、更新できない古いPHPを使っていないかです。バージョンの数字だけで安全かどうかは決まりません。この記事では、その見方と順番を説明します。

内容は、2026年10月23日に、php.netの告知、PHPのGitHubのアドバイザリ（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）、JPCERT/CCの注意喚起、IPAの注意、各社のお知らせと照らし合わせました。

何が見つかり、何が直ったか

開発元のアドバイザリでは、2件とも深刻度はCritical、CVSS v4.0は9.2と書かれています（開発元の表記です）。php.netは、更新が完全な対策で、設定の変更だけでは安全にならないと書いています。

影響を受ける版と修正版は、アドバイザリの表では次の通りです。

修正版の公開は、php.netの事前告知では2026年10月21日14時（UTC、日本時間の23時）の予定でした。エックスサーバーのお知らせにも「23時頃に修正版が公開された」とあります。

影響の範囲について、php.netは、Webのリクエストを受けるすべてのPHP（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed）が対象で、特にmod_phpが最も危険だと書いています。GitHubのアドバイザリには、mod_phpに対して外からの通信だけで攻撃が成立することを確かめた、とあります。一方、IPAの注意には、実際に悪用された確認の記載はありません。

8.1以前は、表に載っていないだけです

アドバイザリの表に8.1以前が載っていないのは、「影響がない」からではありません。PHP 8.1以前は、PHPの開発元がすでに更新を出していない版です。php.netには、次の内容が書かれています。

• PHP 8.1以前は、開発元からの更新を受けられない。ディストリビューションやLTSの提供元が、独自に修正を出している場合がある
• 重大さを考え、PHPのセキュリティチームが、PHP 7.4、8.0、8.1向けに、ソースから組み立てる人のための最小限のバックポート（古い版へ修正を移したもの）を出した

IPAの注意は、この調査に関わったWiz社によれば、PHP 5.4以降のどの版も、2件のうち少なくとも1件の影響を受けるとしています。JPCERT/CCも、8.1以前はサポートされている版への移行を勧めています。

つまり、8.1以前を使っているなら、次のどれかで修正が入っているかを確かめる必要があります。

• サーバー会社が、自社の判断で修正を当てたと案内している
• OSの提供元（ディストリビューションやLTSの提供元）が、修正済みのパッケージを出している
• 自分でソースから組み立てた版に、上のバックポートを当てた

どれにも当てはまらないなら、修正が入っていない前提で、サポートされている版への移行を計画します。

自分が何をする立場か

使い方によって、やることが変わります。

レンタルサーバーの場合

サーバー会社ごとに、対応の内容が違います。読んだ範囲では、次の通りです。

さくらインターネットは、2026年10月23日17時30分の追記で、さくらのレンタルサーバで提供しているPHPに必要な修正を適用し、サポートが終わったPHPのうち同サービスで提供している版にも修正を適用した、と書いています。ただし、サポートが終わったPHPには今後も新しい脆弱性が見つかる可能性があるので、最新のサポート対象の版を使うよう勧めています。また、2026年10月23日17時の時点で、同社の調査では、この脆弱性を悪用した不正アクセスや情報漏えいなどの被害は報告されていない、とも書かれています。

エックスサーバーは、2026年10月23日13時15分の追記で、提供しているPHP 5.6から8.5に修正パッチの適用が完了した、と書いています。PHP 5.6から8.1はバージョンの表示を変えずに対策し、8.2から8.5は同じ系列の修正版に更新しました。このため、これらの版を使っている人は、この脆弱性への対策として急いで版を変える必要はない、とエックスサーバーは案内しています。PHP 5.1から5.5は、同じお知らせの対応状況の表で、対象となるサーバーの過半数に修正パッチの適用が完了したとされています（2026年10月23日17時の時点）。

大事なのは、エックスサーバーの5.6から8.1のように、版の数字が古いままでも、サーバー会社が修正を当てている場合があることです。逆に、版の数字だけを見て「古いから危険」「新しいから安全」と決めることはできません。数字は参考にとどめて、使っているサーバー会社の最新のお知らせを読みます。この見方は、各社が「自社のサーバーで」どうしたかという案内の範囲に限ります。他の会社や、自分で用意したサーバーには当てはまりません。

VPSや自分のサーバーの場合

さくらインターネットは、さくらのVPSについて、サービスの提供にPHPを使っていないため影響はないとしています。そのうえで、利用者のVPSの中でPHPが動いているなら、最新版への更新を勧めています。VPSの中に自分で入れたPHPは、自分で更新するのが基本です。

更新するPHPがOSの標準のパッケージなら、OSの提供元が出している修正済みのパッケージの案内を確かめます。php.netは、ディストリビューションやLTSの提供元には、修正があらかじめ渡されていたので、提供元を確認するよう書いています。

WordPressを使っている人向けに、本体、プラグイン、テーマ、PHPの更新の分担と点検表を、次の記事にまとめています。

関連記事安全と会社での利用WordPressの脆弱性とバージョン確認｜本体を更新してもPHPは直らない理由と点検表WordPress本体を更新してもPHPは新しくなりません。PHPの重大な脆弱性を受けて、本体、プラグイン、テーマ、PHPを誰がどう更新するか、PHPの版の確かめ方、乗っ取りが心配なときの進め方を、WordPress.orgの案内で整理します。

PHPのバージョンの調べ方

自分の立場に合う方法を選びます。どの方法でも、調べた版を控えておきます。

phpinfo()は、PHPのバージョンのほか、設定、サーバーの情報、環境の情報を一度に出す関数です（php.netの説明）。出る情報が多いので、誰でも開けるURLには置かないでください。 使うなら、ログインした管理者だけが見られる場所で、一度だけ確かめ、確かめたらすぐにファイルを消します。

数字が分かったら、次の点を見ます。

• 8.2から8.5なら、修正版（8.2.35、8.3.36、8.4.27、8.5.12）以上か
• 修正版より前なら、サーバー会社がパッチを当てたと案内しているか（エックスサーバーのように、版の表示が変わらない場合もあります）
• 8.1以前なら、上の「表に載っていないだけです」の確認をする

いまやること（順番）

JPCERT/CCは、速やかな対策の適用と、侵害の有無の調査を勧めています。IPAは、PHPを使うプログラムの棚卸しを呼びかけています。次の順に進めます。

1. 自分のサイトとサーバーを書き出す。 どのドメインが、どのサーバーで、どのPHPで動いているかを、表にします。忘れられた古いサイトや、検証用のサイトも入れます
2. サーバー会社のお知らせを読む。 契約しているサービスの名前で、最新の案内を探し、PHPの版ごとの対応を確かめます
3. 対応済みなら、版の数字と案内を控えて、次の確認へ進む。 未対応の版があるなら、サーバー会社に問い合わせるか、パネルで修正済みの版に変えます
4. 自分で更新する場合は、先に控えを取る。 サイトのファイルとデータベースのバックアップを取り、更新後に、サイトの表示、ログイン、問い合わせフォームなどの主な機能を確かめます。古いPHPからの更新では、使っているプラグインや自作のプログラムが動かなくなることがあります
5. 更新がすぐにできないなら、暫定の対策を考える。 php.netは、更新が完全な対策で、次の設定は特定の攻撃の道筋を減らすだけで、安全にはならないと明記しています。IPAは、有効な暫定対策が難しいときは、外部からのアクセスの遮断やサービスの一時停止が必要かを判断するよう勧めています
6. 侵害の痕跡を確かめる。 下の項目で、ログを見ます
7. 使い続けるかを決める。 更新や保守を続けられる見込みがないなら、保守を受けられるサービスへの移行や、サイトの公開の終了も選択肢です（IPAの案内にあります）

暫定の対策（php.netが挙げているもの）

自分でサーバーを管理している場合のために、php.netが「更新できないとき」として挙げている内容の一部を、そのまま整理します。どれも完全な対策ではありません。

• memory_limit=-1を、アプリケーションが上書きできない形（FPMのプールのphp_admin_valueやApacheの設定）で入れ、どこかの設定が有限の値を戻していないかを確かめる
• post_max_sizeを小さくする。ファイルのアップロードが要らないアプリなら8M、必要なら32Mを、php.netは例に挙げています
• session.upload_progress.enabled=0にして、すべてのワーカーを再起動する（ini_set()や.user.iniには頼らない）
• PHP 8.5では、fatal_error_backtraces=0にして、すべてのワーカーを再起動する
• 初期化の前に警告を出す、無効な設定や古い設定を取り除く

細かい条件と理由は、php.netの告知とアドバイザリに書かれています。作業の前に読んでください。

侵害の痕跡の確かめ方（JPCERT/CCの案内）

JPCERT/CCは、この脆弱性を見つけた人たちの公開情報にもとづき、次の点を確かめるよう勧めています。

• 過去のHTTPの応答で、不自然に長い、または異常な形のPHPSESSIDのCookieが設定されていないか
• 不審なmultipart/form-data形式のリクエストがないか。その前後に、PHPのメモリ上限に関するエラーやHTTP 500のエラーが出ていないか
• PHPのワーカーが予期せず異常終了したり、頻繁に再起動したりした痕跡がないか

JPCERT/CCは同時に、攻撃の道筋は複数あり、単一の検知の条件ですべてを見つけられるとは限らず、痕跡が残らない場合もあるので、痕跡が見つからなくても攻撃を受けていないとは断定できない、と書いています。不審なプロセスの実行、外への通信、見覚えのないファイルの作成といった他の兆候も見ます。侵害が疑われる場合は、ログなどの証拠を保存したうえで、影響の範囲を調べ、必要なら該当のシステムを切り離すよう案内されています。

自分のサーバーでClaude Codeを安全に使う

自分で管理しているサーバーや、そのバックアップの設定ファイルがあるなら、Claude Codeは「版の棚卸し」と「更新の計画の下書き」に役立ちます。変更を実行するのは人間にします。

公式の権限モードの説明（2026年10月23日に読みました）によると、次の違いがあります。

• Manualモード（設定値はdefault）は、ファイルの編集、シェルのコマンド、ネットワークへのアクセスなど、ほとんどの操作の前に、Claude Codeが止まって確認を求めます。ファイルの読み取りは、確認なしで行われます。claude --permission-mode defaultで起動できます
• プランモードは、調べて計画を出すモードで、ソースの編集はしません。計画を承認するまで編集は止まります。シェルのコマンドの扱いは環境で変わり、自動モードが使えるときは、分類器が確かめて実行します。そのため、サーバーに触れる作業では、プランモードでも出るコマンドを必ず読みます

進め方の例は次の通りです。

1. 読むだけから始める。 設定ファイルの写しやサイトのフォルダを渡し、使っているPHPの版と、設定の値の一覧を作らせます。サーバーを書き換える権限は持たせません
2. 版を一覧にさせる。 「どのサイトが、どのPHPの版を使っているか」を表にし、修正版より前のものと、8.1以前のものを分けて出させます。サーバー会社の案内との突き合わせは、人間がします
3. 更新の計画の下書きを作らせる。 手順、バックアップの取り方、更新後に確かめる画面を、下書きとして出させます。実行するのは人間で、1つずつコマンドを読んでから動かします

頼み方の例です。

このフォルダにあるPHPの設定ファイルと
サイトの一覧を読んでください。
ファイルは変更しないでください。
1. サイトごとに、使っているPHPの版が
   分かるものを表にしてください。
2. PHP 8.2.35、8.3.36、8.4.27、8.5.12
   より前のものと、8.1以前のものを
   分けてください。
3. 版が分からないものは、分からないと
   書いてください。推測で埋めないで
   ください。

本物のサーバーにつなぐ鍵やパスワード、本番の顧客データは、渡さないでください。見せたくないファイルをpermissions.denyで読めなくする設定と、最初の安全な使い方は、次の記事で説明しています。

関連記事安全と会社での利用Claude Codeのセキュリティ設定｜権限・sandbox・法人運用【2026年版】Claude Codeを安全に使うためのpermissions、sandbox、機密ファイル拒否、ネットワーク制御、managed settings、データ保持、監査を公式仕様で解説。

関連記事安全と会社での利用Claude Codeを安全に始める初期設定｜初心者の30分スターターClaude Codeを安全に始める初心者向け手順。専用フォルダ、ダミーデータ、権限設定、確認、復旧を30分で試せます。

PHP 8.2のサポートは2026年12月31日までです

php.netの告知には、PHP 8.2が2026年12月31日にサポート終了となり、それ以降はセキュリティ修正を受けられない、と書かれています。php.netのサポート中の版の一覧では、セキュリティ修正が続く期間は次の通りです（2026年10月23日に読みました）。

今回の修正を当てても、8.2は年内で終わります。更新するなら、移行先は8.3以降を考えると、同じ作業を繰り返さずに済みます。ただし、使っているプラグインやプログラムが新しい版で動くかは、事前に確かめてください。

この記事で確かめたことと、確かめていないこと

確かめたこと

• CVE番号、深刻度とCVSSの表記、影響を受ける版と修正版は、php.netとGitHubのアドバイザリの表記と照らし合わせました
• JPCERT/CC、IPA、さくらインターネット、エックスサーバーの記述は、それぞれの公式ページを2026年10月23日に読みました
• PHPのサポート期限は、php.netのサポート中の版の一覧で読みました

確かめていないこと

• NVDの登録内容は、この記事では読んでいません
• 8.1以前の各ディストリビューションや各社の修正の状況は、一つひとつは確かめていません
• Claude Codeでサーバーを調べる手順は、記事のために実機で試した結果ではありません。使う前に、安全な環境で試してください
• 読んだ資料に、実際に悪用された確認の記載はありませんでした。今後の資料で変わる可能性があります

公式資料

• PHP.net News Archive 2026（セキュリティ告知） 2026年10月23日に読みました
• GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp 2026年10月23日に読みました
• PHP Supported Versions 2026年10月23日に読みました
• JPCERT/CC 注意喚起 JPCERT-AT-2026-0033 2026年10月22日公開、2026年10月23日に読みました
• IPA PHPの脆弱性対策について 2026年10月22日公開、2026年10月23日に読みました
• さくらインターネット PHPの脆弱性に関する当社の対応状況について 2026年10月23日17時30分の追記を読みました
• エックスサーバー お知らせ 2026年10月23日13時15分の追記と16時20分時点の表を読みました
• WordPress.org Critical PHP Security Release 2026年10月23日に読みました
• Claude Code 権限モード 2026年10月23日に読みました

よくある質問

PHP 8.1以前は、今回の脆弱性の対象外ですか？

対象外とは言えません。アドバイザリの表に載っていないのは、8.1以前が開発元の更新を受けられない版だからです。開発元は7.4、8.0、8.1向けに最小限のバックポートをソースで出し、IPAは、Wizの調査として5.4以降の版が少なくとも一方の影響を受けるとしています。サーバー会社やOSの提供元が修正を出しているかを確かめてください。

修正版より古い版の数字が出ているのに、サーバー会社が「対応済み」と言っています。信じてよいですか？

エックスサーバーは、PHP 5.6から8.1の版の表示を変えずに修正を当てたと案内しています。このように、版の数字が変わらないまま修正が入る場合があります。自分が使っているサーバー会社の最新のお知らせで、使っているプランと版が対象に入っているかを確かめてください。

自分のPHPのバージョンは、どこで分かりますか？

レンタルサーバーなら管理パネルのPHPの設定、WordPressなら管理画面のツール、サイトヘルス、情報、サーバーで分かります。VPSならphp -vが使えますが、Webサイトを動かすPHPと別の版のこともあります。phpinfo()は情報が多いので、管理者だけが見られる場所で一度確かめ、すぐに消します。

WordPressを更新すれば、この脆弱性は直りますか？

直りません。WordPress.orgは、この脆弱性はWordPress固有ではなく、WordPressの更新は必要とされておらず、予定もないと書いています。直すのはサーバー側のPHPです。

PHPを更新できない場合は、どうすればよいですか？

更新が完全な対策です。php.netが挙げる設定の変更は、特定の攻撃の道筋を減らすだけです。IPAは、暫定の対策が難しいときは、外部からのアクセスの遮断やサービスの一時停止が必要かを判断し、保守を受けられるサービスへの移行も検討するよう案内しています。