Scribble at 2026-10-24 11:01:43 Last modified: unmodified

Pixiv が PHP の脆弱性に対処して数十分でサイトを復旧させたことを賞賛している人がいたりするんだけど、話はそんなドパガキの基準で判断できるわけではない。

まず簡単に言えば、PHP のパッチを当てる作業そのものは１分で終わる。具体的には、

# dnf updateinfo list sec | grep php

でリポジトリにパッチが用意されていることを確かめてから、

# dnf upgrade "php*"

で更新処理を完了して、

# systemctl restart php-fpm

# systemctl restart httpd

で終わりである。僕の場合は、パッチが用意されるタイミングが不明だったから、ひとまず自分で管理している全てのウェブ・サーバに対して、cron で23:15に上のような一連の処理を実行するように、一回限りのタスクを定義して実施した（そして、既に説明したように AmazonLinux 2023 はパッチが用意されるまでにもっと時間がかかった）。

現実には、「さくらインターネットの VPS」が最も早くパッチが用意されていて、その次に「さくらのクラウド」で運用していた KUSANAGI のパッチ、そして最後に AmazonLinux 2023 という順番であった。実は、最も早い VPS でも23:15にパッチは当てられなかったので、手動でなんどかやりなおしたというのが実情だ。なので、こういうことはパッチの適用を受けられる側からすれば、適用する時刻をコントロールできるわけではない。かといって、Pixiv のように自力でソースコードからパッチを当てる方法が最善かというと、もちろんそうとも限らないのはプロのサーバ・エンジニアであれば誰でも知っていることだ。なぜなら、手動でパッチを当てると dnf の管理から逸脱してしまい、それ以降は全て手動でプログラムを更新しなくてはいけなくなるからだ。Pixiv のように自社でエンジニアを何人もかかえているならともかく、大多数のウェブ制作会社に僕のようなレベルのサーバ・エンジニアがいるわけでもないし、ベンダーにすら、プログラマやコーダはいても、サーバつまり OS そのものを運用できるエンジニアが何人もいるとは限らないのである。

また、既に報道されているように、PHP のバージョンが低いとパッチが用意されない場合がある。得てして WordPress で気軽に構築されたようなサイトだと、いまだに PHP が 7.x 系統、酷い場合は 5.x 系統のままサーバを運用している・・・上場企業すらあるのを、僕は電通や博報堂の案件でさんざん見てきた（もちろん、そのたびに指摘はしている）。そうなってくると、最新のパッチを当てるためには OS を入れ替えないといけない。今回の PHP の脆弱性に対処する作業は急に必要となったことなので、あらかじめ OS を入れ替えておくことはできなかったので、この機会に新しくサーバを用意していると、それこそ１日仕事であろう。