2026年10月21日にPHP8.3.36が公開されました。今回のリリースでは、未認証の攻撃者によるリモートコード実行につながる重大な脆弱性が修正されています。IPAも注意喚起をしており、主要サービスやゲームサービスが緊急メンテナンスを行うなど、影響範囲がかなり大きい内容です。
自分のブログもDocker上でWordPressを動かしており、PHPのバージョンを確認すると8.3.32でした。脆弱性修正版にアップデートしなければと思い、バックアップを取り、WordPressコンテナのイメージを差し替えることにしました。
意外とすんなりとPHPを8.3.36に更新でき、WordPressのバージョンは7.1.3のまま維持できました。サイトが正常に表示されることまで確認できたので、今回の作業を記録しておきます。このようなバージョンアップの際に、docker環境だとバックアップや管理、設定が楽だなと感じます。
ポチップ
Contents
更新前の環境
今回の環境は次のとおりです。
| 項目 | 更新前 |
|---|---|
| Webサイト | WordPress |
| WordPressのバージョン | 7.1.3 |
| PHPのバージョン | 8.3.32 |
| WordPressのDockerイメージ | wordpress:7.0-apache |
| データベース | MariaDB 12.3 |
| コンテナ管理 | Docker Compose |
| HTTPS・アクセス制御 | Cloudflare |
少しややこしかったのが、Dockerイメージのタグはwordpress:7.0-apacheなのに、実際のWordPress本体は7.1.3だったことです。
WordPressのファイルは名前付きボリュームに保存しているため、コンテナのイメージタグと、ボリューム内にあるWordPress本体のバージョンが一致していませんでした。WordPressの自動更新機能で内部でバージョンアップをしていたようです。
今回は、すでに動いているWordPressを維持しながら、PHPの脆弱性に対応する方針にしました。
まずは現在のバージョンを確認
最初に、稼働中のコンテナでPHPのバージョンを確認します。
docker exec wp php -v実行結果はPHP8.3.32でした。
続いて、WordPress本体のバージョンも確認します。
docker exec wp php -r 'include "/var/www/html/wp-includes/version.php"; echo $wp_version, PHP_EOL;'こちらは7.1.3でした。
イメージのタグだけを見て更新方法を決めるのではなく、実際に動いているPHPとWordPress本体の両方を確認しておきましょう。
作業前にバックアップを取得
更新に失敗した場合に備えてバックアップを取得しました。
MariaDBのバックアップ
次のコマンドで全データベースをダンプします。
docker exec mariadb sh -c 'mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --all-databases --single-transaction --routines --triggers' \
> ~/wp-backup-$(date +%Y%m%d-%H%M%S).sqlバックアップファイルは約29MBでした。
WordPressのデータをバックアップ
続いて、WordPressの名前付きボリュームを圧縮して保存します。
docker run --rm \
-v wp_wordpress_data:/data:ro \
-v "$HOME":/backup \
alpine \
tar czf /backup/wp-wordpress-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .私の環境では5分ほどかかりました。今回のバックアップファイルは約294MBでした。
wp_wordpress_dataは今回の環境で使用しているボリューム名です。環境によって名前は異なるため、事前にdocker inspect wpなどで実際のボリューム名を確認してください。
コンテナの設定も保存しました。
docker inspect wp > ~/wp-container-inspect-before-update.json
docker inspect mariadb > ~/mariadb-container-inspect-before-update.jsonデータだけでなくコンテナの設定も残しておくと、トラブル発生時に変更前の状態を調べやすくなります。
なお、今回のバックアップはサーバー内に保存したものです。サーバー自体の故障や削除に備えるなら、バックアップを別のサーバーや手元のストレージにもコピーしておくと安心です。
ポチップ
新しいDockerイメージでPHPのバージョンを確認
本番コンテナを更新する前に、PHP8.3.36を含む新しいWordPressイメージを仮で作成して動作確認しました。
今回使用したのはwordpress:7.1.3-php8.3-apacheです。
docker run --rm wordpress:7.1.3-php8.3-apache php -v実行結果は次のとおりでした。
PHP 8.3.36 (cli) (built: Oct 21 2026 15:57:18) (NTS)
Zend Engine v4.3.368.3.36以降であれば今回の脆弱性に対応しているバージョンです。
いきなり本番環境を変更するのではなく、先にイメージ単体で起動してバージョンを確認しておくと安心です。
Docker Composeのイメージ設定を変更
使用するイメージを確認できたので、docker-compose.ymlを編集します。
変更したのはWordPressサービスのimageだけです。
変更前：
image: wordpress:7.0-apache変更後：
image: wordpress:7.1.3-php8.3-apache変更を保存したら、設定ファイルに問題がないか、反映前に確認します。
docker compose configWordPressのイメージ設定だけを確認する場合は、次のコマンドも使えます。
docker compose config | grep -A3 -B3 'image: wordpress'先ほど設定したイメージ名が表示されたので、以下のコマンドでWordPressサービスを更新します。
docker compose up -d wordpress実行結果ではWordPressコンテナが再作成され、MariaDBコンテナは稼働を継続していました。データベース側の設定やイメージは変更していません。
更新後のバージョンを確認
コンテナが起動したら、最初にDockerの稼働状態を確認します。
docker psWordPressコンテナが起動していることを確認できました。
続いてPHPのバージョンを確認します。
docker exec wp php -v結果はPHP8.3.36でした。
WordPress本体も、変更なく7.1.3のままです。
docker exec wp php -r 'include "/var/www/html/wp-includes/version.php"; echo $wp_version, PHP_EOL;'7.1.3これで、今回変更したかったPHPのバージョンだけを更新できました。
サイトが正常に表示されるか確認
実際にHTTPアクセスして応答を確認します。
まず、サーバー内部からApacheにアクセスします。
curl -I http://127.0.0.1/結果はHTTP/1.1 200 OKでした。
レスポンスには次の情報も含まれていました。
HTTP/1.1 200 OK
Server: Apache/2.4.69 (Debian)
X-Powered-By: PHP/8.3.36
Content-Type: text/html; charset=UTF-8Apacheが起動し、PHP8.3.36でWordPressから応答を返せていることを確認できました。
ブラウザでアクセスした際も正常に本文や画像が表示されていました。
今回の作業で気を付けたこと
更新作業には事前のバックアップと影響範囲を把握しておくことが大切だと思いました。
Docker環境ならイメージを差し替えるだけで簡単にバージョンを上げられますが、切り戻せるバックアップを作成しておくことと何に影響が及ぶのか（アプリ側だけなのか、バックエンドなのか）を理解しておくとスムーズです。
