PHP の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）に Ubuntu 24.04 のサーバーで対応した

2026 年 10 月 21 日、PHP の開発チームがログインなしで外部からプログラムを実行される脆弱性 2 件を修正したバージョンを公開しました。WordPress を動かしている自分のサーバー（Ubuntu 24.04、Apache の mod_php）も対象だったので、確かめ方と更新の手順を残しておきます。

脆弱性の内容

PHP の開発チームの発表によると、修正版は PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。2 件とも、認証なしでリモートからコードを実行できる脆弱性で、開発チームはすべての利用者にすぐ更新するよう呼びかけています。

CVE 番号内容
CVE-2026-109618メモリー不足の処理で、途中までしか用意できていない内部のデータを、正しいデータとして扱ってしまう
CVE-2026-109619使い終わったはずの内部の状態が残り、同じプロセスが次に処理するリクエストで使われてしまう

対象は Web のリクエストを処理しているすべての PHP です。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が挙げられています。中でも mod_php がもっとも危険とされていて、ログインしていない人のリクエストで、アプリケーションのコードが動く前に攻撃できることが確かめられています。

アプリケーションのコードが動く前に攻撃できるので、WordPress 本体やプラグインを更新しても直りません。直すには PHP を更新します。

自分のサーバーが対象かを確かめる

Ubuntu の PHP はセキュリティの修正を入れても本体の番号を変えず、パッケージの番号の末尾を上げて配布します。そのため、php -v を実行すると更新の前も後も「8.3.6」と表示されます。対象かどうかはパッケージの番号で確かめます。

Ubuntu のセキュリティ情報（USN-8948-1 と、CVE ごとのページ）によると、次のバージョンで修正されています。

Ubuntuパッケージ修正されたバージョン
22.04 LTSphp8.18.1.2-1ubuntu2.28
24.04 LTSphp8.38.3.6-0ubuntu0.24.04.13
26.04 LTSphp8.58.5.4-0ubuntu1.5

入っているパッケージのバージョンは、次のコマンドで表示できます。

dpkg -l 'php8.3*' libapache2-mod-php8.3 | awk '/^ii/{print $2, $3}'

自分のサーバーは 8.3.6-0ubuntu0.24.04.12 で、修正の 1 つ前でした。libapache2-mod-php8.3 が入っているので、もっとも危険とされる mod_php の構成です。php8.3-imagick は別のパッケージなので、番号の付け方が違います。

修正版がすぐには届かなかった

USN-8948-1 が出たあとに apt update を実行しても、修正版は表示されませんでした。apt-cache policy で見ると、取得できる最新のバージョン（Candidate）が .12 のままです。

Ubuntu のパッケージを公開している Launchpad では、.13 は日本時間 22 時 41 分に公開済みになっていました。一方で、security.ubuntu.com のパッケージの一覧は 23 時 30 分の時点でも作り直されておらず、.12 のままでした。公開の手続きと、配布用の一覧の更新との間に、時間差があったようです。

しばらく待ってから apt update をやり直すと、noble-security の行が「Hit」から「Get」に変わり、新しい一覧を取得できました。最後に「13 packages can be upgraded」と表示されます。

apt update で noble-security の行が「Hit」のままで、Candidate も古いままなら、まだ一覧が更新されていません。時間をおいてやり直してください。待っている間は、後の「修正版が届くまでの緩和策」を入れておくと安心です。

更新する

次のコマンドで更新します。PHP 以外のパッケージもまとめて上げてかまわなければ、apt upgrade だけで済みます。

sudo apt update
sudo apt upgrade

PHP のパッケージだけを上げる場合は、入っているものを指定します。

sudo apt install --only-upgrade libapache2-mod-php8.3 php8.3 php8.3-cli php8.3-common php8.3-curl php8.3-gd php8.3-intl php8.3-mbstring php8.3-mysql php8.3-opcache php8.3-readline php8.3-xml php8.3-zip

13 個のパッケージが 8.3.6-0ubuntu0.24.04.13 に更新されました。画像ではダウンロードと展開の行を省いています。

出力の最後では、needrestart が「Restarting services...」と表示していて、あとに回されたサービスは unattended-upgrades だけでした。ただ、mod_php は Apache のプロセスの中で動くので、Apache が古い PHP を読み込んだまま動いていないよう、Apache も再起動しておきます。

sudo systemctl restart apache2

更新できたかを確かめる

パッケージのバージョンがすべて 8.3.6-0ubuntu0.24.04.13 になっていれば完了です（php8.3-imagick は除きます）。

dpkg -l 'php8.3*' libapache2-mod-php8.3 | awk '/^ii/{print $2, $3}'

Apache が更新の後に起動し直したかは、起動した時刻で確かめられます。

systemctl show apache2 -p ActiveEnterTimestamp

自分のサーバーでは、すべてのパッケージが .13 になり、Apache の起動時刻も更新の後になっていました。

最後に、サイトがふつうに表示されるかを確かめます。

修正版が届くまでの緩和策

修正版がまだ届かない場合や、すぐに更新できない場合のために、PHP の開発チームは攻撃の経路を減らす設定も示しています。ただし、これで安全になるわけではなく、完全に直すには更新しかないとしています。

開発チームはアプリケーションの ini_set() などで上書きされない場所に設定するよう求めています。WordPress は ini_set() でメモリーの上限を変えるので、mod_php では Apache の設定に php_admin_* で書きます。

sudo tee /etc/apache2/conf-available/php-cve-2026-10-mitigation.conf > /dev/null <<'EOF'
# CVE-2026-109618 / 109619 の緩和策（PHP の公式の勧告より）。修正版に更新したら外す
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 32M
    php_admin_value upload_max_filesize 30M
</IfModule>
EOF
sudo a2enconf php-cve-2026-10-mitigation
sudo apachectl configtest && sudo systemctl restart apache2

session.upload_progress.enabled を off にすると、CVE-2026-109619 の確認されている攻撃の経路をふさげます。post_max_size は CVE-2026-109618 向けの設定で、ファイルのアップロードが必要なサイトでは 32M が示されています。upload_max_filesize は、post_max_size より小さくします。

勧告には memory_limit を -1（上限なし）にする方法もあります。ただ、重い処理でサーバーのメモリーを使い切るおそれがあり、勧告でもコンテナや cgroup でメモリーに上限をかけることをすすめています。入れるかどうかはサーバーの環境に合わせて判断してください。

修正版に更新したら、この設定は外してかまいません。

sudo a2disconf php-cve-2026-10-mitigation && sudo systemctl restart apache2

参考

PHP を使わない CMS の EmDash については、EmDash 日本語ガイドのお知らせで紹介しています。

スポンサーリンク

コメント

タイトルとURLをコピーしました