Amazon Lightsail（非Bitnami）のWordPressでPHPを安全に更新する手順【Debian 12・Apache／PHP 8.2.35の事例】
2026年10月21日にPHPの重大な脆弱性（CVE-2026-109618／CVE-2026-109619）の修正版が公開されました。この記事は、Amazon LightsailのWordPress（Bitnamiではない構成）でPHPを更新するための実践ガイドです。筆者が2026年10月23日に行った更新（Debian 12・Apache・PHP 8.2.34から8.2.35）を事例にしています。
記事では、内容を次の2種類に分けて書いています。筆者の環境で確認していない点は、その箇所で「確認していません」と書きます。
- 【実施済み】筆者が実際に行い、確認できたこと
- 【推奨】AWS・PHP・Debianなどの公式資料に基づく一般的な手順（読者向けの実行例であり、筆者が入力したコマンドの全文ではありません）
この記事で解決できること
- 自分のLightsail環境が、この記事の手順で更新できる構成かを判断できる
- Bitnami構成か、非Bitnami構成かを見分けられる
- PHPのパッチ更新を、バックアップ→更新→再起動→確認の順で進められる
- 更新後も残る注意点（PHP 8.2のサポート終了、別の未修正CVE）を把握できる
最初に確認するチェック表
| 確認すること | 結果 | 次にすること |
|---|---|---|
判定の目安：/opt/bitnami/php/bin/php がなく、command -v php が /usr/bin/php | 非Bitnami（Lightsail提供のOSパッケージ版PHP）の可能性が高い。ただし、これだけでは断定できない | WebサーバーがどのPHPを使っているか（mod_phpかPHP-FPMか、設定ファイルの場所）も確認してから、この記事の手順（aptで更新）へ |
/opt/bitnami/php がある | Bitnami構成 | apt upgrade ではPHPは更新されません。AWSの手順（新インスタンスへの移行など）を参照 |
PHP 8.2〜8.5系で、php -v の版が 8.2.35／8.3.36／8.4.27／8.5.12 以上 | PHP本家の修正版以降。2件のCVE（109618／109619）の修正を含む | CVE-2026-115560の暫定設定を確認（下の行） |
| PHP 8.2〜8.5系で、上記の版未満 | 修正前の可能性が高い。ただしDebianなどは版番号を上げずに修正を取り込む場合があり、版番号だけでは断定できない | スナップショットを取り、apt-cache policy、パッケージのchangelog、Debian Security Trackerで修正の有無を確認してから更新 |
| PHP 8.1以下（7.4、8.0を含む） | PHP本家の更新は終了。ディストリビューション、LTSベンダー、第三者のリポジトリが修正を提供している場合がある | 提供元の案内で修正の有無を確認。PHP 8.2以上への移行も計画（この記事の手順は8.2系が対象） |
PHPが修正版でも session.upload_progress.enabled が有効 | 別のCVE（CVE-2026-115560）は未修正。ただし、影響は特殊な条件がそろった場合に限られる | 「CVE-2026-115560の影響条件と暫定対応」を参照 |
対象環境と対象外の環境
対象環境
- Amazon Lightsail上のWordPress。Lightsailが提供するブループリント（Bitnami製ではないもの）
- OSはDebian 12、WebサーバーはApache、PHPはOSのパッケージ管理（apt）から入れたもの
- SSHでログインでき、sudoが使える
【実施済み】筆者の環境はLightsail、Debian 12、Apache、BitnamiではないWordPressです。
対象外
- Bitnami版のブループリント（PHPが
/opt/bitnami/phpにあり、apt upgradeでは更新されません） - Nginx構成（再起動するサービス名が異なります。AWSの手順を参照してください）
- Windows Serverインスタンス
- PHPのメジャー／マイナーバージョンを上げる作業（8.2から8.3など）。この記事はパッチ更新のみを扱います
Bitnamiか非Bitnamiかの確認
【推奨】SSH接続して次のコマンドを実行します。読み取りだけで、環境は変更されません。
cat /etc/os-release | head -n 3
ls -d /opt/bitnami 2>/dev/null && echo "bitnami directory exists" || echo "no bitnami directory"
ls -l /opt/bitnami/php/bin/php 2>/dev/null || echo "no Bitnami PHP binary"
command -v php
php -v
apache2 -vAWSの案内では、Bitnamiのブループリントは /opt/bitnami/php に独自のPHPを持ち、apt upgrade では更新されません。判定の目安は、/opt/bitnami/php/bin/php があるか、command -v php がどのPHPを指すかです。/opt/bitnami ディレクトリの有無だけでは判断できない場合があります。AWSがBitnami環境向けに案内する代替手順（OSパッケージのPHPを併用してBitnamiのWebサーバーから使う）を実施した環境では、Bitnamiの構成のまま /usr/bin/php が使われる場合があります。Bitnamiの可能性がある場合は、WebサーバーがどのPHPを使っているかを確認するまで、この記事の手順を実行しないでください。
また、LightsailのBitnami WordPressの扱いは時期によって変わり得ます。筆者の別記事（Luxeritas + WordPress 移行作業まとめ）では、Bitnami環境からLightsailのネイティブ（Debian + Apache2）環境へ移行した経緯を書いています。古い記事（Amazon Lightsail WordPressのPHPバージョンアップ、2023年）はBitnami構成の移行手順で、今回の方法とは別物です。
WordPress更新とPHP・OS更新の違い
| 対象 | 更新する場所 | 主な手段 |
|---|---|---|
| WordPress本体・プラグイン・テーマ | WordPressの管理画面（またはWP-CLI） | ダッシュボードの更新 |
| PHP（ランタイム） | OS（Debian）のパッケージ | aptでSSH接続して更新 |
| Apache、OSのその他のパッケージ | OS（Debian）のパッケージ | apt |
WordPressの管理画面で「最新です」と表示されても、PHPは更新されていません。今回のようなPHP本体の脆弱性は、WordPress側の更新では直りません。
更新前の確認とバックアップ
【推奨】AWSの手順では、変更前にインスタンスのスナップショットを作成することが先頭の手順です。更新に失敗した場合は、スナップショットから新しいインスタンスを作成してサイトを復元できる、と説明されています。
【実施済み】筆者は、PHPを更新する前に、Lightsailのスナップショットを取得しました。このスナップショットは、約1週間後に削除しました。
- スナップショットの復元は新しいインスタンスの作成になります。静的IPの付け替えなど、復旧に手間がかかる点を理解しておいてください
- 更新前に現在のバージョンと更新対象を控えておくと、後で比較できます
- 本番環境での作業になるため、アクセスの少ない時間帯を選び、Apacheの再起動で数秒〜の接続断が起こり得ることを想定してください
# 更新前の記録（読み取りのみ）
php -v
apt-cache policy php8.2-common
apt list --upgradable 2>/dev/null | grep -i php
df -h /
free -mapt-cache policy php8.2-common は、候補バージョンと、そのパッケージの取得元を表示します。取得元がDebianの security.debian.org かどうか、別のリポジトリ（サードパーティなど）が混ざっていないかをここで確認できます。
参考までに、Debian Security Trackerには、bookworm-securityのphp8.2として 8.2.35-1~deb12u1 が記載されています（2026年11月1日確認）。AWSの案内では、Lightsailが提供するWordPress／LAMPブループリントは、PHPをOSのパッケージリポジトリから入れる構成です。ただし、筆者の環境でPHPがどのリポジトリから入ったかは、この記事では確認していません。apt-cache policy の出力で、候補バージョンの取得元（Debianのセキュリティリポジトリか、別のリポジトリか）を確認してください。
版番号だけで、脆弱と断定しないでください。PHP公式の情報は「8.2.35より前」のように本家の版番号で書かれていますが、OSによっては版番号を上げずに修正だけを取り込む場合があります。OSのパッケージでは、changelogやセキュリティ情報で、修正が入っているかを確認します。
# パッケージのchangelogに、修正されたCVEが書かれているか（Debianの例。出力は環境で異なる）
apt changelog php8.2-common | grep -n -i -E "CVE-2026-109618|CVE-2026-109619"changelogを取得できない場合は、Debian Security Trackerで、bookwormの状態を確認します。
実際に行ったPHP更新手順
【実施済み】今回の更新で、筆者が行ったことは次のとおりです。
- 環境：Amazon Lightsail、Debian 12、Apache、BitnamiではないWordPress
- PHPを8.2.34から8.2.35へ更新
- 更新にはaptを使用
- 更新対象に
php8.2-common、php8.2-mysql、php8.2-zip、php8.2-opcache、php8.2-mbstringなどが含まれた - Apacheを再起動した
- OS（サーバー）の再起動はしていない
- PHPを更新する前に、Lightsailのスナップショットを取得し、約1週間後に削除した
session.upload_progress.enabled=0の設定変更は、今回の更新作業では行っていない
筆者が行ったのは、aptでのPHPの更新と、Apacheの再起動です。以下は、読者向けの実行例です。AWSの公式手順に沿った推奨手順であり、筆者が実際に入力したコマンドの全文を示すものではありません。
手順（推奨）
- Lightsailコンソールでスナップショットを作成する
- SSHで接続する
- 更新対象を確認し、パッケージ情報を更新してアップグレードする
- Apacheを再起動する
- バージョンを確認する
# 3. 更新
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt upgradesudo apt upgrade はPHP以外のパッケージも更新します。AWSの手順もこのコマンドを案内していますが、更新対象の一覧を見てから実行すると、意図しない更新（カーネルなど）に気づけます。確認の途中で設定ファイルの上書きを聞かれた場合は、既存の設定を維持する選択肢が安全なことが多いです。判断がつかないときは中断して調べてください。
# 4. Apacheの再起動（Lightsail提供のWordPress/LAMPブループリントでのAWS案内）
sudo apache2ctl configtest
sudo systemctl restart apache2
# 5. バージョン確認
php -vAWSの案内では、表示されるバージョンが修正版（8.2系なら8.2.35）かそれ以降であることを確認します。configtest はApacheの設定構文を確認する一般的なコマンドで、AWSの手順には含まれていません。
PHP-FPMを使っている場合の再起動
AWSの案内は、Lightsail提供のWordPress／LAMP（Apache）では apache2 の再起動、Nginxでは php8.2-fpm の再起動です。ApacheでPHP-FPMを併用する構成は、AWSの手順に明記がありません。FPMを使っている場合は、FPMのワーカーが更新後のPHPを使う必要があるため、sudo systemctl restart php8.2-fpm も必要になります（PHP公式のGHSAも、設定変更の反映には全ワーカーの再起動を求めています）。パッケージの更新時にサービスが自動で再起動される場合もあるため、更新後に systemctl status で稼働状況を確認してください。mod_phpかFPMかは、apache2ctl -M | grep -i -E "php|proxy_fcgi" や systemctl is-active php8.2-fpm で確認できます。
OS（カーネル）の再起動は必要か
PHPのパッケージだけを更新した場合、OSの再起動は通常不要で、Apache（またはFPM）の再起動で足ります。ただし、sudo apt upgrade はPHP以外も更新します。カーネルなどが同時に更新された場合、新しいカーネルは再起動するまで使われません。OSを再起動すると、SSHが切れ、サイトが一時的に停止します。【実施済み】今回、筆者はOSの再起動をせず、Apacheの再起動だけを行いました。ただし、読者の環境では、apt upgrade の内容によってOSの再起動が必要になる場合があります。再起動の要否を確認する例を示します。
# 稼働中のカーネルと、インストール済みのカーネルイメージ
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
# 再起動が必要なことを示すファイル（環境によっては作られない）
ls -l /var/run/reboot-required 2>/dev/null || echo "reboot-required file not found"稼働中のカーネルより新しいカーネルイメージが入っていれば、アクセスの少ない時間帯に再起動を検討します。
更新後のPHP・Apache・WordPress確認
【実施済み】筆者はApacheの再起動を実施しました。【推奨】以下は、読者向けの推奨の確認項目です。
# PHP（コマンドライン版）
php -v
# PHPパッケージの状態
dpkg -l | grep php8.2
# Apacheの状態とエラーログ
sudo systemctl status apache2 --no-pager
sudo tail -n 50 /var/log/apache2/error.log
# PHPをApacheに組み込む方式（mod_php）か確認
apache2ctl -M | grep -i phpphp -vはコマンドライン版PHPのバージョンです。Webサーバーが使うPHPと同じ版とは限りません。apache2ctl -Mにphpのモジュールが出ればmod_php、出なければPHP-FPMなど別方式の可能性があります。FPM方式ならphp8.2-fpmの再起動も必要です- WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、PHPバージョンとサーバーAPIを確認できます（AWSもBitnamiの手順で同じ確認方法を案内）
- サイトのトップページ、管理画面ログイン、記事の保存、画像アップロードなどを実際に操作して確認する
更新できない場合の切り分け
| 症状 | 確認すること |
|---|---|
apt upgrade でPHPが更新対象に出ない | apt-cache policy php8.2-common で候補バージョンと取得元を確認。すでに修正版か、リポジトリがDebianの更新を取得できていない可能性。apt update でエラーが出ていないかも確認 |
apt がロックされている／途中で止まる | 別のaptプロセスが動いていないか。df -h で空き容量、free -m でメモリを確認 |
php -v は新しいが、サイトの挙動が変わらない／古いままに見える | Apacheを再起動したか。mod_phpかPHP-FPMかを確認（FPMなら php8.2-fpm も再起動）。WordPressのサイトヘルスで実際のPHPバージョンを確認 |
| 更新後にサイトが表示されない | Apacheのエラーログ（/var/log/apache2/error.log）を確認。プラグインやテーマの互換性問題の切り分けは、管理画面が使えるか、プラグインを停止して試す |
/opt/bitnami がある | Bitnami構成の手順に切り替える（AWSの案内を参照） |
| SSHが応答しない | Lightsailのメモリ不足の可能性。筆者の過去記事（Lightsail上のWordPressサイトがSSHごと無応答になった件）を参照 |
復旧が必要な場合、スナップショットから新しいインスタンスを作る方法がAWSの案内にあります（静的IPの付け替えなどが必要）。
今回の脆弱性への対応範囲
| 項目 | 内容 | 出典 |
|---|---|---|
| CVE-2026-109618／CVE-2026-109619 | 2026年10月21日公開のPHP 8.2.35（ほか8.3.36、8.4.27、8.5.12）で修正。認証なしのリモートコード実行につながる可能性があるとされ、完全な回避策はなく更新が唯一の確実な対応と説明されている | PHP公式、AWS公式 |
| CVE-2026-115560 | 2026年10月23日にPHPが情報アドバイザリを公開。8.2.35を含む上記の版では修正されていない。PHP公式は、完全なアドバイザリを次のリリースで公開するとしている。条件と暫定対応は、この表の下で説明 | PHP公式、AWS公式 |
| Windows向けビルド | 10月26日にBrotliのセキュリティ修正のためWindows向けビルドが再公開された。Linuxのaptには無関係 | PHP公式 |
PHP 8.2.35に更新しただけで、すべての脆弱性が解決したとは言えません。少なくともCVE-2026-115560は未修正で、今後も修正版が出る可能性があります。
CVE-2026-115560の影響条件と暫定対応
PHP公式の情報アドバイザリ（2026年10月23日）は、これを可能性の低いRCE経路として扱い、次の定期バグフィックスリリースまで session.upload_progress.enabled=0 にすることを勧めています。公式の説明では、問題が起きるのは、設定とアプリケーションのコードが特殊な組み合わせになっている場合だけです。次の条件がすべてそろう場合です。
- アプリケーションが、設定で
session.serialize_handlerをphp_binaryまたはphp_serializeにしている - そのうえで、実行時に
ini_set()でphpに切り替えている - 切り替えたあとに
session_start()を呼ぶ - セッションのアップロード進捗（
session.upload_progress.enabled）が、まだ有効になっている
公式は、実行時にシリアライズハンドラを変更しないアプリケーションでは、この機能を有効のままでよいとしています。PHPマニュアルでは、session.serialize_handler の既定値は php、session.upload_progress.enabled の既定値は 1（有効）です。したがって、既定の設定のままで、コードも実行時に変更しない構成は、通常この条件に当たりません。ただし、利用中のプラグインやテーマが ini_set() で session.serialize_handler を変更していないかは、この記事では確認していません。
なお、session.upload_progress.enabled=0 は、10月21日のCVE-2026-109619のアドバイザリ（GHSA）でも緩和策として挙げられており、すでに適用している場合は、追加の対応は不要と公式は述べています。この設定を無効にすると、アップロード進捗を使うアプリケーションは、進捗を取得できなくなります。
確認と設定変更は別の作業です
【推奨】最初のコマンドは、読み取りだけの確認です。設定の変更は本番の設定ファイルを書き換える作業なので、スナップショットを取り、内容を理解したうえで行ってください。【実施済み】筆者は、今回のPHP更新の作業では、この設定変更を行っていません。以下は、前述の影響条件に当たる環境向けの参考手順です。
# 確認（読み取りのみ）
# 1. 使っているPHP SAPIの確認（mod_phpなら php_module、FPMなら proxy_fcgi などが見える）
apache2ctl -M | grep -i -E "php|proxy_fcgi"
systemctl is-active php8.2-fpm
# 2. 設定ファイルの場所（DebianではSAPIごとに分かれていることが多い）
ls -d /etc/php/8.2/*/
# 3. 現在の設定（conf.d以下も含む）
grep -rn "session.upload_progress.enabled" /etc/php/8.2/
grep -rn "session.serialize_handler" /etc/php/8.2/Debianの一般的な構成では、設定は /etc/php/8.2/apache2/（mod_php）、/etc/php/8.2/fpm/（PHP-FPM）、/etc/php/8.2/cli/（コマンドライン）に分かれています。Webに効くのは、実際に使っているSAPIのディレクトリだけです。cli を変更しても、Webには影響しません。conf.d 以下に同じ設定があると php.ini の値を上書きするため、grepの結果で確認します。
変更する場合は、使っているSAPIの php.ini をバックアップしてから編集し、反映のためにサービスを再起動します。【推奨】次は、mod_php（Apache）の場合の例です。FPMなら apache2 を fpm に、再起動するサービスを php8.2-fpm に読み替えます。
# 設定変更の例（本番の設定を書き換える。スナップショット後に実施）
sudo cp -a /etc/php/8.2/apache2/php.ini /etc/php/8.2/apache2/php.ini.bak
sudo nano /etc/php/8.2/apache2/php.ini
# session.upload_progress.enabled = 0 （行がなければ追記）
# 反映（mod_phpの場合はApache。FPMの場合は php8.2-fpm）
sudo apache2ctl configtest
sudo systemctl restart apache2
# 反映確認（CLIによる近似確認。稼働中のWebワーカーの設定値を直接確認するものではない）
# そのSAPIの設定ファイルをCLIのPHPに読み込ませ、値を見る
PHP_INI_SCAN_DIR=/etc/php/8.2/apache2/conf.d php -c /etc/php/8.2/apache2/php.ini -r 'var_dump(ini_get("session.upload_progress.enabled"));'最後のコマンドは、CLIのPHPに、そのSAPIの設定ファイルを読み込ませる近似確認です。稼働中のWebワーカー（ApacheやPHP-FPM）が実際に使っている設定値を、直接確認するものではありません。設定ファイルに意図した値が書かれているかの確認にとどまります。再起動を忘れると、稼働中のPHPには反映されません。公開ディレクトリに phpinfo() を置く方法は、情報が外部から見える危険があるため、この記事では勧めません。
IPAは10月21日付の事前注意喚起で、PHPを利用するシステムの棚卸しと、修正プログラムをすみやかに適用できる準備を求めています（その時点でIPAは悪用を確認していないと記載）。最新の状況は各公式ページで確認してください。
PHP 8.2サポート終了に向けた今後の方針
| 項目 | 日付 | 出典 |
|---|---|---|
| PHP 8.2 アクティブサポート終了 | 2024年12月31日 | PHP公式 |
| PHP 8.2 セキュリティサポート終了 | 2026年12月31日 | PHP公式 |
| PHP 8.3 セキュリティサポート終了 | 2027年12月31日 | PHP公式 |
| PHP 8.4 セキュリティサポート終了 | 2028年12月31日 | PHP公式 |
| Debian 12 bookworm 通常サポート終了 | 2026年7月11日まで（Debianのリリース情報）。LTSチームへの引き継ぎ告知は2026年7月12日付 | Debian公式（リリース情報、ニュース） |
| Debian 12 bookworm LTS終了 | 2028年6月30日まで。LTSの対象アーキテクチャは限られる（i386、amd64、armhf、arm64、ppc64el）。uname -m で自分の環境を確認 | Debian公式（リリース情報、LTSのwiki） |
PHP 8.2本家のセキュリティサポートは2026年12月31日までです。これは、Debian 12のphp8.2パッケージの保守の終了日ではありません。今回の修正も、Debianは「DLA-4848-1」（2026年10月21日、php8.2、bookwormの修正版 8.2.35-1~deb12u1）として案内しており、Debian 12の通常サポート終了後も、LTSチームがPHPの修正を提供している実例といえます。Debian 12のLTSは2028年6月30日までです。
ただし、PHP本家の保守が終わったあとの脆弱性に、Debianが今後も修正を提供し続けるかは、保証されません（個々の脆弱性ごとにDebianが判断します）。移行は推奨しますが、移行までの間は、Debian Security Trackerでphp8.2のbookwormの状態を確認してください。
今後の方針は次のとおりです。
- 移行は推奨です。PHP本家の保守が終わる2026年12月31日までに、移行先（PHP 8.3または8.4）を決めておきます。あわせて、OS側（Debian）の修正提供状況を、Security Trackerのbookwormの状態で確認します。移行先がDebian 12標準のPHP 8.2ではない場合、別のリポジトリ（AWSの手順ではSuryのリポジトリを案内、AWSの管理外のサードパーティ）か、新しいDebianのブループリントへの移行が選択肢になる
- 移行前にステージング環境（スナップショットから作った検証用インスタンス）でWordPress本体、テーマ、プラグインのPHP互換性を確認する
- 移行までの間も、aptのセキュリティ更新は継続して適用する
出典
- PHP公式：2026年のニュース（10月21日のセキュリティアドバイザリ、10月23日の情報アドバイザリ、10月26日のWindowsビルド更新）
- PHP公式：サポートされているバージョン
- PHP 8.2.35 リリース（php-src）
- AWS公式：Update PHP on Lightsail instances to address CVE-2026-109618 and CVE-2026-109619
- IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について
- Debian公式：Security support for Bookworm handed over to the LTS team
- Debian Security Tracker：CVE-2026-109618
- Debian LTS Announce：DLA-4848-1 php8.2
- php-src GitHub Advisory：CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）
- Debian公式：Debian 12 bookwormのリリース情報（サポート期間）
- Debian Wiki：LTS
- PHPマニュアル：セッションの実行時設定
※本記事の確認日は2026年11月1日です。各公式ページの内容は更新される場合があります。【実施済み】の記述は筆者本人が確認した作業内容に基づいており、コマンドの出力は掲載していません。