PHP がアップグレードを迫り、Apple からは何も来ない：古い macOS Server を 1 回でモダナイズ

公開 2026-10-24

2026 年 10 月 21 日、PHP は、認証なしのリクエストでサーバ上のコードを実行されるおそれがある 2 件の重大な脆弱性を修正しました。Linux のサーバなら修正はパッケージで届きます。Apple の Server.app を動かし続けている Mac には、何も届きません。Server.app の Web サイトが使っているのは、Apache に mod_php として組み込まれた Apple 標準の PHP 7.1 です。php.net はこの構成を最も危険と評価しており、PHP 7.1 の修正は 2019 年に終わり、Apple が更新することも二度とありません。

古い Mac サーバでは、PHP のアップグレードはもう「いつかやること」ではありません。今すぐ、しかも何年も手を入れずに動いてきたサイトを壊さずにやる必要があります。10 月 23 日リリースの FrontierStack 2.11 では、「古い Mac サーバのモダナイズ」ペインがこれを 1 回の実行で行います。さらに当初の予定より一歩進めて、修正の来ない Apple の Apache をインターネットの前面から外します。

Apple を待っていられない理由

• macOS Server は終了しています。Apple は 2022 年 4 月に提供を終えました。Web サイトとメールをまだ扱えた最後の版は、High Sierra 用の Server 5.6 です。
• OS のサポートも終わっています。High Sierra の最後のセキュリティアップデートは 2020 年 11 月、Mojave は 2021 年 7 月です。
• Apple はもう PHP を同梱していません。PHP は macOS Monterey で削除されたため、修正済みの PHP 7.1 を届ける macOS アップデートは今後もありません。10 月の修正の、PHP 公式のバックポートも 7.4 からです。
• Apple の Apache も止まったままです。High Sierra では、Server.app のすべての Web サイトでインターネットに面している Apache、serviceproxy は 2018 年の Apache 2.4.33 です。

2 件の脆弱性の内容と、Homebrew・MacPorts・MAMP での対処は PHP の 2026 年 10 月の重大な修正を Mac で にまとめました。この記事では、それを受けてモダナイズのペインで何が変わったかを紹介します。

自動でモダナイズ：1 回の実行で、各段階をチェック

ペインの先頭には 2 つのボタンが並びます。ツールをインストール は、Web サイトに触れずに必要なものをすべて揃えます。自動でモダナイズ… は、アプリ内のコンソールで、次の作業を順に最後まで行います。

1. Apple のコマンドラインツール（ない場合）。MacPorts に必要なもので、FrontierStack はサーバ自身の Apple ソフトウェアアップデートから取得します。画面もログイン中のユーザも要りません。High Sierra 向けにも Apple はまだ提供しています。
2. MacPorts、続いて PHP 8.5 と新しい curl・OpenSSL・rsync。どれも /opt/local に入り、Apple のものを上書きせず並べて置きます。
3. Web サイトを PHP-FPM 8.5 に移します。元の php.ini の上限値は引き継ぎます。
4. Apple の PHP 7.1 を退役させます。Apache はそれを一切読み込まなくなります。
5. MacPorts Apache を serviceproxy と並べてテストし、そのあと置き換えます。

各段階の前後で、すべてのサイトを読み込んで確かめます。サイトが壊れたり、ページが PHP を実行せずにソースを表示し始めたりしたら、その段階は自動で元に戻ります。実行はそこで止まり、それより前の段階は完了・確認済みのまま残ります。切り替えのたびに Web サイトが止まるのは数秒だけです。

PHP 8.5.12 未満は入れない

ペインは PHP 8.5 をインストールし、10 月の修正を含む最初の 8.5 である 8.5.12 より古いものは受け付けません。インストール・切り替え・移行のどれも、先にバージョンを確かめます。PHP を入れたあとはインストールが 更新 に変わり、MacPorts のポートをその場で更新します。次の PHP セキュリティリリースも、作り直しではなく各サーバでクリック 1 回です。

以前に PHP 8.4 でモダナイズしたサーバも取り残しません。更新はまずその PHP 8.4 を修正済みの 8.4.27 に上げるので、すぐに安全になります。そのあと PHP 8.5 に移行… が、同じ前後チェック付きでサイトを 8.5 に移し、壊れたサイトがあれば自動で 8.4 に戻します。

自社のサーバで実際に行ってみて、小さな問題も 2 つ見つかりました。PHP-FPM の標準プールはワーカ 5 個までで、忙しいサーバには足りません。そこでペインは、各ワーカが実際に使うメモリとデータベースに必要な分から、プールの大きさを決めるようになりました。また、古いコードでは PHP 8 のエラーログが数時間で数十 MB 増えることがあるため、インストール時にログのローテーションも設定します。

Apple の Apache をインターネットの前面から外す

最初のモダナイズの記事では、Apple の Apache は置き換えられないと書きました。Server.app の Web サイト、プロファイルマネージャ、Wiki、カレンダーがすべてそれを通るからです。プロキシの奥にある Apache については、今もそのとおりです。変わったのは、その手前の部分です。

serviceproxy は、Server.app が提供するすべてのものについて、ポート 80 と 443 で応答する Apache です。同じ 3 つの問題が繰り返し起きていました。

• セキュリティ修正が来ません。
• 古い Mac で固まります。奥の Apache は動き続けているのに、どのサイトにもつながらなくなります。
• サイトの TLS 秘密鍵を System キーチェーンから取り出します。macOS は起動時にこのキーチェーンを検査し、検査に失敗すると脇に退けて空のキーチェーンを作ります。すると serviceproxy は鍵を見つけられず、再起動しても再起動しても HTTPS は戻りません。

置き換えはボタン 3 つで、1 つずつ進めます。

1. serviceproxy を置き換え は MacPorts Apache をインストールするだけで、ほかは何も変えません。serviceproxy の設定を、Server.app がそこから読み込むファイルごと変換します。証明書・秘密鍵・チェーンは組にして root だけが読めるファイルに保ち、Apple の Apache にしかない数個のディレクティブは除きます。
2. serviceproxy の横でテスト は、変換したコピーを 127.0.0.1 で動かします。すべてのサイトと Server.app のすべてのパスについて serviceproxy の応答と比べます。プロファイルマネージャ、Wiki、カレンダー、連絡先も含みます。応答はすべて一致しなければなりません。
3. 新しい serviceproxy に切り替え… は serviceproxy を止め、launchd でオフにし、そのポートを MacPorts Apache に渡します。切り替え後に 1 つでも応答が違えば、serviceproxy がすぐに戻ります。

Server.app はそのまま動き、プロキシの奥のすべてを管理し続けます。Server.app でサイトを変更したり証明書が更新されたりすると、再同期ジョブが設定を自動で変換し直します。再同期に失敗すれば、ペインが知らせます。serviceproxy に戻す… で変更全体を元に戻せます。

注意点が 1 つあり、隠すより書いておきます。登録済みデバイスについて、serviceproxy は Apple の Apache にしかない証明書チェックを使っていました。MacPorts Apache はデバイスの証明書を標準の方法でチェックします。テストは iPhone のふりができないため、切り替えたあとはプロファイルマネージャを開き、登録済みデバイスがまだチェックインしているか確かめてください。

再起動ループではなく、修復役

古い Server.app の Mac の多くには、Web サイトが応答しなくなるとマシンを再起動する手作りのウォッチドッグがあります。プロキシの故障は再起動では直りません。しかも Server.app で Web サイトをオフにしていると、ウォッチドッグは Mac を何度も再起動し続けます。今週、まさにそれが 2 台のサーバで起きました。

サービスプロキシの修復役（ヒーラ）がウォッチドッグに代わります。毎分、ポート 80 と 443 と、その奥の Apache を、各サイトの実際の名前で確かめます。プロキシが固まっていれば、プロキシだけを再起動します。15 分で 3 回再起動しても直らなければ、それ以上は試さず、見つけたことを報告します。再起動では直らない TLS 鍵のエラーをログから見分け、代わりに証明書を読み込み直すよう伝えます。Mac を再起動することはありません。切り替え後は MacPorts Apache を同じように見守り、出来事はすべて FrontierStack のアラートに届きます。

ほかのサーバには応答させない

Server.app の Mac で Web ページを返してよいのは Server.app だけです。ペインは、ほかに応答しているものがないか探すようになりました。macOS 内蔵の Apache、launch デーモンから起動された別の Apache や nginx、古い MAMP などです。自社のサーバのうち 2 台では、内蔵の Apache が何年も前にオンにされたままでした。1 台はポート 80、もう 1 台はポート 8080 で応答し、PHP ファイルをそのままテキストとして返していました。サイトのデータベースのパスワードが公開されてしまうのは、まさにこういうときです。チェックリストはそのサーバを不合格として示し、余分なサーバをオフにすることを提案します。Web サイトがオフなのにポート 80 で何かが応答すれば、ヒーラもアラートを出します。

System キーチェーンを守る

起動時のキーチェーンのリセットは、思ったより頻繁に起きます。今週も自社のサーバ 1 台で HTTPS が止まりました。FrontierStack のリモートエージェントはバージョン 1.27 から、保護対象のサーバで System キーチェーンをバックアップし、macOS が置き換えたことに気づきます。そのうえで元のキーチェーンを戻せます。戻すのは起動 1 回につき最大 1 回で、自動で戻すのは許可した場合だけです。Web サイトを MacPorts Apache に移せば、その鍵はキーチェーンから完全に離れます。ガードは、メールを含め、まだキーチェーンに頼っている残りすべてを守ります。

フリートのほかのサーバでも

• フリート実行 ▸ PHP のバージョンとセキュリティ修正 は、連携したすべてのサーバ上の PHP を見つけます。それぞれについて入手元（Homebrew、MacPorts、MAMP、Apple、Linux ディストリビューション）と Web ページを返しているかを示し、php.net の最新のセキュリティリリースと比べます。自分で更新はせず、警告にとどめます。AI プロンプトをコピー で、自分で手順に従うことも、AI エージェントに渡すこともできる具体的な指示が得られます。
• 自分の Mac の PHP ペインには、Homebrew・MAMP・MacPorts・システムの PHP を対象にしたセキュリティの項目があります。
• OPNsense のファイアウォールも PHP で動いています。ルータの健全性チェックがファームウェアの PHP のバージョンを読み取り、遅れていればアラートを出します。
• セキュリティチェック と サーバ保護 は、古い Mac だけでなく、連携したすべての macOS・Linux サーバで使えるようになりました。サーバ保護は、毎日のファイル整合性チェックと管理用ポートのファイアウォールを加えます。

それでも直せないもの

これで macOS 自体のセキュリティアップデートが戻ってくるわけではありません。モダナイズのあと、Web サイトはサポート中の PHP と保守されている Apache で動きますが、その下のカーネルは High Sierra のままです。通信を検査するファイアウォールの内側に置き、管理用ポートをインターネットから隠し、専用のネットワークを与えてください。その強化とサーバを囲むネットワークの防御は 手持ちの Mac サーバをあと 10 年 で、準備ができたら Server.app から完全に移る方法は macOS Server の代わりと、移行の方法 で紹介しています。

始め方

FrontierStack 2.11 にアップデートし、古いサーバを連携させます。続いて「セットアップと移行」の 古い Mac サーバのモダナイズ を開くか、macOS 10.x のサーバのページで このサーバをモダナイズ を押します。ペインには、そのサーバで実際に動いているサービスの項目だけが表示されます。各段階を自分の目で見ながら進めたいなら、まず ツールをインストール から始めてください。訪問者から見えるものは何も変わりません。ペインが行う変更はすべてバックアップを残し、元に戻せます。