ソフトウェアを、最新に保つ――新しい版を知る、手に入れる、反⁠映⁠す⁠る

脆弱性の記事の最後には、たいてい「最新版に更新してください」と書かれています。私たちの記事もそうです。ただ、何を、どこから手に入れて、どう本番に反映するのかが分からなければ、手が止まり⁠ま⁠す⁠。

この記事では、サイトを動かしているソフトウェアを層に分けて、新しい版の知り方、手に入れ方、本番への反映の仕方を書きます。ウェブのセキュリティの基本の4本のうち、4本目です。後半はエンジニア向けのコマンドが多くなり⁠ま⁠す⁠。

誰が、何を更新す⁠る⁠の⁠か

更新するものは一つではありません。サイトの下にはOSがあり、その上でPHPやNode.js、データベースが動き、さらにその上に、WordPressのようなCMSの本体、プラグインとテーマ、Composerやnpmで入れたライブラリ、Dockerのイメージが重なっています。社内のルーターやVPN、ファイアウォールにも、同じように更新が要ります。1本目の自社サイトの点検で書き出したものが、そのまま使え⁠ま⁠す⁠。

層ごとに、更新する人が違います。レンタルサーバーなら、OSはサーバーの会社が更新しますが、VPSやクラウドなら自分です。PHPやNode.jsの版の切り替えは、レンタルサーバーでも契約者がすることが多く、CMSの本体とプラグインはサイトの持ち主が、ライブラリやコンテナは開発した人が、機器は社内の担当か保守の会社が受け持ち⁠ま⁠す⁠。

いちばん抜けやすいのは、この「誰が」が空欄のところです。OSはサーバーの会社が更新してくれても、PHPの版は契約者が切り替えるまで古いまま、ということはよくあり⁠ま⁠す⁠。

新しい版⁠を⁠知⁠る

更新の知らせは、公式の告知で受け取るのが確実です。WordPressなら、管理画面の「ダッシュボード」の「更新」と公式のリリース一覧を、PHPなら公式のニュースとサポート期間のページを見ます。GitHubで公開されているソフトは、リポジトリの「Watch」で「Releases」と「Security alerts」を選んでおけば、通知が来ます。日本語でまとめて追うならJVNがあります。JPCERT/CCとIPAが運営していて、RSSでも受け取れます。サポート期間はendoflife.dateで調べられますが、有志のまとめ⁠で⁠す⁠。

日本語の報道は便利な反面、遅れたり、訳が原文と違ったりします。この半月に書いた記事でも、報道と一次情報の食い違いが何度もありました（WordPressの記事、OpenSSHの記事）。対応を決めるときは、原文を見てくだ⁠さ⁠い⁠。

手に⁠入⁠れ⁠る

ここからはエンジニア向けです。OSは、UbuntuやDebianならapt、AlmaLinuxやRocky LinuxのようなRHEL系ならdnf、Alpineならapkで、更新があるかを確かめてから入れ⁠ま⁠す⁠。

# Ubuntu / Debian
sudo apt update
apt list --upgradable
sudo apt upgrade

# AlmaLinux / Rocky Linux など
sudo dnf check-update
sudo dnf upgrade

# Alpine
apk update
apk upgrade

PHPとNode.jsのライブラリは、古くなった部品の一覧と既知の脆弱性を、次のコマンドで確かめます。更新したら、ロックファイル（composer.lockやpackage-lock.json）も一緒に記録し、本番ではロックファイルのとおりに入れ⁠ま⁠す⁠。

composer outdated
composer audit
npm outdated
npm audit

WordPressは管理画面の「更新」から更新できますが、サーバーでコマンドが使えるなら、WP-CLIでもできます。10月末に見つかった本体の欠陥では、修正版への更新そのものが一度だけ古い更新の処理で動きます。WordPress本体の欠陥と、更新の前にやることは、別の記事にまとめま⁠し⁠た⁠。

wp core version
wp core update
wp plugin update --all

レンタルサーバーのPHPは、多くの場合、コントロールパネルで版を切り替えます。版を上げると、古いプラグインやテーマが動かなくなることがあるので、次に書く試す環境で先に確かめてくだ⁠さ⁠い⁠。

本番に反⁠映⁠す⁠る

本番に入れる前に、ファイルとデータベースの両方のバックアップを取ります。WordPressの公式の手順も、更新の前のバックアップを勧めています（WordPress）。次に、試す環境（ステージング）で先に更新して、表示と、フォームや決済などの主な動きを確かめます。問題がなければ本番を更新し、再起動して、本番でもう一度確かめます。問題が出たら、バックアップから戻し⁠ま⁠す⁠。

見落とされがちなのが再起動です。パッケージを更新しても、動いているプログラムは、再起動するまで古いまま動き続けます。OpenSSHの欠陥のときも、更新したあとにsshdを再起動するよう注意が出ていました（OpenSSHの記事）。PHPなら、PHP-FPMやウェブサーバーの再起動が要り⁠ま⁠す⁠。

自動にできるところは、⁠自⁠動⁠に

手で更新するものが多いほど、どこかで止まります。WordPressの本体は、保守とセキュリティの修正にあたる小さな更新が、既定で自動です。大きな更新は、5.6以降に新しく入れたサイトなら既定で自動ですが、それより前から使っているサイトは、設定しないかぎり以前の動きのままです（WordPress）。プラグインとテーマは既定では自動で更新されず、5.5からは、プラグインの一覧の「自動更新」の列で一つずつ有効にできます。ホスティングの会社やプラグインがこの機能を止めていると、列そのものが出ません（WordPres⁠s⁠）⁠。

Ubuntuには、unattended-upgradesが最初から入っています。既定では、セキュリティの更新だけを1日に1回自動で入れますが、自動の再起動はしません（Ubuntu）。カーネルのように再起動が要る更新は、入っても、再起動するまで効かないということです。動いているかは、次のコマンドで試せ⁠ま⁠す⁠。

sudo unattended-upgrade -v --dry-run

GitHubで管理しているコードなら、Dependabotが、使っている部品に脆弱性が見つかったときに、直った版に上げるプルリクエストを自動で作ってくれます（GitHub Docs）。人は、確かめて取り込むだけになり⁠ま⁠す⁠。

ただ、自動の更新は、まれにサイトを壊します。自動にするなら、壊れたときにすぐ気づけて、戻せることが条件です。死活の監視とバックアップは、そのために要ります（2本目のサイトの乗っ取りに気づくための見張⁠り⁠）⁠。

サポート切れは、更新では直⁠ら⁠な⁠い

最後に、いちばん大事なことです。サポートが切れた版には新しい修正が出ないので、いくら更新を確かめても、直る版がありません。PHPは、2026年11月8日の時点で8.1以前のサポートがすでに終わっていて、8.2も2026年12月31日で終わります（PHP）。8.2で動いているサイトは、年内に8.3以降への移行を計画してくだ⁠さ⁠い⁠。

古いPHPから上げるときは、CMSやプラグイン、自作のコードが新しい版で動くかを、先に確かめる必要があります。ここは、更新というより小さな改修です。PHPの更新がまだのサイトに向けたPHP2Shellの現状と、いま確認することと、使っているものを書き出しておく理由になる2026年のCVE登録件数の急増の内訳は、それぞれ別の記事に書きました。更新の計画や、PHPの版の移行でお困りの方は、お問い合わせからご相談くだ⁠さ⁠い⁠。