CVE-2026-111497（Brotli）対応と、無料版MAMPのPHP脆弱性をMacローカルで潰した手順

Weblog

前回の更新が 2020年7月 なので、気がつけばかなり久しぶりだ。書いていないあいだも開発や運用自体は続いていたのだが、ブログにまとめるところまでは手が回っていなかった。いまは PHP の重大脆弱性や関連するセキュリティ情報が立て続けに出ていて、開発機のランタイムまで含めて見直す空気が強い。自分の環境も棚卸ししたので、手順を残しておく意味で、これを機に再開する。

2026年10月、Brotliデコーダの境界外書き込みとして CVE-2026-111497 が話題になった。影響範囲は Brotli 1.0.3〜1.2.0。Node.js では 22.23.4 / 24.22.1 / 26.12.1 以降が修正版だ。

自分の環境を調べてみると、公開中のサーバ（CentOS Stream 9 + Apache + PHP-FPM）には Node が入っておらず、典型的な高リスク経路には乗っていなかった。一方、手元の Mac（M2）は Node.js v22.14.0（内蔵 Brotli 1.1.0）と Homebrew brotli 1.2.0 が該当。公開サーバよりローカルの方が先に直すべき、という状況だった。

ついでに PHP も確認したところ、いわゆる php2shell（CVE-2026-109618 / CVE-2026-109619）について、Homebrew の PHP はすでに 8.5.12 で修正済み。ただし MAMP 同梱の PHP は古いままだった。ngrok で一時公開することがあるので、こちらも対応した。

ということで、Mac ローカルで実際にやった手順を紹介する。

環境

  • Mac（M2 / Apple Silicon）
  • macOS 27.x
  • Homebrew
  • MAMP（無料版）7.4
  • 更新前: Node.js 22.14.0、brotli 1.2.0、MAMP 同梱 PHP は未修正
  • 更新後: Node.js 24.22.1、brotli 1.2.1、MAMP 実体 PHP 8.5.12

1. CVE-2026-111497 — Node.js を公式インストーラで更新

もともと公式 .pkg で入れていたので、同じ方法で上書きするのが手早い。

① https://nodejs.org/en を開く。

② 普段使いなら LTS を選ぶ（本稿時点では v24.22.1）。

Download 画面。オレンジ帯の「October 2026 security releases are available」は、このセキュリティ修正の告知。帯をクリックしなくても、24.22.1 の .pkg を入れれば目的は達成できる。

③ ページ上部の Version / OS / Method ではなく、少し下の 「Or get a prebuilt Node.js® for…」 を見る。

  • OS: macOS
  • アーキテクチャ: ARM64（Apple Silicon / M2）
  • 形式: macOS Installer (.pkg)

※ 上部の Method が nvm になっていても気にしなくてよい。方法A（公式pkg）ではそのコマンドは使わず、.pkg だけダウンロードすれば十分。

④ ダウンロードした .pkg を開き、Continue → Agree → Install。管理者パスワードを入力。

⑤ インストール完了後、新しいターミナルを開き、確認する。

$ node -v
$ npm -v
$ which node
$ node -p "process.versions.brotli"

⑥ 自分の環境では次のようになった。

v24.22.1
11.19.1
/usr/local/bin/node
1.2.0

process.versions.brotli が 1.2.0 のままでも問題ない。Node 24.22.1 は修正を取り込みつつ、内蔵 Brotli のバージョン表記を上げていないためだ。重要なのは Node が 24.22.1 以上であること。

2. Homebrew の brotli を 1.2.1 へ

Node 内蔵とは別に、Homebrew で入れた brotli もある場合はこちらも上げる。

$ brew upgrade brotli
$ brew list --versions brotli

① 実行。

brotli 1.2.1

② 1.2.1 になれば OK。すでに最新なら Warning: brotli X.X.X already installed と出て終わる。

これで CVE-2026-111497 向けのローカル対応は完了。

3. PHP 脆弱性の確認（php2shell と upload_progress）

Brotli のついでに、同じ Mac の PHP も確認した。2026年10月21日前後に公開された重大脆弱性（いわゆる php2shell）の修正版は次のとおり。

  • 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
$ which php
$ php -v

① PATH 上の php（Homebrew）を確認。

/opt/homebrew/bin/php
PHP 8.5.12 (cli) ...

② Homebrew 側は修正済み。一方、当時の MAMP 同梱は 8.5.0 / 8.4.15 / 8.3.28 などで、未修正だった。

加えて、まれな設定でのみ問題になる別件（upload_progress まわり）への暫定緩和として、PHP 公式は次を推奨している。

session.upload_progress.enabled=0

③ Homebrew の php.ini を編集する。

$ nano /opt/homebrew/etc/php/8.5/php.ini

④ 該当行を Off にする（なければ追記）。

session.upload_progress.enabled = Off

⑤ 反映を確認。

$ php -i | grep upload_progress.enabled

session.upload_progress.enabled => Off => Off

CLI の PHP なので、サービス再起動は不要。

4. MAMP を 7.4 へ更新し、修正済み PHP を使う

無料版 MAMP は、執筆時点では php2shell 修正版（8.5.12 等）を同梱していない。MAMP PRO の追加 PHP を買う以外の現実的な方法として、Homebrew の PHP 8.5.12 を、MAMP が認識するフォルダ名の中に差し込む形にした。

ネットに繋がっているだけでは即危険、というわけではない。ただし MAMP の Apache を起動した瞬間に、脆弱な PHP が Web 用に動き出す。ngrok を使うなら、更新しておいた方が安心だ。

① 公式サイトから MAMP 7.4 を入れ直す（既存の上にインストールでよい）。

② 同梱 PHP の場所を確認する。

$ ls /Applications/MAMP/bin/php/

php7.3.33
php7.4.33
php8.3.30
php8.4.17
php8.5.2
...

③ 無料版の UI で選べる版（例: 8.3.30）の bin を、Homebrew の PHP へ差し替える。バックアップを取ってから実行する。

$ PHPDIR=/Applications/MAMP/bin/php/php8.3.30
$ BREWPHP=$(brew --prefix php)

$ mkdir -p "$PHPDIR/bin.bak"
$ mv "$PHPDIR/bin/php" "$PHPDIR/bin/php-cgi" "$PHPDIR/bin/phpize" \
    "$PHPDIR/bin/php-config" "$PHPDIR/bin/phpdbg" "$PHPDIR/bin.bak/" 2>/dev/null

$ ln -sf "$BREWPHP/bin/php"        "$PHPDIR/bin/php"
$ ln -sf "$BREWPHP/bin/php-cgi"    "$PHPDIR/bin/php-cgi"
$ ln -sf "$BREWPHP/bin/phpize"     "$PHPDIR/bin/phpize"
$ ln -sf "$BREWPHP/bin/php-config" "$PHPDIR/bin/php-config"
$ ln -sf "$BREWPHP/bin/phpdbg"     "$PHPDIR/bin/phpdbg"

④ MAMP 用 php.ini でも upload_progress を Off にする。

$ nano /Applications/MAMP/bin/php/php8.3.30/conf/php.ini

session.upload_progress.enabled = Off

⑤ MAMP を起動し、Preferences で PHP が 8.3.30（自分の環境で選べる版）になっていることを確認。Apache を Start。

無料版ではドロップダウンに出る版が限られる。表示は「8.3.30」のままでよい。実体は次で確認する。

⑥ 実体のバージョンを確認する。

$ /Applications/MAMP/bin/php/php8.3.30/bin/php -v

PHP 8.5.12 (cli) ...

または、ドキュメントルートに phpinfo.php を置いてブラウザで開く。

<?php phpinfo();

PHP Version が 8.5.12 なら成功。UI の表示と実体が一致しないのは、無料 MAMP がサーバー側の許可リストとフォルダ名を照合するためだ。

フォルダ名を勝手に「php8.5.12」だけにすると、起動時にこのようなエラーになる。無料版が知っている名前（例: php8.3.30）を残し、中身だけ差し替えるのがポイント。

⑦ MAMP のスタートページで、古いコード由来の Deprecated 警告が出ることがある（例: curl_close()）。PHP 8.5 で動いている証拠でもある。気になる場合は該当箇所を直すか、スタートページを開かない運用でよい。

http://localhost:8888/MAMP/ で出る警告例。本体のサイト動作とは別件。

5. 最終確認チェックリスト

$ node -v
# => v24.22.1 以上

$ brew list --versions brotli
# => brotli 1.2.1

$ php -v
# => PHP 8.5.12（Homebrew）

$ php -i | grep upload_progress.enabled
# => Off => Off

$ /Applications/MAMP/bin/php/php8.3.30/bin/php -v
# => PHP 8.5.12

MAMP 起動後は、ブラウザの phpinfo でも 8.5.12 を確認しておく。

http://localhost:8888/en/admin/reports/status/php にて、PHP Version 8.5.12・Build Provider: Homebrew を確認。UI 上は 8.3.30 でも、実体は修正版で動いている。

補足・注意

  • 公開中サーバの libbrotli がディストリ側でまだ未修正でも、Node 等が無ければ公開 Drupal 経路の実害リスクは低いことが多い。パッチが出たら dnf update で入れる、で十分な場合もある。
  • MAMP をアプリ更新すると、差し替えたシンボリックリンクが消えることがある。アップデート後は ③〜⑥ をやり直す。
  • Homebrew PHP には、MAMP 同梱の一部拡張（古い imagick など）が無い場合がある。足りなければ都度追加する。
  • 無料版で UI 上も 8.5.12 と出したい場合は、MAMP PRO の追加 PHP 機能が必要になる。
  • EOL の PHP 7.x は使わない。起動選択肢に残っていても選ばない。

以上。Brotli の CVE をきっかけに、普段あまり触らないローカル PHP まで棚卸しできたのはよかった。ngrok で外に出す開発機ほど、同梱ランタイムの版数は意識しておきたい。