Scribble at 2026-10-22 17:28:48 Last modified: 2026-10-22 17:35:30

さて、今回の PHP に見つかった深刻な脆弱性への対応だが、弊社のサービス・サイトはカーネルの更新も含めてサービス・サイトの再起動を慎重にやらないといけないものは停止している。それから、求人サイトの方は WordPress で動いてるだけと言えばそれまでだから、さっさと PHP を更新して復旧している。どちらも委託先に委ねてあるし、取り回しも提携しているエンジニアらの采配に任せて10年以上となるから、ひとまず彼らの対応を見ているだけである。

さて、コーポレート・サイトだが、これは僕が AWS で単独に運用・管理しているサーバなので、もちろん PHP のパッチは適用するのだけれど、昨日の23:00を回った当初は、困ったことに Amazon Linux 2023 はパッチを用意できていなかった・・・というか、用意したパッチが汚染されていたり、あるいは誰かに勝手に削除されていたり、かなり AWS でも混乱が続いていたようだった。もっとも、これも既にリポジトリへ最新のパッチが反映されていたから、更新作業は上の画面で示したように完了している。

ちなみに、もともと弊社のコーポレート・サイトは、今回のようなリモート・コードを実行されるリスクには、幾つかの対策をしてある。第一に、"file_uploads" を "off" にしてあること、そして第二に、"disable_functions" で "phpinfo, eval, exec, passthru, shell_exec, system, proc_open, popen, parse_ini_file, show_source" といった関数を使えなくしてあることだ。こういうことは、サーバの全権を握っていて、どこでどういうプログラムを使っているか知っており（すべて僕が開発して実装したのだから当然だ）、それらが必要とする関数やモジュールを特定したり区別できるからこそ実施できる対策だ。レンタル・サーバでこのような設定は、誰がどんなプログラムを使っているのか分からないからには、ほぼ不可能だろう（file_uploads を無効にするだけで WordPress のユーザは画像を全くアップロードできなくなるわけだし）。

なんしか、昨日の夕方からさきほどまで、ほぼ24時間の就業であった。もちろん、途中で当然のように寝たし、歯医者にも行ってきたけれど、打刻としては久しぶりに酷い内容だ。おかげで、「リモート・ワークは週に４日」という意味不明なルールがあるため、本来は明日は出社しないといけないのだが、今回は自宅でやらせてもらうことにした。そもそも、幾つかのサーバは自宅の IP アドレスしかアクセスを許可していない。WeWork の IP アドレスを許可して作業するなんて、同じ IPアドレスを誰と共用しているかも分からないのに、どう考えても自殺行為であろう。よって、実は会社でサーバ・エンジニアリングの仕事なんてもはやできないのである。