PHP の 2026 年 10 月の重大な修正を Mac で：Homebrew、MacPorts、MAMP、Server.app、そしてファイアウォール

公開 2026-10-22

2026 年 10 月 21 日 14:00（UTC）、PHP プロジェクトは前日の事前告知どおり、PHP 8.5.12、8.4.27、8.3.36、8.2.35 をリリースしました。修正されたのは、認証なしのリクエストでサーバ上のコードを実行されるおそれがある 2 件の重大な脆弱性で、いずれも CVSS v4.0 で 9.2 と評価されています。php.net の表現ははっきりしています。完全な緩和策はなく、アップデートだけが安全な選択肢です。

多くの解説は Linux のホスティングを前提にしています。ディストリビューションのパッケージが届き、それを入れれば済むという前提です。Mac では事情が違います。いま修正済みかどうかは PHP をどこから入れたかで決まり、本稿執筆時点（2026 年 10 月 22 日）では、Homebrew、MacPorts、MAMP、Apple 標準の PHP でそれぞれ答えが異なります。本稿ではそれぞれを順に確認し、最後にその手前にあるファイアウォールを取り上げます。

2 件の脆弱性

• CVE-2026-109618（GHSA-w8hw-w9fx-j79w）：メモリ不足の処理によって、リクエストのデータが一部しか初期化されていない状態で PHP が中断されることがあり、その後の後片付けで不正なデータが正しいものとして扱われます。
• CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）：あるリクエストに属する状態がメモリの解放後も残り、同じワーカで処理される後続のリクエストに使われることがあります。

Web リクエストを処理するすべての PHP が影響を受けます。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed です。php.net が最も危険度が高いとしているのは mod_php で、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立することが実証されています。自分のコードやプラグイン、ログイン画面は防壁になりません。

PHP 8.1 以前には公式のリリースはありません。ソースからビルドする人向けに、セキュリティチームは 7.4、8.0、8.1 への最小限のバックポートを php-src のブランチとして公開しています（例：PHP-8.1-CVE-2026-109618-109619）。7.4 より古いバージョンにはありません。

Homebrew：修正済み、ただし PHP-FPM の再起動を

Homebrew は 10 月 21 日に新しいリリースをパッケージにしました。php は 8.5.12、[email protected]、[email protected]、[email protected] はそれぞれ 8.4.27、8.3.36、8.2.35 です。brew upgrade php（または brew upgrade [email protected] など）で修正が入ります。Homebrew の自動更新をオフにしている場合は、先に brew update を実行してください。

• アップグレード後は PHP-FPM を再起動します。2 件のうち 1 件は長時間動き続けるワーカの中にあり、アップグレード前に起動したワーカは古いコードのまま動き続けます。brew services restart php（または [email protected]）を実行し、Apache が PHP をモジュールとして読み込んでいる場合は Apache も再起動します。
• 入っている PHP をすべて確認します。複数の formula が入っていることはよくあります。brew list --versions | grep php ですべて表示されます。それぞれにアップグレードと再起動が必要です。
• [email protected] には修正がありません。Homebrew では非推奨（deprecated）とされ、8.1.34 のままです。そのサイトはサポート中のブランチへ移してください。
• Intel Mac ではソースからビルドされます。本稿執筆時点で、これらのリリースに Homebrew がビルド済みの bottle を用意しているのは Apple シリコンの Mac だけです。Intel Mac ではアップグレード時に PHP をコンパイルするため時間がかかり、Apple のコマンドラインツールも必要です。

MacPorts：アップグレードすれば修正済み

MacPorts は 10 月 22 日に修正版を公開しました（php85 8.5.12、php84 8.4.27、php83 8.3.36）。port install はインストール済みのポートを古いバージョンのまま残すので、明示的にアップグレードします。

sudo port selfupdate
sudo port upgrade outdated
sudo port reload php84-fpm

-fpm のポートは使っているブランチに合わせてください。再読み込みが必要な理由は Homebrew と同じです。入っているものは port installed | grep php で確認できます。

MAMP：MAMP のアップデートを待つ

MAMP は独自にビルドした PHP を同梱しています。Homebrew や MacPorts から来たものではなく、MAMP がアップデートを出したときにだけ変わります。それまでは、提供している PHP のバージョンごとに MAMP が使う php.ini に暫定設定を入れ、MAMP のサーバを再起動してください。MAMP を自分の Mac での開発にだけ使っているなら影響は小さく、ネットワークやインターネットに Web サイトを公開しているなら、ほかのサーバと同じように扱ってください。

Apple の PHP と Server.app：修正は来ない

Apple の Server.app を今も動かしている古い Mac（macOS 10.13 世代）は、Apple の PHP 7.1 を mod_php として Apache に読み込み、Web サイトを提供しています。今回の勧告が示す中で最悪の組み合わせです。最も危険な PHP の動かし方であるうえ、バージョンが古すぎて、7.4 から始まるソースのバックポートすらありません。Apple が更新することもありません。（macOS 12 以降の Mac には PHP 自体が含まれていません。）

対処は、Web サイトを Apple の PHP の横で動く、サポート中の PHP（PHP-FPM）へ移すことです。その方法は「手持ちの Mac サーバをあと 10 年」で紹介しました。MacPorts の PHP 8.5 に切り替え、各サイトを前後で確認し、どこかが壊れたら元に戻します。FrontierStack のモダナイズのペインは、こうしたサイトを PHP 8.5.12 以降に移し、それより古いものは受け付けません。移行すれば、勧告が最も危険とする mod_php からサイトが外れます。すぐに移せないサイトは、そもそも公開が必要かを考えてください。社員しか使わないイントラネットのページなら、社内ネットワークや VPN からだけ見えるように制限できます。

OPNsense と pfSense：ファイアウォールの PHP

ファイアウォールも PHP で動いています。OPNsense の Web GUI は PHP で書かれ、root として動きます。キャプティブポータルはゲストの端末に PHP のページを返すので、ゲストネットワークでは、締め出したい端末そのものがそれと通信していることになります。本稿執筆時点で、OPNsense は修正を発表していません。FreeBSD の ports ツリーにはすでに修正済みの PHP（8.3.36、8.4.27、8.5.12）がありますが、OPNsense は PHP を自身のファームウェアのパッケージとして配布しています。OPNsense のフォーラムでは、26.1 がまだ PHP 8.3.30 のままだという指摘もあります。

• 修正が出たら、OPNsense のファームウェアアップデート（System ▸ Firmware ▸ Updates）だけで更新してください。ファイアウォールに PHP のパッケージを手で入れないでください。
• それまでは、Web GUI に信頼できるネットワークからだけ接続できるようにします。WAN からも、ゲストや IoT のネットワークからも接続させないでください。
• キャプティブポータルを使っている場合は、特に注意して OPNsense の発表を待ってください。信頼できない端末が直接触れる PHP だからです。

pfSense も PHP（nginx と php-fpm）を使っています。本稿執筆時点で、Netgate は勧告を出していません。対応は同じです。Netgate が修正を出したら pfSense 自身のアップデートの仕組みで更新し、それまでは GUI を信頼できないネットワークに出さないでください。

Linux サーバ：バージョン番号ではなくセキュリティ情報を確認

php.net によると、Linux ディストリビューションと LTS の提供元には事前にパッチが渡されています。多くのディストリビューションは、すでに配布している PHP のバージョンに修正をバックポートするため、修正済みのサーバでも 8.2.35 や 8.4.27 より小さい番号を表示することがあります。バージョンを比べるのではなく、ディストリビューションのセキュリティ情報で CVE-2026-109618 と CVE-2026-109619 を確認し、パッケージを更新したら PHP-FPM か Apache を再起動してください。

すぐにアップデートできない場合

php.net は、特定の攻撃経路への露出を減らす設定を挙げています。ただし、これでインストールが安全になるわけではないと明記しているので、アップデートまでのつなぎとして扱い、アップデートの代わりにはしないでください。

• session.upload_progress.enabled = 0：php.ini か PHP-FPM のプールで設定します。ini_set() や .user.ini は反映が遅すぎるので頼らないでください。その後、すべてのワーカを再起動します。
• PHP 8.5 では fatal_error_backtraces = 0 も設定し、同じく再起動します。php.net によると、これが防ぐのは確認済みのバックトレースの経路だけです。
• post_max_size を小さく保ちます。アップロードを受け付けないサイトは 8M、受け付けるサイトは 32M とし、upload_max_filesize はそれより小さくします。
• php.net は memory_limit = -1（アプリケーションが上書きできない場所で設定）も挙げていますが、メモリ確保の失敗が依然として脆弱性に届きうると注意しています。メモリの少ない Mac では、上限をなくすと、暴走した 1 つのリクエストがほかのすべてからメモリを奪うことにもなります。

今日やること

1. PHP を提供しているマシンをすべて書き出し、それぞれの PHP の入手元（Homebrew、MacPorts、MAMP、Apple、Linux ディストリビューション、ファイアウォールのファームウェア）を確認します。
2. Homebrew：PHP の formula をそれぞれアップグレードし、PHP-FPM と Apache を再起動して、バージョンを確認します。
3. MacPorts：sudo port selfupdate を実行し、PHP のポートをアップグレードして PHP-FPM を再読み込みし、バージョンを確認します。
4. MAMP：いますぐ暫定設定を入れて再起動し、修正済みの PHP を含む MAMP のアップデートが出たらすぐに適用します。
5. Server.app の Apple 標準 PHP：今週中に PHP-FPM への移行を計画し、それまでは公開する必要のないサイトに接続できる相手を制限します。
6. Linux：ディストリビューションのアップデートを入れ、セキュリティ情報で 2 つの CVE を確認し、PHP を再起動します。
7. ファイアウォール：OPNsense や pfSense の GUI は信頼できるネットワークだけに限り、修正が出たらファームウェアのアップデートで更新します。
8. 実際に動いているものを確認します。php -v が示すのはコマンドラインの PHP で、サイトを提供している PHP と同じとは限りません。Web サーバが使っているバージョンも確認し、そのために phpinfo() のページを使った場合は、確認後すぐに削除してください。

FrontierStack にできること

FrontierStack が上の手順を肩代わりするわけではありません。次のアップデートでは、それを見つけやすく、忘れにくくします。

• フリート実行 ▸ PHP のバージョンとセキュリティ修正は、連携したサーバ全体を読み取り専用で確認する操作です。各サーバの PHP（Homebrew、MacPorts、MAMP、Apple 標準、ディストリビューションのパッケージ、SSH 経由の OPNsense や pfSense のファームウェア）をすべて一覧にし、サーバが php-fpm、php-cgi、mod_php で Web に PHP を提供しているかを示し、それぞれを php.net にあるそのブランチの最新リリースと比べます。セキュリティリリースより古いものや、修正が提供されなくなったブランチのものには印が付きます。FrontierStack 自身は PHP をアップデートしません。AI プロンプトをコピーで、Claude Code、AI 管理者、またはほかのエージェント向けのプロンプトをクリップボードに入れます。エージェントは各サーバの入手元から PHP を 1 台ずつアップデートし、変更のたびに確認を求め、ディストリビューションやファイアウォールのパッケージについては提供元のセキュリティ情報を確認します。マニュアルのフリート実行をご覧ください。
• 古い Mac サーバのモダナイズは PHP 8.5 を入れ、修正を必須にします。インストール・切り替え・移行は、この修正を含む最初の PHP 8.5 である 8.5.12 より古いものを受け付けません。以前に PHP 8.4 で設定したサーバにはPHP 8.5 に移行が表示され、前後で各サイトを確認し、どれかが壊れたらすぐに元に戻します。PHP がその後のセキュリティリリースを出した日にも、MacPorts のパッケージ化を待たずに警告します。PHP 8.5 をアップデートは PHP のポートを実際にアップグレードし、PHP-FPM を再起動するようになりました。これまでは、インストールをもう一度実行しても、インストール済みの PHP はアップグレードされませんでした。curl・rsync・OpenSSL のアップデートも同様にアップグレードするようになり、MacPorts のインストーラは macOS 26 と 27 を含め、MacPorts が対応するすべての macOS で動きます。セキュリティのチェックリストは、Apple の PHP のままの Web サイトを不合格の項目として示し、ペインはサーバ上で古くなっている MacPorts のツールを一覧にします。マニュアルのモダナイズのペインをご覧ください。
• PHP ペインには、Mac 上のすべての PHP（Homebrew、MAMP、MacPorts、Apple 標準）を対象にしたセキュリティの確認が加わります。8.5.12 より古いもの（古いブランチでは 8.4.27・8.3.36・8.2.35 より古いもの）に印を付け、8.1 以前は修正が提供されないものとして示し、それぞれの対処法を表示します。
• Router Health は、API で連携した OPNsense ファイアウォールのファームウェアのパッケージ一覧から、インストールされている PHP のバージョンを読み取り、そのブランチの最新のセキュリティリリースより古ければ警告します。修正そのものは OPNsense のファームウェアで入れます。マニュアルのファイアウォールの状態をご覧ください。

3 つとも、読み取って報告するだけです。変更はそれぞれの PHP の入手元を通じて、あなたの承認があるときにだけ行われます。

出典：php.net の10 月 20 日の事前告知と 2026 年 10 月 21 日のリリース告知、上にリンクした php-src の 2 件の勧告、2026 年 10 月 22 日に確認した Homebrew、MacPorts、FreeBSD のパッケージ情報。リリース直後の数日はパッケージのバージョンがすぐに変わるので、頼る前にもう一度確認してください。