PHP2Shellによる侵害調査
2026/10/21、PHP2Shell（CVE-2026-109618、CVE-2026-109619）が世界をパニックに陥れた。remiと各ディストリが迅速に緊急パッチを配信してくれたおかげで脅威はほどなく去ったのだが、JPCERTがアドバイザリ「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」 JPCERT-AT-2026-0033を発表、その中で侵害調査を推奨していたのでChatGPTの助けを借りてログを調べた。
JPCERT-AT-2026-0033によると
– 過去のHTTPレスポンスにおいて、不自然に長い、または異常な形式の値を含むPHPSESSID Cookieが設定されていないか。
– 不審なmultipart/form-data形式のHTTPリクエストが送信されていないか。また、その前後にPHPのメモリ上限に関連するエラーやHTTP 500エラーが発生していないか。
– PHPのワーカープロセスが予期せず異常終了したり、頻繁に再起動したりした痕跡がないか。
の3点について確認を推奨とのこと。
PHPSESSID Cookieの異常調査は「PHPのプロセスメモリがHTTPレスポンスのCookieに漏れ出す攻撃を想定した調査」とのことだがこれについて調べるためには通常のcombined形式のapacheログではなく、LogFormatに %{Set-Cookie}o などが含まれている必要があるそうで、デフォルトのログしか取っていないと調べることは出来ないようだ。
また、不審なmultipart/form-data形式のHTTPリクエストが送信されていないかについても、apacheのログにはContent-Type: multipart/form-dataは記録されないため、調べられるのは500番台のエラーになっているPOSTリクエストが集中しているかどうかだけのようだ。
そこでapacheのログだけではなく、php-fpmのログに出てくるメモリ関連のエラーやfatal/プロセス異常などのワーカーエラー ――PHP2Shellを突いた攻撃では、PHPのHTTPリクエスト処理中にメモリ不足や不適切な内部状態の再利用が発生すると、メモリ破壊を経て任意コード実行につながる脆弱性が突かれる為、組み合わせとしてPOSTの5xxとphp-fpmのメモリ破壊やプロセスの異常終了がセットになって現れてくるとみられる――を確認して、上の500番台エラーとなっているPOSTリクエストと突合し、両者がシンクロしていないかどうかが一つのメルクマールとなりそうだった。
以上について、10月17日には既に攻撃の試行が観測されていたとの報告があるため、2026年10月17日～22日を調査期間とし、ApacheおよびPHP-FPMの現行・ローテーション済みログを対象として追ってみた。
まずphp-fpmログをチェック。
sudo grep -HniE \
'Allowed memory size|memory exhausted|out of memory|Fatal error|SIGSEGV|SIGABRT|segfault|exited on signal|child [0-9]+ exited|emergency restart|failed' \
/var/log/php-fpm/error.log \
/var/log/php-fpm/error.log-20261018 \
/var/log/php-fpm/www-error.log \
/var/log/php-fpm/www-error.log-20261018
ここで以下のMessageをチェック。
Allowed memory size … exhausted PHPのメモリ上限超過
PHP Fatal error … PHPの致命的エラー
SIGSEGV … 不正なメモリアクセスによる異常終了
SIGABRT … プロセスの異常終了
child … exited on signal 子プロセスのシグナルによる終了
AH01067 … ApacheとFastCGI間の通信異常の可能性
結果としては、メモリ関連のエラーは確認されなかった。
その他のエラーはbotによるWordPress内部ファイル探索の形跡のようで、PHP2Shellを突いた攻撃痕とは考えにくいものだった。
そこで次に対象期間にphp-fpmでエラーになった上の攻撃とapacheログを突合させてHTTP側のエラー内容を確認した。
sudo find /var/log/httpd -maxdepth 1 -type f \
\( -name '*access_log' -o -name '*access_log-20261018' \) \
-exec grep -HnE \
'(functions[.]php|wp-settings[.]php|wp-admin/includes/admin[.]php|wp-includes/blocks/(latest-posts|rss|search)[.]php)' \
{} +結果、WordPressターゲットのスキャンがくり返されていることと、HTTP 500エラーが、POSTではなく、すべてGETエラーであることがわかった。
さらに直接、POSTで500が発生したログを探してみた。
sudo awk '
$6 == "\"POST" {
post++
if ($9 == 500) {
post500++
print FILENAME ":" FNR ":" $0
}
}
END {
printf "POST総数: %d\nPOSTでHTTP 500: %d\n", post, post500
}' /var/log/httpd/organicsys.jp_ssl_access_log{,-20261018}
POST総数: 3530
POSTでHTTP 500: 0やはり一件もなかった。
念押しでjournalログでのphp-fpmの異常終了についても確認した。
echo "=== PHP-FPM / Apache systemdログ ==="
sudo journalctl -u php-fpm -u httpd \
--since "2026-10-11 00:00:00" \
--until "2026-10-23 00:00:00" \
--no-pager |
grep -Ei 'segfault|SIGSEGV|SIGABRT|signal|exited|crash|core dump|oom|out of memory|killed process|emergency restart|failed'
echo "=== カーネルログ ==="
sudo journalctl -k \
--since "2026-10-11 00:00:00" \
--until "2026-10-23 00:00:00" \
--no-pager |
grep -Ei 'php-fpm|httpd|segfault|out of memory|oom-killer|killed process'結果はゼロ出力だった。
=== PHP-FPM / Apache systemdログ ===
=== カーネルログ ===ただし既にjournalログはローテートしていて2026/10/20 06:35からの分しか残っていなかったのでこの期間にphp-fpmが異常終了するイベントはなかったということになる。
以上から、php-fpmとapacheの両者でシンクロして起こったメモリ異常＋HTTP500は確認できないことを確認できた。もちろんこれは簡易調査に過ぎず、別ルートでの侵害可能性を全否定できるものではない。
が、おおよその目安として、当サイトはPHP2Shellを突く攻撃には遭っていなかった可能性が高いと言うことは可能だろう。
なのでパッチ適用後、サイトの公開を再開した。
