2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@TaichiEndoh(遠藤 太一)

【10/21 23:00 公開】PHP緊急セキュリティリリース（CVSS 9.2 × 2件）― 一次情報の整理と、公開前後の運用ランブック

2
Posted at

対象読者： PHPで動くサービスを運用しているエンジニア／病院・研究機関・中小企業でWebサーバーを「なんとなく引き継いで」管理している人
読了時間： 約15分

※2026年10月21日 21:30 JST時点の公開情報にもとづく筆者の整理です。修正版は 2026-10-21 14:00 UTC（23:00 JST） に公開予定。影響バージョン・修正版は公開と同時に発表されるため、本記事の「公開後」セクションは23時以降に追記します。脆弱性の技術的な仕組み・攻撃手順には触れません。

TL;DR

  • PHPセキュリティチームが10/20に「CVSS v4.0 9.2の脆弱性2件を10/21 14:00 UTCに修正する」と事前告知。公式が言っているのはこれだけ
  • CVE-2026-109618 / 109619 はNVD・MITREで reserved。「PHP 5以降すべて」「認証なしRCE」はCERT-EUの注意喚起（外部情報ベース）であり、本家は未確認
  • エンバーゴ前に情報が漏れ、研究者が再現動画を公開。日本ではコドモン・pictSQUARE・BASE・さくら等が予防停止
  • 8.1以前はEOL。上流の修正は8.2〜8.5のみの見込み（研究者発言・二次情報）。ディストリのバックポートを待つか、移行か、切り離し
  • 公開前にやること：インベントリ → バージョン確認 → バックアップ → 更新手順のスクリプト化 → 監視強化
  • 公開後にやること：php.netとphp-srcのGitHub advisoryだけを信じて更新 → 検証 → 空白期間の侵害痕跡確認

1. 一次情報の到達状況（正直に書く）

情報源 状態 備考
php.net アーカイブ「Upcoming Critical PHP Security Release」（10/20） ✅ 全文確認 本記事の唯一の「本家の発言」
php-src GitHub Security Advisories ❌ 未公開 23時以降に出る見込み
NVD / MITRE CVE-2026-109618, 109619 ⚠️ reserved 番号のみ確保。説明文なし
CERT-EU 注意喚起 ⚠️ 原文未取得 複数の二次情報が引用
IPA 注意喚起（10/21） ⚠️ 原文未取得 URLは出典欄
JPCERT/CC ❓ 未確認 出ているか自体を確認できず
CISA KEV ✅ 未掲載（watchTowr FAQ経由） in-the-wild悪用は21時時点で未確認

この記事の「確定情報」は、実質php.netの告知1本です。 以降、それ以外の情報には出所を付けます。

2. PHP公式の告知（原文）

The PHP security team would like to give advance notice of an upcoming security release.
It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC.
It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.
All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.
We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
Full details, affected versions, and the fixed versions will be published with the release.

公式が言っていないことを明示しておきます。

  • CVE番号（watchTowrが先に公表。本家の告知には出てこない）
  • 影響バージョン
  • 脆弱性の種類（RCEとは書いていない）
  • 修正版の番号
  • 影響を受けるコンポーネント・設定

SNSで流れている「仕組み」「15分で攻撃」「8.3以上は安全」「PHP 5以降すべて」は、全部この外側です。

3. 二次情報の整理（出所つき）

3.1 CERT-EU（EU機関のCERT）

  • CVE-2026-109618 / 109619 を提示
  • スコアから「認証なしのRCEの可能性」
  • 「外部情報によれば PHP 5以降のすべてのバージョンが影響を受ける懸念」
  • 推奨：PHPアプリの洗い出し／即時適用の準備／適用できないものはインターネットから切り離す

3.2 エンバーゴ崩壊の経緯（Cyber Kendra・GIGAZINE）

  • 10/20 15:20 UTC：Hacker Newsに「信頼できる筋から2件のRCEが出ると聞いた」投稿（投稿者自身が根拠なしと明記）。スクショが拡散
  • watchTowrが「本物のゼロデイRCE」と確認し、CVE番号を公表。本来のエンバーゴは10/22 11:00 ET → PHPチームが10/21に前倒し
  • 研究者がWordPress/Drupal/Magentoのテスト環境での再現動画をXに投稿（通称「php2shell」はここから）
  • watchTowr：CVE-2026-109618の再現に成功、詳細は非公開。in-the-wild悪用は未確認、KEV未掲載、公開前のワークアラウンドなし

3.3 PoC流出の有無（食い違いあり）

  • watchTowr / Cyber Kendra：技術的詳細は非公開、PoCは出ていない
  • SecureLayer7：「PoCが出回っているとの報告あり」
  • pictSQUARE：「悪用する方法が公開されたとの情報もあります」（断定なし）

→ 「確認されていない」が現時点の正確な表現。 ただし再現に成功した組織が複数ある以上、「穴の場所を知っている人が複数いる」は確定。

3.4 バージョン・修正範囲（未確定）

  • Florian Roth氏：「修正はPHP 8のみ。5・7はEOLで修正なし」
  • Phoenix Security：上流修正は8.2〜8.5のみの見込み。8.0/8.1も修正なしの見込み。修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 と噂されているが未確認
  • PHP公式のサポート表：8.4/8.5 = Active、8.2/8.3 = Security fixes only、8.1以前 = EOL

3.5 公開サーバーの露出（Phoenix Security・単一ソース・目安）

  • X-Powered-By: PHP を返すホスト 約223万、うちバージョン開示 約150万
  • バージョン開示ホストのうち修正が来ない系統（5.x/7.x/8.0/8.1）が約88万（59%）
  • 国別の「修正が来ない」ホスト：米国 約22.9万、中国、日本 約5.5万、ドイツ 約4.6万
  • 同社自身が「directional（方向性の目安）」と注記

4. 公開前ランブック（〜23:00 JST）

4.1 インベントリ：PHPで動いているものを全部出す

「忘れていた1台」が一番危ない。本番だけでなく、以下も含める。

  • ステージング・検証環境・古いキャンペーンサイト・採用サイト
  • CMS（WordPress / Drupal / Joomla / EC-CUBE / MediaWiki / Moodle / LimeSurvey / Nextcloud / phpMyAdmin / Matomo / Redmine の一部構成）
  • コンテナイメージ（php:*、wordpress:*、自前ビルド）
  • CIランナー・ビルドイメージ
  • 「院生が昔作った受付システム」「誰が作ったか分からないWiki」
# ホスト上のPHPバイナリ・FPMを洗い出す（例）
which -a php php-fpm php8.3 php8.2 php7.4 2>/dev/null
ls /usr/bin/php* /usr/sbin/php-fpm* /usr/local/bin/php* 2>/dev/null

# パッケージ管理経由のPHP（Debian/Ubuntu）
dpkg -l | grep -E '^ii\s+php'

# RHEL系
rpm -qa | grep -E '^php'

# Dockerイメージ
docker images --format '{{.Repository}}:{{.Tag}}' | grep -Ei 'php|wordpress|drupal|laravel|nextcloud'

# 稼働中コンテナの中のPHP
for c in $(docker ps -q); do echo "== $c"; docker exec "$c" php -v 2>/dev/null | head -1; done

4.2 バージョン確認

php -v
php-fpm -v 2>/dev/null
# Webから見える版数（公開サーバーはこれを消すことも検討）
curl -sI https://example.com/ | grep -i x-powered-by

レンタルサーバー（さくら・エックスサーバー・ロリポップ・ConoHa等）は管理画面の「PHP設定」「PHPバージョン切替」を確認。事業者が新版を用意しても、切替ボタンを押すのは利用者側であることが多い。

4.3 分類

稼働バージョン 23時以降の方針
8.4 / 8.5 上流の修正版に更新
8.2 / 8.3 上流の修正版に更新（security fixes only だが対象の見込み）
8.0 / 8.1 上流修正なしの見込み → ディストリのバックポート待ち／8.2+へ移行／切り離し
5.x / 7.x 上流修正なし → 移行／切り離し／停止。誰も使っていないなら今夜止める

4.4 バックアップとロールバック手順

# 設定・webroot・DBのスナップショット（例）
tar czf /backup/php-etc-$(date +%F).tgz /etc/php* /etc/php-fpm* 2>/dev/null
tar czf /backup/webroot-$(date +%F).tgz /var/www
mysqldump --all-databases --single-transaction > /backup/db-$(date +%F).sql

VM/クラウドならスナップショットを取る。更新で動かなくなった時に戻せることを確認しておく。

4.5 更新手順をスクリプト化しておく

23時に慌てて打たないよう、今のうちに用意する。

# Debian/Ubuntu（公式リポジトリ or Ondřej Surý PPA）
sudo apt update && sudo apt install --only-upgrade 'php8.3*' && sudo systemctl reload php8.3-fpm

# RHEL/Alma/Rocky（Remi等）
sudo dnf update 'php*' && sudo systemctl reload php-fpm

# Docker：ベースイメージのタグを修正版に上げて再ビルド
# FROM php:8.3-fpm → FROM php:8.3.XX-fpm（公式発表の番号）

4.6 公開前の暫定対策（根本対策ではない）

watchTowrは「公開前のワークアラウンドなし」としています。以下は被害を減らす・検知を上げるための暫定措置で、修正の代わりにはなりません。

  • 外部公開面を減らす：管理画面（/wp-admin/、phpMyAdmin等）、API、Webhookは可能ならIP制限・VPN内に
  • WAF：ベンダーのルール配信状況を確認。あくまで「減速帯」
  • ログ強化：Webサーバーとphp-fpmのログレベルを上げる。アクセスログに X-Forwarded-For と User-Agent が出ているか確認
  • ファイル整合性のベースライン：更新前の webroot のハッシュを取っておく
# webroot のハッシュ・ベースライン（更新後の差分確認用）
find /var/www -type f -name '*.php' -exec sha256sum {} + | sort > /backup/php-files-baseline-$(date +%F).txt
  • 本当に使っていないPHPサービスは、今夜止める。これが一番安い対策

5. 公開後ランブック（23:00 JST〜）

5.1 信じる情報源を3つに絞る

  1. https://www.php.net/ のニュース／アーカイブ
  2. https://github.com/php/php-src/security/advisories
  3. 自分が使っているディストリ／ベンダーのセキュリティ告知（Debian DSA、Ubuntu USN、RHEL RHSA、各レンタルサーバー）

SNSに流れる版数は、公式で突き合わせるまで使わない。 噂されている 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 も、公式が出すまでは噂です。

5.2 更新 → 検証

# 更新後
php -v                      # 修正版になっているか
systemctl status php-fpm    # 再起動・リロードされているか
curl -sI https://example.com/ | head -5   # 200が返るか
  • 主要ページ・ログイン・フォーム送信・決済の動作確認
  • 更新した時刻・バージョン・担当者を記録（監査・報告用）
  • CMSのバージョンとPHPのバージョンは別物。WordPress本体が最新でもPHPは古い、は普通にある

5.3 空白期間（10/20〜更新完了）の侵害痕跡確認

公開前にリークがあった以上、「更新前に入られていないか」の確認は必須。防御側の一般的な確認項目を挙げます（この脆弱性固有のIOCは公式発表待ち）。

# 10/20以降に作成・変更されたPHPファイル
find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls

# ベースラインとの差分
find /var/www -type f -name '*.php' -exec sha256sum {} + | sort > /tmp/php-files-now.txt
diff /backup/php-files-baseline-*.txt /tmp/php-files-now.txt

# アップロード・キャッシュ・一時ディレクトリに .php が紛れていないか
find /var/www -path '*/uploads/*' -name '*.php' -ls
find /var/www -path '*/cache/*'   -name '*.php' -ls
find /tmp /var/tmp -name '*.php' -ls 2>/dev/null

# Webサーバー実行ユーザーのcron・プロセス
crontab -u www-data -l 2>/dev/null
ps -u www-data -o pid,etime,cmd

# 不審な外向き接続
ss -tnp | grep -v ':443\|:80' | grep www-data
  • CMSの管理者アカウント一覧に見覚えのないものがないか
  • wp-config.php 等の設定ファイルの変更日時
  • 不審な点があれば、secrets（DBパスワード・APIキー・SaaSトークン）をローテーションし、ホストは「クリーンと証明できるまで侵害前提」で扱う

5.4 EOL版で更新できない場合の選択肢

  1. ディストリのバックポート：Debian/Ubuntu/RHELはEOLのPHPでもセキュリティ修正をバックポートすることがある。DSA/USN/RHSAを待つ
  2. 移行：8.2+へ。テーマ・プラグイン・ライブラリの互換性確認が必要。今夜は無理でも、計画を今夜立てる
  3. 切り離し：インターネットからの到達を止める（学内・社内限定、VPN必須）
  4. 停止：使っていないなら止める

どれも経営判断・組織判断なので、技術者が一人で抱えず、責任者に「選択肢と期限」を伝える。

6. 医療機関・研究機関の担当者へ

PHPは「配管」で、院内・学内の見えないところに通っています。

  • 病院：公式サイト、採用サイト、Web問診、予約フォーム、院内ブログ
  • 研究室：WordPress、MediaWiki、LimeSurvey（被験者アンケート）、Moodle、Nextcloud、phpMyAdmin、「院生が昔作ったシステム」

制作会社・情報センターに今夜聞くことは3つ。①PHPのバージョン ②今回の修正を当てるのは誰で、いつ ③完了したら連絡をもらえるか。

Web問診や被験者フォームがある場合、サイトの先に個人情報がある。乗っ取られて漏れれば、個人情報保護法26条の報告義務が発生しうる（筆者の理解。法的助言ではない）。

医療機器の回収・改修対応と構造は同じです。通知を読む → 該当機器を洗い出す → 対策を当てる → 部品がない機器を判断する → 記録する。対象が機器からサーバーに変わっただけ。

7. SNS情報との付き合い方

今日、X上で数百万人に届いた投稿が複数あり、煽る方向にも安心させる方向にも、一次情報にない断定が混ざっていました。

  • 「15分以内に全世界へ自動攻撃」→ 出所なし。構図（差分解析→攻撃コード作成の競争）は正しい
  • 「脆弱性の仕組み」の具体的な解説 → 公式未発表。現時点では推測
  • 「共用レンタルサーバーなら対応不要」→ 半分。バージョン切替は利用者側のことが多い
  • 「8.3以上なら安全」→ 根拠なし。公式は影響バージョン未発表
  • 「バックアップしていれば大丈夫」→ バックアップは復旧用。防御ではない

どの投稿も、誰かを守りたくて書かれたものだと思います。情報を共有してくれるエンジニアの方には感謝しつつ、鵜呑みにせず、それぞれが一次情報で確認する。それがこういう夜に一番大事だと思っています。この記事も「21:30時点で筆者が分かっている範囲」なので、同じ扱いでお願いします。

8. 📝 公開後の追記（23時以降に更新）

  • 影響バージョン：（公開後に記載）
  • 修正版：（公開後に記載）
  • 影響コンポーネント・設定条件：（公開後に記載）
  • EOL版の扱い・ディストリのバックポート状況：（公開後に記載）
  • in-the-wild悪用の確認状況：（公開後に記載）
  • 公式が示す検知・緩和策：（公開後に記載）

9. お願い

筆者はセキュリティ専門職ではありません。医療機器の現場に11年いた臨床工学技士が、AIエンジニアとして一次情報を読んで整理している立場です。

間違い・不足があれば指摘してください。特にセキュリティエンジニアの方、PHPを本番運用している方、レンタルサーバー事業者の方。 ランブックの抜け、より良い確認コマンド、ディストリ別のバックポート情報など、コメントいただけたら追記します。

出典

免責

本記事は2026年10月21日21:30 JST時点の公開情報にもとづく筆者の整理と個人的見解です。脆弱性の技術的な仕組み・攻撃手順には触れていません。記載したコマンドは一般的な運用確認の例であり、環境に合わせて読み替えてください。影響バージョン・修正版は公式発表で必ず確認してください。引用した投稿の検証は内容の切り分けが目的で、投稿者個人への評価ではありません。筆者は本記事の内容を実際の業務で使われたことに起因するいかなる損害についても責任を負いません。

著者

臨床工学技士 × AIエンジニア / 11年間、病院の医療機器の現場に立ち続けてきました。
いまはAIエンジニアとしても活動しながら、酪農学園大学の研究生として論文博士の取得を目指しています。
研究テーマの主軸は遺伝子医療の未来。そのうえで、医療現場と地続きにある病院のIT・サイバーセキュリティ・医療AI導入についても、現場で起きている課題と一次情報を突き合わせながら調べ続けています。

質問・誤りの指摘・「うちではこうしている」という事例の共有、いつでも歓迎します。

X：@endoh_taichi
Qiita：@TaichiEndoh

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?