この記事を書いた理由
2026年10月21日の夜、PHPの修正版が公開されました。直後の情報の多くは英語か、php.iniやPHP-FPMが並ぶエンジニア向けの日本語でした。正しい情報ですが、Webディレクターがそこから「うちは今日何をすればいいのか」を導くのは難しい。それがこの記事を書いた動機です。
読んだ方に考えてほしいのは、脆弱性対応の初動で一番時間を失うのは技術の理解ではなく担当者探しだという点です。誰がPHPを更新できる立場なのかが分かれば、残りの作業は半分以上片付きます。
私はフリーランスでAIとWeb領域の技術支援をしており、手元の検証環境（Ubuntu 24.04）でもPHPを動かしています。今回、その環境で修正パッケージへの更新前と更新後を実際に確かめました。その中で一つ、エンジニアでも見落としそうな落とし穴に気づいたので、第5章で共有します。
この記事の対象読者
- Webサイトの運営・制作進行を担当していて、PHPやサーバーの設定は自分では触らない方（Webディレクター、Web担当者、制作進行）
この記事で得られること
- 自社サイトが今すぐ動くべき状態かを判定し、誰に何を依頼するかを今日中に決められる
- エンジニアや保守会社にそのまま送れる依頼文と、返ってきた答えを判定する基準
- 「WordPressを更新したから大丈夫」などの、よくある勘違いの見分け方
この記事で扱わないこと
- 攻撃の再現方法や攻撃コードの解説（防御側の判断に必要な範囲だけを扱います）
- PHP 8.2以上への移行作業そのものの手順
1. 何が起きたのか ── 30秒で分かるPHP2Shell
このセクションで分かること：事件の全体像と、なぜ今日中なのか。
PHP（Webサイトの裏側でページを組み立てるプログラム言語）の本体に、2件の重大な脆弱性が見つかりました。番号は CVE-2026-109618 と CVE-2026-109619（CVEは脆弱性に振られる世界共通の番号）で、2件まとめて PHP2Shell と呼ばれています。PHP公式の呼び名ではなく、情報漏えい後に出回った検証用ツールの名前に由来します。
深刻度を表すCVSS（脆弱性の深刻さを0〜10で採点する国際的な指標）は、2件とも 9.2 です。この記事に出てくる用語は、末尾の用語集にもまとめています。中身はRCE、つまり外部の第三者がサーバーの上で好きなプログラムを動かせてしまう種類の欠陥で、ログインもユーザーの操作も必要ありません。
Ubuntuによると、配布元と調整していた本来の公開日は10月22日で、情報が漏れたため1日前倒しされました。修正版の公開直後、セキュリティ企業のwatchTowrは、2件への攻撃の試みを観測していると発表しました。
PHP公式は、8.5.12などのリリース告知で暫定策についてこう書いています。
There are no complete mitigations, updating is the only safe choice.
（和訳：完全な回避策はありません。更新だけが安全な選択肢です。）
IPA（情報処理推進機構）も10月21日、PHPを使うプログラムの棚卸しを呼びかけています。
2. なぜ危ないのか ── 厨房のたとえで2つの穴を理解する
前章で、外部から好きなプログラムを動かされる欠陥だと分かりました。仕組みを押さえておかないと、WordPressの更新のような効かない対策で安心してしまいます。
このセクションで分かること：なぜWordPress側の対策では直らないのか。
Webサイトをレストランにたとえます。この記事では最後までこのたとえを使います。
| たとえ | 実際の仕組み |
|---|---|
| レストランの店舗 | Webサーバー |
| 厨房 | PHP本体 |
| 注文票 | ブラウザから届くリクエスト |
| 調理担当（同じ人が次々注文をさばく） | ワーカー（リクエストを処理するPHPのプロセス） |
| 調理台の広さの上限 | memory_limit（PHPが使えるメモリの上限） |
| メニューと料理のレシピ | WordPressなどのアプリ |
| 厨房の作業手順書の改訂 | PHPの修正版への更新 |
穴1：調理台があふれた瞬間の後片付け（CVE-2026-109618）
PHP公式の説明では、メモリ不足の処理がリクエストの内部データを作りかけのまま中断させ、その後の後片付けが壊れたデータを正しいものとして扱ってしまうことがあります。
たとえで言えば、調理台があふれた瞬間に作業を打ち切ったところ、書きかけの注文票が完成品として片付け工程に回る状態です。攻撃者はわざと調理台をあふれさせ、片付け工程を乗っ取ります。
穴2：前のお客のメモが残っている（CVE-2026-109619）
もう1件は、リクエストが持っていた内部の状態が、メモリを解放した後も残ってしまう欠陥です。同じワーカーが次のリクエストを処理するとき、その古い状態を使ってしまいます。
たとえで言えば、片付けたはずの前のお客の注文メモが次のお客の料理に使われる状態です。
どちらも厨房の手順の問題
2つの穴はどちらも、メニュー（WordPress）ではなく厨房（PHP本体）の欠陥です。PHP公式は、PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedと、動かし方を問わずWebリクエストを処理するすべてのPHPが対象だとしています。
中でも危険度が最も高いとされたのが、Apacheに組み込んで動かすmod_phpです。PHP公式は、アプリのコードが1行も動く前に、認証なしのリクエストで攻撃が成り立つ実証があると書いています。受付を通る前に厨房へ入られるイメージです。
WordPress.orgも10月21日に、この2件はWordPress固有の問題ではなく、WordPressの更新は不要で予定もないと発表しました。直すのは厨房、つまりPHP本体です。
3. 自社サイトは対象か ── 誰が厨房を直せるかで判定する
前章で、直すべきはWordPressではなくPHP本体だと分かりました。すると次に決めるべきことは、そのPHPを更新できるのは誰かです。担当者によって、あなたの今日の動きはまったく変わります。
このセクションで分かること：自社サイトの管理形態ごとに、誰が何をするのか。
修正済みの版
PHP公式が10月21日に出した修正版は次の4つです。
| PHPの系列 | 修正版 | 補足 |
|---|---|---|
| 8.5 | 8.5.12 | 8.5だけの暫定策がある、第6章 |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | 2026年12月31日でサポート終了 |
| 8.1以前 | 公式の修正版なし | OS提供元の修正を確認するか、8.2以上へ移行 |
8.1以前向けにPHP公式が出したのは、7.4・8.0・8.1用の最小限のソースコード修正だけです。自分でビルドする人や長期サポート提供元向けのもので、Webディレクターが直接使うものではありません。
WordPress.orgは、8.2より古いPHPのサーバーを自分たちで管理しているなら、更新の準備ができるまでサーバーをインターネットから外すことも検討するよう勧めています。英国の国家サイバーセキュリティセンターの助言を引用した形です。
レンタルサーバーの場合
共用レンタルサーバーでは、PHP本体を入れ替えるのはサーバー会社です。管理画面で選べるのは「8.3」「8.4」といった系列で、系列の中の修正（8.3.36など）はサーバー会社が当てる形が一般的です。
各社は10月21日の夜から緊急メンテナンスや修正の適用を進めており、予防目的で管理画面を一時停止した事業者もあると利用者のブログなどで報告されています。状況は刻々と変わるので、契約しているサーバー会社のお知らせページで最新情報を確かめてください。
4. 今日やる5つのこと ── 誰に何を頼むか
前章の判定で、あなたのサイトの厨房を直せる人が決まりました。この章では、その人に向けて今日中に動く手順を並べます。
このセクションで分かること：今日中にやる作業と、そのまま送れる依頼文。
手順1：PHPの版を確認する
WordPressなら、管理画面の ツール → サイトヘルス → 情報 → サーバー にPHPのバージョンが表示されます。WordPress.orgの告知が案内している場所で、サーバーの管理画面が予防停止で開けなくても確認できます。
手順2：PHPを更新できる担当者を特定する
保守契約書、サーバー代の請求書、制作会社とのメールから、サーバーの契約者と管理者を確かめます。分からなければ、それも今日の依頼に含めます。
手順3：担当者に依頼を送る
次の文面をそのまま使えます。〇〇の部分だけ埋めてください。
件名：【至急】PHP脆弱性（CVE-2026-109618 / CVE-2026-109619）の対応状況確認
〇〇様
PHP本体に、認証なしで外部からプログラムを実行される脆弱性が
2件公表されました（通称PHP2Shell、2026年10月21日修正版公開）。
弊社サイト（〇〇.co.jp）について、以下をご確認ください。
1. サイトを動かしているPHPのバージョンと、動かし方
（PHP-FPM / Apacheのmod_php など）
2. 修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）または
OSの修正済みパッケージを適用済みか、未適用なら適用予定日時
3. 適用後にPHPやWebサーバーを再起動したか
4. 10月20日以降のログに不審な痕跡がないか
（不審なファイル、知らない管理者、外部への通信）
5. 8.1以前の場合、移行または公開停止の判断
本日中に、現状と見込みだけでも返信いただけると助かります。
手順4：8.1以前なら移行か公開停止かを決める
サイトヘルスに8.1以前の版が表示された場合は、厨房の手順書の改訂版がそもそも配られない状態です。選択肢は次の3つです。
- OSやサーバー会社が独自に修正を配っているか確認する
- PHP 8.2以上へ移行する（プラグインやテーマが動かなくなることがあるので、バックアップと動作確認が前提）
- 移行が終わるまで公開を止める
どれを選ぶにせよ、決めずに放置するのが最も危険です。
手順5：入られていないかとバックアップを確認する
修正前に入られていないとは限りません。watchTowrは、変更前にログと設定を保全し、不審なファイル、見慣れない定期実行、新しいアカウントを確認するよう勧めています。
Webディレクターが自分で見られるのは次の2点です。
- WordPressのユーザー一覧に、知らない管理者が増えていないか
- バックアップがサーバーの外にあり、10月20日より前の時点に戻せるか
ファイルやログの確認はエンジニアに任せます。
ここまでのまとめ
- 直すべきなのはWordPressではなく、厨房にあたるPHP本体
- 対応は「PHPを更新できるのは誰か」で決まる。今日中に、その人へ依頼する
- 修正版は8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。8.1以前は公式の修正なし
次の章では、手順1の「版を確認する」に潜んでいた落とし穴を扱います。
5. エンジニアに渡す確認方法 ── 版の番号に騙されない
前章の手順1で、版を見れば修正済みかが分かると書きました。実は、それが成り立たないケースがあります。エンジニアから「8.3.6です」と返ってきたとき、正しく受け止めるための章です。
このセクションで分かること：OSのパッケージで入れたPHPは、修正後も版の番号が変わらないこと。
手元のUbuntu 24.04で修正前後を比べた
UbuntuなどのLinuxディストリビューション（Linuxを配布用にまとめたもの）は、PHPの版の番号を据え置いたまま、修正だけを取り込む方式をとります。Ubuntuの公式発表では、Ubuntu 24.04のphp8.3は 8.3.6-0ubuntu0.24.04.13 で修正済みです。
検証環境で、修正パッケージへの更新前と更新後を確かめました。
- 環境：Ubuntu 24.04.5 LTS、php8.3パッケージ、CLI（コマンドラインで動かすPHP）で実行
- 実施日：2026年10月22日
| 確認項目 | 更新前 | 更新後 |
|---|---|---|
| php -v の表示 | PHP 8.3.6（10月7日ビルド） | PHP 8.3.6（10月19日ビルド） |
| パッケージ版 | 8.3.6-0ubuntu0.24.04.12 | 8.3.6-0ubuntu0.24.04.13 |
| 下のスクリプトの判定 | 公式の番号では修正前 | 公式の番号では修正前 |
| 実際の状態 | 未修正 | 修正済み |
更新後も php -v は8.3.6のままで、変わったのはビルド日だけでした。ビルド日に目を留めるまで、更新が効いていないようにしか見えなかったのは意外でした。版の番号だけで判定すると、修正済みのサーバーを未修正と誤判定します。逆に、番号だけ見て「8.3.6は古いから危ない」と騒ぐのも誤りです。
表の判定に使ったスクリプトです。
<?php
// php2shell_check.php -- PHP2Shell (CVE-2026-109618 / 109619) 簡易確認
// Webサーバーに置いてブラウザで開くと、実際にサイトを動かしているPHPを確認できる。
// 確認が終わったら、このファイルは必ず削除すること。
$fixed = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP_VERSION : ' . PHP_VERSION . "\n";
echo 'SAPI : ' . PHP_SAPI . "\n";
echo 'upload_progress : ' . (ini_get('session.upload_progress.enabled') ? 'on' : 'off') . "\n";
if (!isset($fixed[$branch])) {
$verdict = '8.1以前。PHP公式の修正版なし。提供元の修正を確認するか 8.2以上へ移行';
} elseif (version_compare(PHP_VERSION, $fixed[$branch], '>=')) {
$verdict = '公式の修正版以上';
} else {
$verdict = '公式の番号では修正前。OSのパッケージは番号が変わらないため、パッケージ版も確認';
}
echo "判定 : {$verdict}\n";
このファイルを置いたままにすると、PHPの版を外部に教えることになります。確認が終わったらすぐに削除するよう、エンジニアに念押ししてください。
OSのパッケージで入れている場合は、パッケージ版と変更履歴で判定します。Ubuntuなら次のコマンドで、2つ目が1以上を返せば修正が取り込まれています。
# パッケージ版を表示（Ubuntu 24.04 なら .13 以上が修正済み）
dpkg-query -W -f='${Package} ${Version}\n' php8.3-common
# 変更履歴に今回のCVE番号が載っているか数える
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -c 'CVE-2026-109618'
# 更新後は再起動が必要（mod_php なら apache2、FPM なら php8.3-fpm）
sudo systemctl restart apache2
検証環境での実行結果は、パッケージ版が 8.3.6-0ubuntu0.24.04.13、CVE番号の出現回数が 2 でした。Ubuntuの公式発表も、mod_phpを使うApacheでは再起動が必要だと明記しています。更新しただけで再起動していないサーバーは、古い厨房のまま動き続けます。
複数サイトをまとめて判定する
制作会社や代理店の立場で、何十サイトもの報告を受け取る場合は、版の一覧表をまとめて判定すると取りこぼしが減ります。次のPythonスクリプトは、Ubuntu・Debianのパッケージ版の比較規則（dpkgと同じ規則）を再現したものです。手元で dpkg の判定と306通りの組み合わせを突き合わせ、すべて一致することを確認しました。
"""Debian/Ubuntu のパッケージ版を比較する最小実装（dpkg と同じ規則）"""
import re
def _order(c: str) -> int:
if c == "~":
return -1
return ord(c) if c.isalpha() else ord(c) + 256 # 記号は英字より後ろ
def _lex(a: str, b: str) -> int:
for i in range(max(len(a), len(b))):
ca = _order(a[i]) if i < len(a) else 0
cb = _order(b[i]) if i < len(b) else 0
if ca != cb:
return ca - cb
return 0
def _vcmp(a: str, b: str) -> int:
while a or b:
da, db = re.match(r"\D*", a)[0], re.match(r"\D*", b)[0]
if r := _lex(da, db):
return r
a, b = a[len(da):], b[len(db):]
na, nb = re.match(r"\d*", a)[0], re.match(r"\d*", b)[0]
if r := int(na or 0) - int(nb or 0):
return r
a, b = a[len(na):], b[len(nb):]
return 0
def deb_cmp(a: str, b: str) -> int:
"""a > b なら正、a == b なら 0、a < b なら負を返す"""
def split(v: str):
epoch, _, v = v.partition(":") if ":" in v else ("0", "", v)
up, rev = v.rsplit("-", 1) if "-" in v else (v, "0")
return int(epoch), up, rev
(ea, ua, ra), (eb, ub, rb) = split(a), split(b)
return (ea - eb) or _vcmp(ua, ub) or _vcmp(ra, rb)
上を debver.py として保存し、判定本体を check_inventory.py として同じフォルダに置きます。
"""PHP2Shell 棚卸し判定: CSV(host,version) を読んで修正済みかを判定する"""
import csv
import re
import sys
from debver import deb_cmp
# PHP公式の修正版（php.net 2026-10-21）
UPSTREAM = {"8.5": "8.5.12", "8.4": "8.4.27", "8.3": "8.3.36", "8.2": "8.2.35"}
# OSパッケージの修正版（Ubuntu / Debian の公式発表）。番号の付き方がPHP公式と違う
DISTRO = [
(r"^8\.3\.6-0ubuntu0\.24\.04\.", "8.3.6-0ubuntu0.24.04.13"), # Ubuntu 24.04
(r"^8\.1\.2-1ubuntu2\.", "8.1.2-1ubuntu2.28"), # Ubuntu 22.04
(r"~deb12u\d+$", "8.2.35-1~deb12u1"), # Debian 12
(r"~deb13u\d+$", "8.4.27-1~deb13u1"), # Debian 13
]
def judge(ver: str) -> str:
for pattern, fixed in DISTRO:
if re.search(pattern, ver):
return "修正済み" if deb_cmp(ver, fixed) >= 0 else f"要更新 -> {fixed} 以上"
m = re.fullmatch(r"(\d+)\.(\d+)\.\d+", ver)
if not m:
return "判定不能 -> 提供元の告知でパッケージ版を確認"
fixed = UPSTREAM.get(f"{m[1]}.{m[2]}")
if fixed is None:
return "公式修正なし -> 提供元の修正確認か 8.2 以上へ移行"
return "修正済み" if deb_cmp(ver, fixed) >= 0 else f"要更新 -> {fixed} 以上"
if __name__ == "__main__":
with open(sys.argv[1], encoding="utf-8") as f:
for row in csv.DictReader(f):
print(f"{row['host']:<14} {row['version']:<26} {judge(row['version'])}")
python3 check_inventory.py inventory.csv で実行します。検証環境の実際の版と、架空のサイト名を混ぜた一覧で試した結果が次の表です（Python 3.13.16）。
| サイト | 報告された版 | 判定 |
|---|---|---|
| 検証環境・更新前 | 8.3.6-0ubuntu0.24.04.12 | 要更新、.13以上へ |
| 検証環境・更新後 | 8.3.6-0ubuntu0.24.04.13 | 修正済み |
| 共用サーバーA | 8.3.35 | 要更新、8.3.36以上へ |
| Debian 12のサーバー | 8.2.35-1~deb12u1 | 修正済み |
| 古いサーバー | 7.4.33 | 公式修正なし、提供元確認か移行 |
| RHEL系のサーバー | 8.3.19-1.el9 | 判定不能、提供元の告知で確認 |
最後の行のように、RHEL系（Red Hat Enterprise Linuxとその互換OS）は番号の規則が違うため、このスクリプトはあえて判定しません。分からないものを「安全」と表示しないことを優先しました。
6. すぐ更新できないときの暫定策 ── 張り紙は鍵ではない
前章で、修正済みかどうかを正しく判定できるようになりました。では、判定の結果が「未修正、しかも今日中には更新できない」だったらどうするか。
このセクションで分かること：暫定策の中身と、それが不完全である理由。
PHP公式は、更新できない場合に特定の攻撃経路を減らす方法を挙げています。たとえで言えば、入口に「大きすぎる注文はお断り」と張り紙をするようなもので、厨房の手順書そのものは古いままです。
| 対象 | PHP公式が挙げる暫定策 | 限界 |
|---|---|---|
| CVE-2026-109618 | memory_limit=-1 をアプリが上書きできない形で設定 | 根本のメモリ確保失敗からは、なお到達しうる |
| CVE-2026-109618 | post_max_size を小さくする（アップロードなしなら8M、ありなら32M） | 攻撃の材料を減らすだけ |
| CVE-2026-109619 | session.upload_progress.enabled=0 にして全ワーカーを再起動 | 確認された経路だけを塞ぐ。ini_set() や .user.ini では効かない |
| CVE-2026-109619 | PHP 8.5なら fatal_error_backtraces=0 | 8.5特有の経路だけを塞ぐ |
watchTowrは、こうした設定ファイルの変更による緩和策は効果がないものと理解すべきだと書いています。PHP公式自身も、これらは安全な状態を作らないと明記しています。
ほかに取れる手は次のとおりです。
- WAFを使う：WAF（入口で怪しい注文票を止める警備員）としてCloudflare（Web配信と防御の企業）を使うサイトは、10月21日から無料プランを含めて既定で保護されていると同社は発表しています。ただし警備員は厨房を直せません
- 公開を止める：第3章のとおり、すぐ更新できない古いサーバーはインターネットから外すのも選択肢です
7. トラブルシューティング ── よくある勘違いと次の一手
前章までで、判定と対策の全体がそろいました。最後に、依頼の返信でよく出てきそうな勘違いを表にまとめます。
このセクションで分かること：よく出る返答の正誤と、次にやること。
| よく聞く言葉 | 実際は | 次の一手 |
|---|---|---|
| WordPressを最新にしたので大丈夫 | メニューを替えても厨房は直らない。WordPressの更新は今回不要 | PHPの版を確認する |
| セキュリティプラグインを入れている | アプリより下の層の欠陥なので防げない | PHPの更新状況を確認する |
| php -v が8.3.6のまま | OSパッケージなら修正済みでも番号は同じ | パッケージ版と変更履歴で判定する |
| 更新はしたが再起動はまだ | 古い厨房のまま動いている | PHP-FPMやApacheを再起動する |
| Cloudflareを使っているので安全 | 警備員は入口を守るだけ | それでもPHPを更新する |
| サーバーの管理画面に入れない | 予防的な一時停止の可能性 | サーバー会社のお知らせを見る。版はサイトヘルスで確認 |
| 保守会社と連絡がつかない | 待つほど危険が増える | 契約書の緊急連絡先、サーバー会社の窓口にも連絡する |
8. 次の脆弱性で慌てないためのロードマップ
前章で初動の判断はそろいました。ただ、IPAは2024年にもPHPの脆弱性の悪用で注意喚起を出しており、次は必ず来ます。担当者探しを繰り返さないための準備です。
このセクションで分かること：今日の対応を、次回に生かす順番。
- サイト台帳を作る：サイトごとにサーバー会社、PHPの版、管理者、緊急連絡先を1行で持つ。手順2が数分で終わります
- 保守契約を見直す：OSやPHPのセキュリティ更新が範囲に入っているか、対応期限は何時間かを明記する
- 注意喚起の受け取り口を作る：IPAの重要なセキュリティ情報とサーバー会社のお知らせを、担当者が必ず見る場所に流す
まとめ
PHP2Shellは、WordPressではなくPHP本体という厨房の欠陥でした。メニューをいくら新しくしても直りません。
Webディレクターが今日やるべきことは、厨房を直せる人を見つけ、修正版の適用と再起動を確認することです。版の番号が8.3.6のままでも、OSのパッケージなら修正済みのことがあります。逆に、番号を見ずに「うちは大丈夫」と言い切るのが最も危ない判断です。
一次情報を読み比べて私が感じたのは、効くのは技術知識より「このサイトのサーバーは誰が触れるのか」を即答できることだ、という点です。今日の対応が終わったら、その答えを台帳に1行残しておいてください。
用語集
| 用語 | 意味 | レストランのたとえ |
|---|---|---|
| PHP | Webページを組み立てるプログラム言語とその実行環境 | 厨房 |
| RCE | 外部からサーバー上で任意のプログラムを動かせる欠陥 | 客が厨房で包丁を握れる状態 |
| ワーカー | リクエストを処理するPHPのプロセス | 調理担当 |
| mod_php | Apacheに組み込んでPHPを動かす方式 | 受付と厨房が一体の店 |
| PHP-FPM | PHPを別プロセスとして動かす方式 | 受付と厨房が分かれた店 |
| WAF | 怪しいリクエストを入口で止める仕組み | 入口の警備員 |
| サポート終了 | 公式の修正が出なくなること | 手順書の改訂が配られない |
参考文献
PHP公式のセキュリティ告知。対象、修正版、暫定策とその限界。
GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（邦題訳：メモリ不足による破損を通じたリモートコード実行）。CVE-2026-109618の詳細。
GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（邦題訳：古いグローバル状態を通じたリモートコード実行）。CVE-2026-109619の詳細。
WordPress.org「Critical PHP Security Release」（邦題訳：PHPの重大なセキュリティリリース）。WordPress更新が不要なこと、版の確認場所。
IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」。棚卸しの呼びかけ。
Ubuntu「php2shell ... PHP critical vulnerability fixes available」（邦題訳：PHPの重大な脆弱性の修正が利用可能に）。版ごとの修正済み番号と再起動の要否。
Debian Security Tracker。Debian 12・13の修正済み番号。
watchTowr「PHP Remote Code Execution (PHP2Shell)」（邦題訳：PHPのリモートコード実行）。悪用の観測状況と対応手順。
Cloudflare「Cloudflare deploys protections against php2shell vulnerability」（邦題訳：Cloudflare、php2shellへの防御を展開）。WAFの既定保護。
YouTube版はこちら
最新情報や、次の記事の告知はXで発信しています。
Zennではより技術寄りの記事を書いています。