【緊急】PHPの重大脆弱性2件(CVE-2026-109618 / 109619)を安全にアップデートする方法

Last updated at 2026-10-22Posted at 2026-10-21

はじめに

2026年10月21日(日本時間の夜)、PHP公式から 認証なしでリモートコード実行(RCE)が可能になる重大な脆弱性2件 の修正版がリリースされました。通称「PHP2Shell」と呼ばれています。

脆弱性のCVE番号が10月20日に事前流出したため、PHP開発チームは当初の公開予定(10月22日)を 1日前倒し して、10月21日 14:00 UTC(日本時間23時)の公開を告知しました。実際の修正版は 日本時間22時半〜23時頃 に公開されています(情報源により数分〜30分ほど差があります)。

この記事では、次の内容を初心者向けにまとめます。

何が起きたのか(時系列)
今回の脆弱性は何が問題なのか
自分の環境が対象かどうかの確認方法
安全にアップデートする手順(バックアップ・確認・切り戻しまで)
すぐに更新できない場合の一時的な対策
更新後に「すでに侵入されていないか」を確認する観点(10月17日以降のログ が対象です)

この記事は 2026年10月22日 19:30時点 の情報です。この記事は今後更新しません。 状況は刻々と変わっているため、最終的には必ず PHP公式サイトや、各ディストリビューション・ホスティング事業者の最新情報を確認してください。

更新履歴

2026/10/21:初版
2026/10/22:実際の攻撃の試みが観測されている 旨を反映。リリース時刻の訂正、国家サイバー統括室の注意喚起、公開PoCに関する注意、検知の観点、更新できない場合の隔離対応を追記
2026/10/22 14:45:Amazon Threat Intelligenceが10/17(公開の4日前)に攻撃の試みを観測し、現在は広範に悪用されていると発表した 点を反映し、調査対象期間を「10/17以降」に修正。時系列の誤りを訂正(事前告知は流出後、リリース時刻は22時半〜23時頃)。悪用状況の表、WAF/IPS対応状況、IOC、WordPress向けの注意を追記。未確認だった情報源と参考リンクを整理
2026/10/22 19:30:最終更新。 Cloudflareが「試行が公表後に数百万件へ急増した」と報告した点、JPCERT/CC・IPAの注意喚起、Censysによる未更新ホスト数の推計、Amazon Linuxの修正状況、ニコニコ・pixivの公式告知、CISA KEVの掲載状況(未掲載)を反映

結論(先に読みたい人向け)

修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
2件とも CVSS v4.0で9.2(Critical)。認証なしのリモートコード実行につながる可能性がある
PHPをWebで動かしているサーバーは全て対象(PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed)
すでに攻撃が出ている。 Amazonは公開の4日前(10/17)の試行を観測し、リリース後は広範に悪用されていると発表した。Cloudflareは、試行が公表後に数百万件まで急増したと報告している。「様子を見る」段階ではない
設定変更だけでは完全には防げない。アップデートが唯一の確実な対策
アップデート後は PHPのプロセス(php-fpm / Apache)の再起動を忘れずに
更新が済んでも終わりではない。10月17日以降のログと不審な挙動を確認する
8.1以前は公式の修正版がない。サポート中のバージョンへの移行が必要

何が起きたのか(時系列)

日時(日本時間)	出来事
2026年10月17日	Amazon Threat Intelligenceが、自社のハニーポット(MadPot)でこの脆弱性を狙った攻撃の試みを初観測(公開の4日前。攻撃者がどうやって情報を得たかは不明)
2026年10月20日	CVE-2026-109618 / 109619 の番号が Hacker News や SNS に事前流出(当初の公開予定は10月22日だった)
2026年10月21日 4時半頃	PHP開発チームが事前告知を公開。リリースを1日前倒しして10月21日 14:00 UTC(日本時間23時)にすると発表。流出などがあれば更に早める可能性にも言及
2026年10月21日 12時頃	Cloudflareが、既知の攻撃経路向けのWAFルールを全プラン(無料含む)に配備。「初期の攻撃が出始めている」と発表
2026年10月21日 22時半〜23時頃	PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 とセキュリティアドバイザリが公開される
2026年10月21日夜	国内の各社が緊急メンテナンスに入る。さくらインターネットは23時から作業開始。BASE/PAY IDやコドモンは安全確保のため緊急停止、ニコニコは19時から順次メンテナンス入り(公式告知で、理由は「利用しているソフトウェア(PHP)の重大な脆弱性」)。pixivも19時から停止予定と告知
2026年10月22日	pixivは02時ごろにトップページの表示を確認(正式な再開告知は未確認)。ニコニコは15:30に動画・チャンネル・プレミアム・ポイントなどが復旧。ニコニコ静画・コモンズなどは作業継続中(ニコニコ公式告知)
2026年10月21日	IPAが事前準備を呼びかける注意喚起を公開。国家サイバー統括室も、X(旧Twitter)で更新プログラムの速やかな適用を呼びかけ(JAPANSecuritySummit Updateの報道で確認。一次情報のURLは確認できていません)
2026年10月22日 6時半〜6時45分	さくらインターネットが緊急のPHPバージョンアップ作業の完了を告知。Xserverも対象サーバーへの修正パッチ適用完了を告知
2026年10月22日 10時25分頃	CloudflareのCEOが、同社ネットワーク全体での試行件数を報告。公表前の10時間は数千件、公表後45分で数万件、2時間以内に数十万件、その後数百万件に急増
2026年10月22日 13時11分	JPCERT/CCが注意喚起を公開。対策の適用とあわせて、侵害の有無を調べるよう呼びかけ(IPAも注意喚起を公開)

公開前に告知されたことで、大規模サービスは「公開と同時に更新する」準備ができていました。個人や小規模チームの環境も、今日のうちに対応する つもりで動くのが安全です。

今回の脆弱性の概要

項目	CVE-2026-109618	CVE-2026-109619
公式の呼称	RCE via OOM corruption	RCE via stale global state
種類	メモリ不足(OOM)時の状態破壊によるRCE	古い(解放済み)グローバル状態の残存によるRCE
深刻度	CVSS v4.0 9.2(Critical)	CVSS v4.0 9.2(Critical)
攻撃に認証は必要か	不要	不要
公式アドバイザリ	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp

何が問題なのか(やさしい解説)

CVE-2026-109618(OOM corruption)
PHPがリクエストを処理している途中でメモリ不足になると、内部のリクエストデータが「中途半端に初期化された状態」のまま処理が中断されることがあります。その後のクリーンアップ処理が、その不完全なデータを「正常なもの」として扱ってしまい、メモリ破壊につながります。

CVE-2026-109619(stale global state)
1つのリクエストで使ったPHP内部の状態が、裏のメモリを解放した後も残ってしまうことがあります。同じワーカー(PHPの処理プロセス)が次のリクエストを処理するとき、通常の初期化でリセットされる前に その古い状態を使ってしまう 問題です。PHP公式は、メモリ内の情報が漏れる(メモリ露出)ことも確認しています。

どちらも「PHPの内部状態が壊れる、または古いまま使われる」ことが原因で、細工したリクエストを送ることでコード実行に持ち込める可能性があります。

ポイントは、自分が書いたアプリケーションのバグではなく、PHP本体の問題 だということです。コードをどれだけ丁寧に書いていても、PHPを更新しない限り影響を受けます。WordPressなどのプラグインを最新にしても、この問題は直りません。

なぜ今すぐ更新すべきか

PHP公式は、特に mod_php 環境でリスクが高い としています。実証された攻撃では、アプリケーションのコードが動く前の段階で、認証なしのリクエストから攻撃が成立するとのことです。
公式は「完全な緩和策はなく、更新が唯一の安全な選択」と明言しています。
すでに攻撃が観測されています(次節)。公開の4日前から試行があったため、「公開日以降に更新すれば間に合う」とは言い切れません。
技術的な解説(Calif)や、WordPress / Drupal / Joomla に対する認証なしRCEのデモ(Wiz)が公開されており、攻撃のハードルは下がっています。
Amazonは、AIの支援によって「パッチや公開情報から攻撃コードを作るまでの時間」が縮んでおり、重要なインターネット公開システムの対応は「日」ではなく「時間」で考えるべきだとしています。
未更新のサーバーが非常に多く残っています。Censysの集計では、10/21時点でバージョンが判別できたPHPホスト約158万台のうち、約157万台が未更新でした(バージョン表示に基づく推定で、実際に攻撃可能な台数とは限りません)。

悪用状況(2026年10月22日時点)

情報源によって観測時点や表現が異なるため、確度の違いが分かるように整理します。

情報源	内容
Amazon Threat Intelligence(AWS Security Blog、10/21)	MadPotで 10/17に攻撃の試行を観測(公開の4日前)。10/21 02:00〜08:00 UTCにも、複数の攻撃者によるとみられる試行を観測。リリース後はPoCが数時間で出回り、「広範に悪用されている」と発表。ただし、実環境で成功したかは不明としている
watchTowr	自社のハニーポットで、両脆弱性への悪用の試みを観測
Cloudflare	10/21時点で「初期の攻撃が出始めている」と発表。攻撃者が検知を避けるためにペイロードを変化させているとも説明
Palo Alto Networks Unit 42	野外での悪用を観測したと公表(報道ベース)
Huntress	10/21 16:30(米東部時間)時点で、自社が管理する環境では悪用を未確認。ただし、他社が攻撃を報告していることは認めている
CISA	10/21のアラートで、公開時点では悪用を観測していないと説明。KEV(悪用が確認された脆弱性カタログ)には、10/22 00:33 UTC時点(watchTowrの表示)で未掲載。CISAのサイトは直接取得できず、その後の変化は未確認です
IPA	10/21付の事前注意喚起の時点では、悪用を確認していないとしている

要するに、一部の情報源は「悪用なし」と書いていますが、それは観測した範囲での話 です。Amazonが公開前の試行を確認している以上、「攻撃の試みは実際に出ており、すでに成功している環境があってもおかしくない」と考えて動くのが安全です。

公開PoC(検証コード)について
GitHubなどに「PoC」を名乗るリポジトリが出回っています。Sophosは「PoCが公開された」と報告している一方、PHPセキュリティチームは、リリース時点で調べた範囲では 動作する公開エクスプロイトは確認できなかった としており、Tenableも「動作は未検証」としています。出所不明の攻撃コードには マルウェアが仕込まれていることがある ため、興味本位で自分の環境で実行しないでください。

自分の環境は対象か?

次のどれかに当てはまれば、基本的に対象です。

PHPでWebサイト・Webアプリ・APIを動かしている(WordPress、Laravel、EC-CUBEなど各種フレームワークやCMSも含む)
動かし方が PHP-FPM / Apache の mod_php / php-cgi / FrankenPHP / LiteSpeed のいずれか
レンタルサーバーやマネージドサービスで、PHPのバージョンを自分で選んでいる
製品やWindowsソフトに同梱されたPHP、コントロールパネル、社内の管理ツールなど(見落としやすいので棚卸しが必要)

WordPress利用者へ:WordPress本体やプラグインを最新版にしても、今回のPHP本体の脆弱性は直りません。PHPの更新は、サーバーの運用者かホスティング事業者が行います。PHP 7.4や8.1など公式の修正版が出ない系列を使っている場合は、サポート中の系列(8.3以上が無難)への移行が必要です。移行前にはバックアップを取り、テーマやプラグインの互換性を確認してください。

レンタルサーバー・マネージドサービスの場合

自分でパッケージを更新できない環境では、次を確認してください。

事業者のお知らせページに、今回の件への対応状況が出ていないか
管理画面でPHPバージョンを選べる場合、修正版が選択肢に出ているか
事業者側で自動更新される場合も、いつ反映されるか を確認する
「メンテナンス実施の予告」と「全顧客への適用完了」は別の話です。完了の告知と、実際に動いているPHPバージョンの両方を確認してください

対象バージョンと修正版

ブランチ	修正版	備考
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	2026年12月31日でサポート終了予定
PHP 7.4〜8.1	公式の修正版なし	PHPチームがソースのバックポート(最小限の修正) のみ提供。下記参照
PHP 5.4〜7.3	修正なし	サポート終了。移行が必要

修正版のソースは PHP公式のダウンロードページで公開されています。

PHP 8.1以前を使っている場合

PHP 8.1以前はPHPプロジェクトとしてのサポートが終了しており、公式の修正版は出ません。対応は次のいずれかです。

サポート中のバージョン(8.3以上が無難)へ移行する(推奨)
ディストリビューションやLTSベンダーがバックポートした修正パッケージを使う(ベンダーに確認)
公式が提供している最小限のソースバックポート(PHP 7.4 / 8.0 / 8.1向け)を使って自分でビルドする

移行や修正の適用が間に合わない場合は、インターネットからの到達を止める(VPN・IP制限の背後に置く、一時停止する)ことを優先してください。

8.2は2026年末でサポートが終わります。今回の更新と合わせて、8.3以上への移行計画 も立てておくのがおすすめです。

アップデート前の準備

ステップ1:今のPHPのバージョンと動かし方を確認する

# バージョン確認
php -v

# どのSAPI(動かし方)で使っているか確認
php -i | grep -i "server api"

# PHP-FPMの場合
php-fpm -v          # コマンド名は環境により php-fpm8.3 など

# Apache(mod_php)の場合
apachectl -M | grep php

見るポイントは次の2つです。

バージョンが修正版より古いか(例:8.3.35以下なら対象)
PHP-FPM / mod_php / その他のどれで動いているか(再起動するサービスが変わります)

Ubuntu / Debian / RHEL系などのディストリビューションのパッケージは、バージョン番号を上げずに修正だけ取り込む(バックポート) ことがあります。php -v の数字が8.3.36になっていなくても、修正済みの場合があります。後述の「修正が入っているか確認する方法」を参照してください。

ステップ2:バックアップを取る

更新前に、最低限次のものを保存しておきます。

# 設定ファイル(場所は環境により異なります)
sudo cp -a /etc/php /etc/php.bak-$(date +%Y%m%d)

# インストール済みパッケージの一覧を記録(切り戻し用)
# Debian / Ubuntu
dpkg -l | grep -i php > ~/php-packages-before.txt
# RHEL / Amazon Linux など
rpm -qa | grep -i php > ~/php-packages-before.txt

あわせて、次も確認しておくと安心です。

Webアプリのソースコード(Gitで管理していればコミット済みか確認)
データベースのバックアップ
クラウド(AWSなど)の場合は、スナップショットやAMIの取得

ステップ3:可能ならステージング環境で先に試す

本番と同じ構成のテスト環境があれば、先にそこで更新して動作確認します。同じ8.x系内の更新(例:8.3.35→8.3.36)は互換性が保たれているので、大きな問題は起きにくいですが、確認する習慣をつけておくと安全です。

今回は緊急性が高く、すでに攻撃も出ているため、ステージングでの確認に時間をかけすぎないことも大切です。「主要機能だけ短時間で確認 → 本番へ」という進め方でも構いません。

アップデート手順

方法A:Linux(パッケージマネージャーを使う場合)

ディストリビューション側の修正パッケージの公開タイミングはそれぞれ異なります。まず更新が出ているか確認してから 実行してください。

Ubuntu / Debian

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php   # 更新候補を確認

# PHP関連パッケージだけ更新する(全体の apt upgrade を避けたい場合)
sudo apt install --only-upgrade 'php*'

RHEL / Rocky / AlmaLinux / Amazon Linux

# コマンドは dnf(古い環境では yum)
sudo dnf check-update | grep -i php
sudo dnf upgrade 'php*'

Amazon Linuxの修正状況(Amazon Linux Security Center、10/22時点)

AL2023は php8.2〜php8.5 が修正済みです(ALAS2023-2026-3301〜3304、10/22公開)。
AL2は Php8.2 Extra のみ修正済みです(ALAS2PHP8.2-2026-015)。
AL2標準の php(Core)とAL2023の php8.1 は「修正予定なし」 です。該当する場合は、対応バージョンへの移行が必要です。
修正版の具体的なパッケージバージョンは、確認したページに記載がありませんでした。
AWSのセキュリティ情報では、Elastic BeanstalkのPHPプラットフォームは10/22にアップストリーム修正版が出る予定、Lightsailは稼働中のインスタンスをその場で更新できず、更新済みブループリントから新規作成して移行する必要があるとされています。

rpms.remirepo.net(Remiリポジトリ)は、公式から「当日は更新が提供されない」と案内されています。Remiを使っている場合は、ディストリビューション標準のパッケージに切り替えるか、ソースからビルドする ことをPHP公式は勧めています。

方法B:Docker(公式イメージを使っている場合)

# 修正版のタグが公開されているか確認してから
docker pull php:8.4-fpm            # 使っているタグに合わせて変更

# キャッシュを使わずにイメージを再ビルド
docker build --no-cache -t myapp:latest .

# 中身のバージョンを確認
docker run --rm myapp:latest php -v

ポイントは次のとおりです。

ベースイメージのタグが更新されていないと、再ビルドしても古いPHPのまま です。Docker Hubで修正版(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35)が出ているか確認してください。
イメージを更新したら、コンテナを入れ替える(再デプロイする)ところまで が作業です。ECSやKubernetesなら、新しいイメージでデプロイし直します。

方法C:Windows

PHP公式のダウンロードページから修正版のバイナリを取得して入れ替えます。入れ替え前に、現在のPHPフォルダと php.ini を必ずコピーして保管してください。

方法D:ソースからビルドする場合

公式のダウンロードページから修正版のソースを取得し、今までと同じ configure オプションでビルドします。以前のオプションは次のコマンドで確認できます。

php -i | grep -i "Configure Command"

アップデート後に必ずやること

ステップ4:PHPのプロセスを再起動する(重要)

パッケージを更新しただけでは、すでに動いているPHPのプロセスは古いまま の場合があります。必ず再起動(またはリロード)してください。

# PHP-FPMの場合(サービス名は環境により異なります)
sudo systemctl restart php8.3-fpm     # Debian / Ubuntu の例
sudo systemctl restart php-fpm        # RHEL系の例

# Apache(mod_php)の場合
sudo systemctl restart apache2        # Debian / Ubuntu
sudo systemctl restart httpd          # RHEL系

restart は一瞬接続が切れます。止められないサービスでは、事前に利用者が少ない時間帯を選ぶか、ロードバランサーから切り離して1台ずつ更新(ローリング更新)してください。大手サービスがメンテナンス入りしたのも、この「止めて入れ替える」作業のためです。

ステップ5:更新できたことを確認する

php -v
php-fpm -v    # PHP-FPMを使っている場合

Webサーバー経由で動いているPHPの情報も確認します。確認用ファイルは 確認後すぐ削除 してください。公開したままにすると、環境情報が外部に漏れます。

<?php phpinfo();

修正が入っているか確認する方法(バックポート対策)

バージョン番号が変わらないディストリビューションでは、変更履歴で今回のCVE番号を確認します。

# Debian / Ubuntu
apt changelog php8.3-cli | grep -i "CVE-2026-109618"

# RHEL / Amazon Linux など
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

何も表示されない場合は、まだ修正が入っていない可能性があります。CVE-2026-109619 についても同様に確認してください。

ステップ6:アプリケーションの動作確認

トップページ、ログイン、フォーム送信、ファイルアップロードなど 主要な機能を一通り触る
PHPのエラーログ、Webサーバーのエラーログを確認する
監視ツールがあれば、エラー率やレスポンスタイムに異常がないか見る

# ログの場所は環境により異なります
sudo tail -n 100 /var/log/php8.3-fpm.log
sudo tail -n 100 /var/log/nginx/error.log

問題が出たときの切り戻し

動作に問題が出た場合は、慌てず次の順番で対応します。

エラーの内容を確認する(ログを見る)
設定ファイルの差分が原因なら、バックアップから戻す

   sudo cp -a /etc/php.bak-YYYYMMDD/. /etc/php/

パッケージを旧バージョンに戻す(Debian / Ubuntuの例)

   sudo apt install php8.3-cli=<旧バージョン> php8.3-fpm=<旧バージョン>

クラウドならスナップショットやAMIから復元する

切り戻すと脆弱性のある状態に戻ります。 一時的な避難措置と考え、原因を調べて早めに再度アップデートしてください。切り戻している間は、下記の暫定対策に加えて、インターネットからの到達を制限する(VPNやIP制限の背後に置く)ことを検討してください。

すぐに更新できない場合の暫定対策

公式が示している対策です。いずれも 攻撃経路の一部をふさぐだけで、安全にはなりません。あくまで更新までの時間稼ぎとして使ってください。

まず検討すべきこと:露出を減らす

更新できないサーバーは、次のいずれかで インターネットからの到達を減らす ことが現実的です(CERT-EUも、更新できない場合はインターネット公開アプリケーションを公衆網から隔離するよう推奨しています)。

一時的にサービスを止める、またはメンテナンス表示にする
VPNやIPアドレス制限の背後に置く
WAF/IPSで保護する(下記参照。ただし 補助であり、PHPの更新の代わりにはなりません)
更新できない環境で、ファイルアップロード(multipart/form-data)が不要なら遮断を検討する(Amazonも推奨。アプリへの影響を確認してから実施してください)

WAF/IPSの対応状況(補助策)

次の製品が、今回向けの防御ルールを公開しています。契約プランや設定によって実際の保護範囲は異なり、どれもPHP本体の修正を代替しません。

製品	内容
Cloudflare WAF	既知の攻撃経路向けルールを、無料プランを含む全プランに配備。Cloudflare自身も「一時しのぎ」と説明
Palo Alto Networks	Threat Preventionシグネチャを提供
Akamai App & API Protector	CVEを明記した検知ルールを提供
Check Point	IPS保護(CPAI-2026-15172)を提供

CVE-2026-109618(OOM)向け

memory_limit=-1 に設定する(アプリ側で上書きされない php_admin_value などで設定)
post_max_size を小さくする(ファイルアップロードが不要なら 8M、必要でも 32M 程度。upload_max_filesize はそれより小さく)
Webサーバーやプロキシ側でも、リクエストサイズやフィールド数、ヘッダー数などを制限する
コンテナやcgroupのメモリ制限を使い、異常なワーカーだけを停止できるようにする
- RLIMIT_AS / RLIMIT_DATA での代用は しない こと(問題の確保失敗を引き起こす可能性があるため)

memory_limit=-1 は、PHPがメモリを無制限に使えるという意味です。暴走した処理でサーバー全体のメモリが枯渇するおそれがあります。更新までの短期間だけ にしてください。

CVE-2026-109619(stale state)向け

session.upload_progress.enabled=0 に設定し、全ワーカーを再起動する(php.ini やFPMプール設定など、リクエスト解析前に適用される場所で設定。ini_set() や .user.ini には頼らない)
PHP 8.5では fatal_error_backtraces=0 に設定し、全ワーカーを再起動する
起動前に警告を出すような、不正または非推奨の設定を取り除く
外部から到達できる致命的エラーや実行タイムアウトを減らす

session.upload_progress.enabled=0 は、確認されている攻撃経路の一部をふさぐだけで、CVE-2026-109618には効きません。公式の修正版が出ないPHP 5〜8.1でも、Huntressは最低限の対策として session.upload_progress.enabled = Off を勧めています(その場合も再起動が必要で、移行や公開範囲の制限と併用してください)。

更新後に確認したいこと:すでに侵入されていないか

今回は 公開前から攻撃の試みが確認されている ため、未更新だった期間に狙われた可能性を否定できません。更新が済んだら、念のため次を確認しておくと安心です。

調べる期間は「10月17日以降」

Amazonは「公開日を、悪用が始まった最も早い日と考えてはいけない。今回は少なくとも10月17日から調査を始めるべき」としています。ログの保存期間が短い場合は、更新前に今あるログを退避しておく ことをおすすめします。

確認する観点

以下は、Amazon、Huntress、Wizなどの発表と、一般的なインシデント対応の観点をまとめたものです。

PHPのワーカープロセス(php-fpm、php-cgi、httpd、apache2など)から、シェルやインタプリタ、ダウンロードツールが起動していないか(Huntressが監視ポイントとして挙げています)
アクセスログ・エラーログに、普段と違う大量のリクエストや異常終了(メモリ不足、タイムアウト、500エラーの連続)がないか
POSTのフォーム送信に PHP_SESSION_UPLOAD_PROGRESS という文字列が含まれていないか(Amazonが挙げている観点。通常のアクセスログにはPOSTの中身が残らないので、WAFやリバースプロキシのボディログがある場合に確認します)
Webの公開ディレクトリに、身に覚えのないPHPファイルが増えていないか(更新日時が新しいファイルを確認)
見慣れないプロセスや外部への通信、cronの追加、新規アカウントがないか
万一不審な点があれば、サーバーの隔離、Webサーバーとphpのログの保全、パスワード・APIキー・DB接続情報の変更、スナップショットからの復旧 を検討する

# 例:直近7日以内に更新されたPHPファイルを探す(公開ディレクトリのパスは環境に合わせる)
find /var/www -name "*.php" -mtime -7 -type f

Amazonが公表したIOC(攻撃元IPアドレス)

IPアドレス	観測日
103.216.220.92	2026/10/17
31.223.184.166	2026/10/21
37.19.200.5	2026/10/21
134.209.159.64	2026/10/21
103.114.163.188	2026/10/21
95.217.98.37	2026/10/21

これらは匿名化ネットワークなどの共有インフラで、今回の攻撃専用ではありません。Amazonも、ブロックするのではなく、ログにこれらのIPからのアクセスがなかったかを調べる 使い方を勧めています。「ログにない=安全」とは限らない点にも注意してください。

今回の問題には、メモリ上の情報が外部に漏れる経路があり、パスワード、トークン、APIキーなどが露出しうる と報告されています。侵害の疑いがある場合は、サーバーを直すだけでなく、そこに置かれていた認証情報の入れ替え まで行ってください。

不審な点が見つかった場合は、自分だけで抱え込まず、社内のセキュリティ担当やホスティング事業者に相談してください。

よくある疑問

Q. 自分のサイトは小規模だけど、狙われますか?
A. 認証不要の脆弱性は、特定のサイトではなく インターネット上のPHPサーバーを広く探して自動で攻撃される 傾向があります。規模は関係なく、対象になりえます。今回はすでに攻撃が観測されています。

Q. WAFを入れていれば更新しなくてもいいですか?
A. いいえ。公式は「完全な緩和策はない」としています。WAFは更新までの補助と考えてください。CloudflareのWAFも、経由した通信にしか効きません。

Q. WordPressのプラグインやテーマを最新にすれば大丈夫ですか?
A. いいえ。PHP本体の問題なので、WordPressやプラグインの更新では直りません。サーバーのPHPを更新する必要があります。

Q. php -v が古いままなのですが、更新できていませんか?
A. ディストリビューションによっては、バージョン番号が変わらず修正だけ入っています。changelogでCVE番号を確認してください。また、再起動していないだけの可能性もあります。

Q. 8.2を使っていますが、更新後も安心ですか?
A. 今回の修正版(8.2.35)で対応できますが、サポートは2026年末までです。早めに8.3以上へ移行する計画を立ててください。

Q. ネットで見つけたPoCで、自分の環境が脆弱か試してもいいですか?
A. おすすめしません。出所不明のコードにはマルウェアが含まれていることがあります。バージョンとchangelogの確認で十分判断できます。

Q. 「悪用は確認されていない」という記事を見ました。急がなくていいですか?
A. その記事の観測範囲や時点に限った話です。Amazon、watchTowr、Cloudflare、Unit 42などは攻撃を観測したと発表しており、Amazonは公開の4日前の試行も確認しています。急ぐべき状況です。

更新後のチェックリスト

php -v で修正版になっている(またはchangelogにCVE対応が記載されている)
PHP-FPM / Apacheを再起動した
主要機能の動作確認をした
エラーログに新しい異常がない
phpinfo() の確認用ファイルを削除した
暫定対策を入れていた場合は、設定を元に戻した(特に memory_limit=-1)
複数台構成なら全台を更新した(開発・検証用サーバー、製品同梱のPHPも含む)
10月17日以降のログ と、不審なファイル・プロセスがないか確認した
侵害の疑いがある場合は、認証情報を入れ替えた
8.1以前や8.2を使っている環境の移行計画を立てた

まとめ

今回の2件は、認証なしでコード実行につながりうる 重大な脆弱性
修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
公開の4日前(10/17)から攻撃の試みが確認され、現在は広範に悪用されている との報告もある
手順は「確認 → バックアップ → 更新 → 再起動 → 動作確認」
更新後の 再起動 と、ディストリビューションごとの パッケージ反映状況の確認 を忘れない
暫定対策やWAFは完全ではないので、更新までのつなぎとして使い、更新できない間は露出を減らす
更新後は、10月17日以降のログ、不審なファイル、プロセスがないかも確認しておく
8.1以前や8.2は、この機会に新しいバージョンへの移行を検討する

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up