コンテンツへスキップ
一覧に戻る
2026/10/22

PHP・Node.js・Go の2026年10月セキュリティ修正まとめ:影響範囲と環境別の対処手順

PHP・Node.js・Go 2026年10月セキュリティ修正まとめ

2026年10月、PHP(CVE-2026-109618/109619)、Node.js(Brotli 展開の境界外書き込みを含む10件)、Go(HTTP/2・TLS・証明書など計16件)で重要な修正が相次ぎました。公式発表と各OSベンダーの情報をもとに、影響の有無の確認方法、修正版、OS・ツール別の更新手順、更新できない場合の暫定策をまとめました。

シェア

要点

  • PHP:8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 へ更新。CVE-2026-109618/109619 は認証不要のリモートコード実行につながり、Apache + mod_php が最も危険
  • Node.js:22.23.4 / 24.22.1 / 26.12.1 へ更新。Brotli 展開の境界外書き込み(CVE-2026-111497)など。Node.js 20 は修正されません
  • Go:1.27.3 または 1.26.10 で再ビルド。10月の2回の更新で HTTP/2・TLS・証明書など計16件を修正
  • 更新したら必ず再起動・再ビルド。古いプロセスは古いコードのまま動き続けます
  • 10月22日時点で公式に確認された悪用はなし(CISA KEV 未掲載)。ただし PHP は攻撃通信が観測されており、最優先で対応を

この記事について

2026年10月22日(日本時間)時点で、各プロジェクトの公式発表、NVD、各OSベンダー(Debian・Ubuntu・Red Hat ほか)のセキュリティ情報を確認してまとめたものです。配布状況は時間とともに変わるため、「未提供」と書いた項目も含め、実際の作業前に末尾の公式リンクで最新状況をご確認ください。

深刻度の数値は発表元によって異なります。本文では、どの機関の評価かを明記しています。

まず確認:自分の環境は影響を受けるか

PHP

  • php -v でコマンドライン版のバージョンを確認します。ただし、Web で動いている PHP(PHP-FPM や mod_php)は別のビルドの場合があります
  • OS の公式パッケージには、修正を取り込んでもバージョン番号が古いままのものがあります(例:Ubuntu 24.04 は 8.3.6、RHEL 9 標準の PHP は 8.0.30、AlmaLinux は 8.2.33 / 8.3.33 のまま)。php -v ではなくパッケージのバージョンで判断してください:dpkg -l | grep -E '^ii +(php[0-9.]+|libapache2-mod-php)'(Debian/Ubuntu)、rpm -q php php-fpm php-cli(RHEL 系)
  • Apache に mod_php が読み込まれているか:apachectl -M | grep -i php(Debian/Ubuntu は apache2ctl -M、RHEL 系は httpd -M)
  • Web 側の実際の値は、管理者 IP からだけ見られる一時的なスクリプトで PHP_VERSION と PHP_SAPI を表示して確認し、確認後すぐ削除します(apache2handler = mod_php、fpm-fcgi = PHP-FPM)

Node.js

  • node -v で確認。22.x は 22.23.4、24.x は 24.22.1、26.x は 26.12.1 より前なら影響あり。20.x・25.x・18.x 以前はすべて影響あり(修正版なし)
  • 同梱ライブラリの版:node -p "process.versions"(修正版は undici 6.29.1 / 7.30.1 / 8.12.2、c-ares 1.34.9)
  • 公式ビルドでの Brotli 修正の有無:node -p "require('zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH" が -17 なら修正済み、undefined なら未修正です(悪意のある入力は使わない確認方法です)
  • コンテナ:docker run --rm --entrypoint node <イメージ名> -v(--entrypoint を付けると、イメージ本来の起動コマンドでアプリが立ち上がるのを防げます)
  • npm で undici を別途入れている場合:npm ls undici(Node.js 本体を更新しても、別途インストールした undici は更新されません)

Go

  • ツールチェーン:go version(1.27.3 / 1.26.10 未満は影響あり。1.25 以前はサポート終了で修正なし)
  • 動いているプログラム:go version -m /path/to/binary で、そのバイナリをビルドした Go のバージョンと依存モジュールが分かります。go version /usr/local/bin のようにディレクトリを指定すると、中の Go 製バイナリをまとめて表示します
  • 脆弱性スキャン:go install golang.org/x/vuln/cmd/govulncheck@latest で導入し、ソースは govulncheck ./...、バイナリは govulncheck -mode binary /path/to/binary

PHP:CVE-2026-109618 / CVE-2026-109619(通称「PHP2shell」)

何が起きたか

PHP プロジェクトは2026年10月21日(UTC)、8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を同時に公開しました。公式発表は「完全な回避策はなく、更新が唯一の安全な選択肢」としています。開発版の 8.6.0RC4 にも修正が入っています(本番利用は不可)。

  • CVE-2026-109618:メモリ不足(OOM)で処理が中断されたとき、途中までしか初期化されていないリクエスト用メモリが後の終了処理で使われてしまう問題。このメモリ不足は、攻撃者が送るリクエストで意図的に起こせます
  • CVE-2026-109619:前のリクエストの状態が解放後も残り、同じワーカープロセスが処理する次のリクエストで再利用されてしまう問題(解放後使用・情報漏えい・コード実行)
  • 深刻度:PHP(CVE 採番機関)の評価は CVSS v4.0 で 9.2。NVD は CVSS v3.1 で 9.8、Red Hat と SUSE は「Important」(CVSS v3.1 8.1)、Ubuntu は「Critical」。公開前に CVE 番号が漏れ、誤った「CVSS 10.0」という情報が出回ったため、公開が前倒しされた経緯があります
  • 影響する版:8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 より前。8.1 以前は公式の新版は出ませんが、PHP プロジェクトは 7.4 / 8.0 / 8.1 向けの最小限の修正をソースのブランチとして公開しています。セキュリティ企業の Wiz は 5.4 以降が影響を受けるとしています

特に危険な構成

  • Apache + mod_php:アプリケーションのコードが動く前の段階で、認証不要のリモートコード実行が実証されています(標準的なメモリ・入力上限、通常の prefork 構成)。アプリケーション側の不具合は不要で、Wiz は「Hello World」を表示するだけの単純なページでも影響を受け得るとしています
  • PHP-FPM:CVE-2026-109619 については、mod_php と PHP-FPM の両方で認証不要のリモートコード実行が実証されたと報告されています(oss-security)。PHP Foundation も、PHP-FPM でアプリケーション側の処理経路を通じたコード実行を確認したとしています
  • FrankenPHP と LiteSpeed(LSAPI)も影響を受ける可能性が高いとされています(ソースコードの分析による。実証はまだ)
  • WordPress・Drupal・Joomla などの CMS:CMS 本体やプラグインを更新しても直りません。PHP 本体の更新が必要です
  • 国内製品の告知:Movable Type(シックス・アパート)と PowerCMS は、オンプレミス・AMI 利用者に PHP の更新を呼びかけています。baserCMS は「baserCMS 自体は影響を受けず更新不要。PHP を修正版へ」としています

共有レンタルサーバー・クラウドの場合

  • 共有レンタルサーバーは事業者側で更新が進んでいます。エックスサーバーは10月22日 6:45(日本時間)までに PHP 8.2〜8.5 の対象サーバーへの修正適用を完了し、それ以前の版は順次対応中と案内しています。ConoHa WING とロリポップも緊急メンテナンスを実施しています。お使いの事業者のお知らせをご確認ください:エックスサーバー、ConoHa WING、ロリポップ
  • VPS・専用サーバー・自前のクラウドサーバーは、利用者自身の更新が必要です
  • Google Cloud:App Engine スタンダード(PHP 8.2 以降)と、基盤イメージの自動更新を有効にした Cloud Run は自動で修正済み。それ以外(App Engine フレキシブル、自前のイメージ、GKE など)は再ビルド・再デプロイが必要です(公告 GCP-2026-070)。PHP 8.1 以前のランタイムは修正されないため、8.2 以降への移行が必要です
  • Cloudflare は10月21日から WAF で防御ルールを全プランに適用し、実際の攻撃通信も観測しています。ただし WAF は補助であり、PHP の更新は依然必要です

対処:OS・環境別の修正版と手順

共通の流れは「更新 → すべての PHP ワーカーを再起動 → 版の確認」です。

  1. パッケージを更新する
  2. Apache で mod_php を使っている場合は、sudo systemctl restart apache2(RHEL 系は httpd)で完全に再起動します。reload(graceful)では古い PHP モジュールがメモリに残ることがあります。当社のサーバーでも、mod_php を無効化して reload した後も PHP モジュールがメモリ上に残り、完全な再起動で初めて消えたことを確認しています
  3. PHP-FPM は sudo systemctl restart php8.X-fpm(RHEL 系は php-fpm)
  4. 古いライブラリを使い続けているプロセスがないか確認:sudo needrestart -r l(Debian/Ubuntu)、sudo dnf needs-restarting -s(RHEL 系)
  • Debian 13(trixie):php8.4 8.4.27-1~deb13u1(DSA-6574-1)。sudo apt update && sudo apt upgrade の後、apt-cache policy php8.4-fpm で確認
  • Debian 12(bookworm):php8.2 8.2.35-1~deb12u1(Debian LTS の DLA-4848-1)
  • Debian 11 以前:無償の Debian LTS は終了しており、修正は有償の Freexian ELTS のみ(bullseye php7.4 7.4.33-1+deb11u14 など)。それ以外の場合、Debian 11 なら下記の Sury リポジトリを使えます(Debian 10 以前のビルドはありません)。または新しい OS への移行を
  • packages.sury.org(Debian/Ubuntu 用の PHP リポジトリ):amd64 向けは10月21日付けの修正版ビルドが公開済み(apt-cache policy の版に 20261021 以降が含まれていれば修正版)。7.4〜8.1 のサポート終了版にも修正が入っています。arm64 向けは10月22日時点で8.2〜8.5 がまだ9月版(未修正)でした
  • Ubuntu 公式(USN-8948-1):26.10 は php8.5 8.5.9-0ubuntu2.1、26.04 LTS は php8.5 8.5.4-0ubuntu1.5、24.04 LTS は php8.3 8.3.6-0ubuntu0.24.04.13、22.04 LTS は php8.1 8.1.2-1ubuntu2.28。php -v の表示は古いままなので、dpkg -l で版を確認します
  • Ubuntu 20.04 以前:Ubuntu Pro(ESM)で提供(USN-8948-2)。Pro がない場合は修正されません
  • ppa:ondrej/php(Ubuntu 22.04 / 24.04):8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 の各ビルドが公開済み(php8.4 は arm64 向けも確認)。Ubuntu 26.04 では PPA ではなく packages.sury.org を使います
  • RHEL 10:php 8.3.36-1.el10_2(RHSA-2026:87070)、php8.4 8.4.27-1.el10_2(RHSA-2026:87071)
  • RHEL 9:php:8.2 モジュール 8.2.35(RHSA-2026:87072)、php:8.3 モジュール 8.3.36(RHSA-2026:87079)、標準の php 8.0 は 8.0.30-8.el9_8.1(RHSA-2026:87151)。php:8.4 モジュールは10月22日時点で修正版なしのため、下記の暫定策を適用し、Red Hat の RHSB-2026-013 を確認してください
  • RHEL 8:php:8.2 モジュール 8.2.35(RHSA-2026:87073)、php:7.4 モジュール 7.4.33-8(RHSA-2026:87080)。それ以外のストリーム(7.2・7.3・8.0)には Red Hat の修正がありません。php:8.2 への切り替えは PHP の大きな版上げになるため、事前に検証してください。有効なストリームは dnf module list php で確認し、sudo dnf upgrade 'php*'
  • AlmaLinux 8 / 9 / 10:Red Hat が提供を終えたストリームも含め、すべての PHP ストリームに修正を取り込み済み。sudo dnf clean metadata && sudo dnf upgrade 'php*'
  • Rocky Linux 8 / 9 / 10:RHEL と同じ版が10月21日に公開済み(例:Rocky 9 の php-fpm 8.3.36-1.module+el9.8.0+40396+4e680bb7)
  • Oracle Linux:OL10(ELSA-2026-87070 / 87071)と OL9 標準の php 8.0(ELSA-2026-87151)は修正済み。OL9 の php:8.2 / 8.3 ストリームと OL8 は10月22日時点で未提供
  • Remi リポジトリ(EL 8/9/10、Fedora):8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 と、サポート終了版向けの修正(7.4.33-31、8.0.30-21、8.1.34-6)を公開済み。確認は rpm -q php-fpm で版を見ます(8.2.35-1 / 8.3.36-1 / 8.4.27-1 / 8.5.12-1 以降なら修正版)。変更履歴に CVE 番号が載るのはサポート終了版向けのみです(rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]')
  • Amazon Linux 2023:php8.2〜8.5 を修正(ALAS2023-2026-3301〜3304)。Amazon Linux 2023 はリポジトリの版が固定されるため、sudo dnf check-release-update で新しい版を確認し、sudo dnf upgrade --releasever=<表示された版> で更新します。Amazon Linux 2 は「Php8.2 Extra」のみ修正(ALAS2PHP8.2-2026-015)、標準の php と AL2023 の php8.1 は「修正予定なし」です
  • AWS Elastic Beanstalk:PHP 8.5 / 8.4 は AL2023 プラットフォーム v4.13.13 で修正。8.3 / 8.2 は10月22日時点で未提供のため、一部緩和策が入った v4.13.12 以降を使ってください
  • Alpine Linux:v3.24 と edge で修正(php83 8.3.36-r0、php84 8.4.27-r0、php85 8.5.12-r0)。v3.23 以前は修正されないため、3.24 への移行か、公式 Docker イメージの利用を
  • 公式 Docker イメージ「php」:8.5.12-* / 8.4.27-* / 8.3.36-* / 8.2.35-* が修正版。php:8.4-fpm などの浮動タグも修正版を指しています。FROM php:... で作った自前のイメージは docker build --pull で作り直し、コンテナも作り直してください(Compose の場合、Dockerfile からビルドするサービスは docker compose build --pull、php イメージを直接使うサービスは docker compose pull を先に実行してから docker compose up -d --force-recreate)。10月6日の RC1 タグには修正が入っていません
  • Fedora:F44 は php 8.5.12-1.fc44 が安定版に。F43(php 8.4.27-2.fc43)と F45(php 8.5.12-1.fc45)は updates-testing で提供
  • Arch Linux:php 8.5.12-1、php-legacy 8.3.36-1。Gentoo:GLSA 202610-02
  • SUSE / openSUSE:Tumbleweed は php8 8.5.12-4.1、SLES 15 SP7 は php8 8.3.36。そのほかの版は10月22日時点で準備中
  • Windows:php.net の Windows 版から修正版の zip を入手(IIS/FastCGI は NTS、Apache モジュールは TS)。IIS はアプリケーションプールを再起動します(例:Restart-WebAppPool -Name "DefaultAppPool")。Chocolatey は4系統とも修正版あり。winget は PHP.PHP.8.5 / 8.3 / 8.2 は修正済みですが、PHP.PHP.8.4 と NTS 版のパッケージは10月22日時点で未更新のため、公式 zip を使ってください
  • macOS(Homebrew):php 8.5.12、php@8.4 8.4.27、php@8.3 8.3.36、php@8.2 8.2.35。brew update && brew upgrade php(または php@8.4 など)の後、brew services restart php(php@8.4 などを使っている場合は brew services restart php@8.4 のように同じ名前で)
  • cPanel(EasyApache 4):ea-php85 8.5.12、ea-php84 8.4.27、ea-php83 8.3.36、ea-php82 8.2.35 ほか、サポート終了版にも修正あり。CloudLinux の ea-php は版番号が古いままのため、rpm -q --changelog で CVE 番号を確認します
  • Plesk:PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35(Linux・Windows)。Plesk の管理画面自体が使う PHP(sw-engine)は 18.0.80 Update 11 / 18.0.81 Update 4 で修正
  • DirectAdmin:CustomBuild で da update の後 da build php
  • LiteSpeed(lsphp):lsphp82 8.2.35、lsphp83 8.3.36、lsphp84 8.4.27、lsphp85 8.5.12。更新後は LiteSpeed を再起動して lsphp を入れ替えます
  • FrankenPHP:v1.13.2(10月21日)で修正版の PHP を同梱
  • ソースからビルドしている場合:php.net から修正版を入手して再ビルド。8.1 以前は php-src の PHP-8.1-CVE-2026-109618-109619 などのブランチに最小限の修正があります(新しい系列への移行を推奨)

すぐに更新できない場合の暫定策(いずれも不完全)

PHP の公式発表どおり、以下は更新までのリスク低減策であり、これだけで安全にはなりません。設定を変えたら、すべてのワーカーを再起動してください。

  • インターネットに公開している PHP サーバーは、修正が済むまで外部からの接続を制限することを検討してください
  • CVE-2026-109619:session.upload_progress.enabled=0 を php.ini か FPM のプール設定(php_admin_flag[session.upload_progress.enabled] = off)で設定します。ini_set() や .user.ini では効きません
  • CVE-2026-109619(PHP 8.5 のみ):fatal_error_backtraces=0(8.5 の既定値は 1)
  • CVE-2026-109619:.htaccess の php_value、nginx の PHP_VALUE などで、無効な設定や非推奨の設定を指定していないか確認し、あれば削除します(エラー表示を消しても効果はありません)
  • CVE-2026-109618:アップロードが不要なら post_max_size を 8M、必要なら 32M 程度に下げ、Web サーバーやリバースプロキシで、リクエストの大きさ、入力項目数、multipart のパート数、ヘッダー数を制限します。multipart を使わないアプリなら multipart 自体を拒否します
  • PHP の公式アドバイザリには、このほか memory_limit の扱いや、cgroup によるメモリ制限(RLIMIT_AS は使わない)、pm.max_requests=1 などの方法も挙げられています。副作用が大きいため、公式アドバイザリ(GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp)を読んだうえで判断してください
  • 攻撃の痕跡の手がかり:異常な multipart リクエストの直後に「Allowed memory size」エラーが出る、HTTP 500 が繰り返される、異常に長い PHPSESSID クッキー、原因不明の PHP ワーカーの再起動など

Node.js:10月21日のセキュリティリリース

修正された主な脆弱性

Node.js は2026年10月21日に 22.23.4 / 24.22.1 / 26.12.1 を公開し、本体の脆弱性10件と、同梱ライブラリの脆弱性を修正しました。Node.js 本体の10件の High / Medium / Low は Node.js プロジェクト自身の評価で、10月22日時点では CVE の詳細(CVSS)はまだ公開されていません。undici と c-ares の CVSS は、それぞれのプロジェクトの GitHub セキュリティアドバイザリによるものです。

  • CVE-2026-111497(High):Brotli 圧縮データの展開処理での境界外書き込み。Node.js も Brotli の開発元も「リモートコード実行を許す」としています。zlib.brotliDecompress() などの API に加え、fetch() は相手サーバーが Content-Encoding: br を返すと自動で展開するため、悪意のある、または乗っ取られたサーバーにアクセスするだけで到達しうる点に注意が必要です(リクエスト側の Accept-Encoding を変えても防げません)
  • CVE-2026-105482(High):dns.resolve*() がホスト名の NUL 文字以降を切り捨てる問題。文字列一致でホスト名を許可リスト判定してから名前解決するアプリで、判定を回避される可能性があります
  • CVE-2026-105483(High):全角数字で書かれた IP アドレスで TLS のホスト名検証を回避できる問題(24.x と 26.x のみ。22.x は影響なし)
  • CVE-2026-106069(High):IP アドレスとして緩く解釈されるホスト名(例:0127.0.0.1)で TLS のホスト名検証を回避できる問題
  • CVE-2026-105481(Medium):keep-alive の接続に、リクエストを送る前に届いていたデータを、次のリクエストへの応答として処理してしまう問題(偽の応答の注入)
  • CVE-2026-106072(Medium):127.1 のような非標準表記の IPv4 で接続した場合に、DNS 名の証明書で IP の接続先が認証されてしまう問題
  • CVE-2026-106074(Medium):スタートアップスナップショットや単一実行ファイル(SEA)で、crypto.randomUUID() と randomInt() が全プロセスで同じ値を返す問題
  • CVE-2026-106070 / 106071 / 106073(Low):実験的機能 zlib.ZipFile(26.x のみ)の不備、パーミッションモデルのワイルドカード指定による過剰な許可(26.x のみ)、fs.realpathSync() によるパーミッションモデルの回避
  • 同梱の undici(fetch・WebSocket の実装):8件。TLS オプションの一部が無視され、独自の証明書検証が効かなくなる問題(CVE-2026-109383、CVSS 7.4)、プロセスを停止させる DoS(CVE-2026-109869・CVE-2026-87018、CVSS 7.5)、リダイレクトとキャッシュの組み合わせによるキャッシュ汚染(CVE-2026-109829)ほか。修正版は undici 6.29.1 / 7.30.1 / 8.12.2
  • 同梱の c-ares(DNS)1.34.9:メモリ破壊(CVSS 7.5)を含む11件。OpenSSL 3.5.9(22.x・24.x):9月29日公表の13件の修正を取り込み
  • このほか、侵害が判明した eMudhra(emSign)系の中間 CA 証明書8件を拒否する仕組みと、ルート証明書の更新(NSS 3.131.1)が入りました。これらの証明書を経由するサイトへの TLS 接続は今後失敗します
  • 10月22日時点で、悪用の公式な報告はなく、CISA の「悪用が確認された脆弱性カタログ(KEV)」にも掲載されていません

Node.js 20 を使っている場合

  • Node.js 20 は2026年4月30日にサポートが終了しており、今回の修正版は出ません(最後の版は 20.20.2)。25.x と 18.x も同様です。22.23.4(サポートは2027年4月30日まで)か 24.22.1(2028年4月30日まで)へ移行してください。メジャーバージョンが変わると、ネイティブアドオンや古い依存パッケージが動かなくなることがあります。依存関係を入れ直し(npm ci または npm rebuild)、検証してから本番を切り替えてください
  • Node.js 26 は10月28日に LTS になる予定です。その後は nvm install --lts などの「最新 LTS」指定が 26 系を指すようになるため、22 や 24 に留まりたい場合はバージョンを明示してください
  • Debian 12 / 13 や Ubuntu の公式パッケージの nodejs は、すでにサポートが終わった系列か古い系列で、10月22日時点で今回の修正は入っていません。公開サービスで使う場合は、下記の NodeSource か公式バイナリへの切り替えを推奨します。当社でも同日、Debian 標準の Node.js 20 から NodeSource の Node.js 24.22.1 へ切り替えました

対処:環境別の手順

  • 公式バイナリ(Linux):nodejs.org から node-v24.22.1-linux-x64.tar.xz などを入手し、SHASUMS256.txt.asc の署名とハッシュを確認してから展開します
  • Windows:公式 MSI を上書きインストール(32ビット版は 22.23.4 のみ)。Chocolatey は choco upgrade nodejs --version=24.22.1 -y で修正版を入れられます(nodejs-lts パッケージは10月22日時点で 24.22.0 のまま)。winget は10月22日時点で未更新
  • macOS:公式 .pkg を上書きインストール。Homebrew の node / node@24 / node@22 は10月22日時点で未更新です(brew upgrade brotli c-ares で入れ替わるのは Brotli と c-ares の共有ライブラリだけです。TLS、dns.resolve*()、HTTP、同梱の undici の修正には node 本体の更新が必要です)。公開サービスには公式インストーラーを使ってください
  • nvm:nvm install --reinstall-packages-from=<今の版> 24.22.1 の後、nvm alias default 24.22.1。pm2 や systemd の設定に ~/.nvm/versions/node/<古い版>/bin/node が直接書かれていないかも確認します
  • fnm / Volta:fnm install 24.22.1 && fnm default 24.22.1、volta install node@24.22.1
  • NodeSource のリポジトリ(Debian/Ubuntu・RHEL 系):まだ設定していない場合や、設定が node_20.x のままの場合は、先に 22.x か 24.x のリポジトリを追加します(curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh && sudo -E bash nodesource_setup.sh の後 sudo apt-get install -y nodejs。RHEL 系は https://rpm.nodesource.com/setup_24.x を同様に実行してから sudo dnf install -y nodejs)。設定済みなら sudo apt-get update && sudo apt-get install --only-upgrade nodejs(RHEL 系は sudo dnf upgrade --refresh nodejs)。版は 24.22.1-1nodesource1 など。Brotli・c-ares・undici・OpenSSL を同梱しているため、これだけで今回の修正がすべて入ります
  • RHEL / AlmaLinux / Rocky の nodejs:10月22日時点で修正パッケージは未提供です。サポートが終わった nodejs:20 ストリームを使っている場合は sudo dnf module switch-to nodejs:22(または nodejs:24)で切り替えを。公開サービスは当面、NodeSource か公式バイナリの利用を検討してください
  • Fedora:10月22日時点で未提供。Alpine:edge の nodejs-current 26.12.1-r0 と、全サポート版の c-ares 1.34.9-r0 は修正済み。main の nodejs は未提供のため、公式の node:*-alpine イメージを使ってください
  • 公式 Docker イメージ「node」:node:22.23.4 / node:24.22.1 / node:26.12.1(各種バリアント)が修正版。node:22、node:24、node:lts などの浮動タグも修正版を指します。既存のイメージは自動では直らないので、docker build --pull --no-cache で作り直して再デプロイします(Kubernetes では、作り直したイメージを新しいタグで push し、kubectl set image deployment/<名前> <コンテナ名>=<イメージ>:<新しいタグ> で切り替えます。同じタグのまま kubectl rollout restart だけを行うと、imagePullPolicy: Always でない限り古いイメージが使われることがあります)。なお node:latest は 26 系です
  • Snap:node の 22 / 24 / 26 トラックは修正済み。sudo snap refresh node --channel=24/stable
  • AWS Lambda:マネージドランタイムは既定(自動)で AWS が更新しますが、10月22日時点で nodejs22.x / nodejs24.x への修正の反映は AWS から公表されていません。関数内で process.version を確認してください。コンテナイメージで作った関数は public.ecr.aws/lambda/nodejs:24(24.22.1)/ :22(22.23.4)から作り直してください。nodejs20.x ランタイムは非推奨で、修正されません
  • Vercel:プラットフォーム側で順次更新中で、WAF ルールも適用済み。Node.js 20 のプロジェクトは 22 か 24 に変更して再デプロイを。Next.js を自前で運用している場合は、画像最適化が Brotli の応答を拒否しないため Node.js の更新が必要としています
  • Heroku:修正版が利用可能。package.json の engines.node を確認し、再デプロイします
  • Electron アプリ:10月22日時点で Node.js 24.22.1 を含む Electron の正式版はまだ出ていません(各系列のブランチには取り込み済み)。リリース後に更新し、アプリを再ビルドしてください
  • undici を npm で直接使っている場合:npm install undici@^7.30.1(または ^6.29.1 / ^8.12.2)。4.x・5.x は修正されないため、修正版のある系列へ移行します
  • 単一実行ファイル(SEA)・スタートアップスナップショット:修正版の Node.js で作り直して再配布します

すぐに更新できない場合の暫定策

  • 信頼できない Brotli データを zlib の Brotli API や DecompressionStream('brotli') に渡さないでください。信頼できない URL への fetch() も避けます
  • 利用者が指定したホスト名を dns.resolve*() で名前解決する場合は、NUL 文字を含むものを拒否します。利用者が指定したホスト名で TLS 接続する場合は、127.1 や 0x7f.0.0.1 のような非標準の IP 表記や、全角数字を含むものを拒否します
  • 信頼できない接続先へのリクエストは keep-alive を無効にします(new http.Agent({ keepAlive: false }))
  • undici の公式回避策:TLS オプションは tls ではなく connect で渡す、TLS 1.3 のみに制限する、SRI のハッシュ名を小文字で書く(sha256 など)、インターセプターを compose(cache(), redirect()) の順で組む

更新後の確認

  • Node.js のプロセスはすべて再起動します。動いているプロセスの実体は readlink /proc/<PID>/exe で確認でき、末尾に(deleted)と出る場合は古いバイナリのままです
  • pm2 を systemd から自動起動している場合(pm2 startup で設定した場合)は、まず pm2 save で現在のアプリ一覧を保存し、sudo systemctl restart pm2-<ユーザー名> で pm2 本体を再起動します(再起動後に戻るのは、最後に保存した一覧のアプリだけです)。シェルから pm2 update や pm2 kill は実行しないでください。pm2 kill は全アプリを止めます。また pm2 update で systemd の管理外に新しいデーモンができると、systemd の停止処理が働いて全アプリが止まります(当社で実際に発生しました)

Go:10月8日と10月19日のセキュリティリリース

10月8日:Go 1.27.2 / 1.26.9(15件)

Go プロジェクトは深刻度の数値を公表していません。下記の CVSS は、米国 CISA が CVE レコードに付与した参考値です。

  • HTTP/2(サーバー・クライアント):HPACK の競合によるサーバー停止(CVE-2026-97032)、Trailer ヘッダーによるメモリ枯渇(CVE-2026-78659)、ストリームのリセットで受信バッファの上限を超えられる問題(CVE-2026-78663、CVSS 9.1)、初期ウィンドウサイズの変更を繰り返す CPU 枯渇(CVE-2026-78669)、リバースプロキシで不正なヘッダーを転送してしまうレスポンススマグリング(CVE-2026-78660)
  • HTTP/1:CONNECT 拒否後の接続ずれ(CVE-2026-56866、httputil.ReverseProxy を含む)、サーバー側の CONNECT 応答後の接続ずれ(CVE-2026-94439)
  • ファイル配信:Range ヘッダーの範囲数が無制限で CPU を消費する問題(CVE-2026-78667)。修正版は 200 を超える範囲指定を無視します(設定 GODEBUG=httpservecontentmaxranges)
  • multipart / MIME:メモリ上限を回避できる問題(CVE-2026-94440)。Go の Web サーバーへのファイルアップロードなどが該当します
  • crypto/tls:Encrypted Client Hello の不正な拡張でサーバーのメモリを枯渇させる問題(CVE-2026-97031)
  • html/template:JavaScript 内のエスケープの誤り2件。テンプレートリテラル内(CVE-2026-94448)と、yield キーワードの後(CVE-2026-97030)で、クロスサイトスクリプティングにつながるおそれがあります
  • os.Root(Windows のみ):ジャンクションをたどってルート外にディレクトリを作れてしまう問題(CVE-2026-56857)
  • go コマンド:悪意のあるプロジェクトと悪意のあるモジュールプロキシを組み合わせると、チェックサム検証を回避できる2件(CVE-2026-94444、CVE-2026-94447)

10月19日:Go 1.27.3 / 1.26.10

  • CVE-2026-111943(crypto/x509):秘密鍵が侵害された中間 CA 証明書8件を、Go 自体が信頼しないようにする修正です(鍵の生成方法に欠陥があり秘密鍵を算出できる状態だったため、CA が失効させました)。Go は CA 名を公表していませんが、Red Hat は eMudhra の件(RHSB-2026-012)としています。秘密鍵はもはや秘密ではないため、通信の途中に割り込める攻撃者であれば悪用できる点に注意が必要です
  • OS の証明書ストアの更新も公開されています:Debian(DSA-6572-1 / DLA-4845-1)、Ubuntu(USN-8944-1 / USN-8944-2 / USN-8947-1)、Alpine(ca-certificates 20261020-r0)。Red Hat は10月22日時点で準備中です。Go は、これに加えて 1.27.3 / 1.26.10 への更新を強く推奨しています

Go の拡張モジュール(golang.org/x)

  • golang.org/x/net v0.60.0 以降:上記の HTTP/2 の修正。x/net/http2 を直接使うコードは、Go 本体とは別に更新が必要です
  • golang.org/x/crypto v0.56.0 以降:SSH の接続全体を停止させる DoS 2件(CVE-2026-56855、CVE-2026-78662)と、パスワード認証などで接続元アドレスの制限が効かない問題(CVE-2026-56854、v0.55.0 で修正)
  • golang.org/x/text v0.41.0 以降:precis の Nickname プロファイルでのパニック(CVE-2026-56851)
  • 証明書を組み込んでいるプログラムは golang.org/x/crypto/x509roots/fallback も最新版(10月20日版)へ

サポート対象の版

Go のセキュリティ修正が出るのは、最新の2系列(現在は 1.27 と 1.26)だけです。1.25 以前でビルドしたプログラムには、今回の修正は一つも入りません(1.25 の最後の版は 1.25.14)。Debian の安定版に入っている golang-1.24(trixie)や golang-1.19(bookworm)、Alpine 3.23 の go 1.25 も古い系列です。

対処:ツールチェーンの更新と再ビルド

Go のプログラムは標準ライブラリをバイナリに埋め込むため、OS のパッケージや Go 本体を更新しただけでは、すでに動いているプログラムは直りません。修正版でビルドし直して再デプロイする必要があります。

  1. Go を更新する:go.dev/dl から 1.27.3 か 1.26.10 を入手し、SHA256 を確認して入れ替えます(Linux は sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.27.3.linux-amd64.tar.gz。既存の /usr/local/go に上書き展開しないこと)。並行して入れる場合は go install golang.org/dl/go1.27.3@latest && go1.27.3 download
  2. 各モジュールで使う版を固定する:go get toolchain@go1.27.3(1.26 系なら go1.26.10)。GOSUMDB=off にはしないでください
  3. 拡張モジュールを更新する:go get golang.org/x/net@latest golang.org/x/crypto@latest golang.org/x/text@latest の後、go mod tidy(依存をベンダリングしている場合は go mod vendor も)。修正済みの最低版は x/net v0.60.0、x/crypto v0.56.0、x/text v0.41.0 ですが、go get でこの版を直接指定すると、すでに新しい版を使っている場合に版が下がってしまいます
  4. ビルドし直して、go version -m <バイナリ> の1行目が go1.27.3 か go1.26.10 になっていることを確認し、再デプロイ・再起動します。最後に govulncheck -mode binary <バイナリ> で確認します
  • 公式 Docker イメージ「golang」:golang:1.27.3-* / golang:1.26.10-*。ビルド用ステージを更新しても、最終イメージ(scratch・distroless など)の中のバイナリは作り直すまで古いままです
  • Homebrew:go 1.27.3、go@1.26 1.26.10(brew upgrade go。1.26 系は brew upgrade go@1.26)
  • Debian:trixie-backports の golang-1.27 1.27.2-1~bpo13+2 は10月8日分の修正のみ。10月19日分(CVE-2026-111943)は10月22日時点で Debian のどの版にも入っていないため、go.dev の公式版、公式 Docker イメージ、または GOTOOLCHAIN で 1.27.3 を使ってください
  • Ubuntu:公式パッケージは10月22日時点で未提供。Canonical の snap は修正済み(sudo snap refresh go、1.26 系は --channel=1.26/stable)
  • RHEL:golang 1.26.10(RHEL 10 は RHSA-2026:86093、RHEL 9 は RHSA-2026:86196、RHEL 8 は go-toolset の RHSA-2026:86203)。sudo dnf update golang
  • Alpine:edge の go 1.27.2-r0、v3.24 の go 1.26.9-r0 は10月8日分のみ。10月19日分は公式 Docker イメージか GOTOOLCHAIN=go1.27.3 で
  • SUSE / openSUSE:10月8日分(go1.26 1.26.9 / go1.27 1.27.2)を提供済み。Fedora:F44 は golang 1.26.10 が安定版に(F43 と F45 の修正版はまだ updates-testing。F45 の安定版 1.27.1 は10月8日分の修正も含みません)
  • Windows:winget の GoLang.Go は10月22日時点で 1.27.0(未修正)のままです。公式 MSI か Chocolatey(choco upgrade golang --version=1.27.3 -y)を使ってください。Microsoft ビルドの Go は v1.27.3-1 / v1.26.10-1 を公開済み
  • Amazon Linux:golang は10月22日時点で修正待ち。公式のツールチェーンかイメージでビルドしてください
  • 一時的な緩和策として、Red Hat は CVE-2026-97032 について、環境変数 GODEBUG=http2server=0 で HTTP/2 サーバーを無効にする方法を挙げています(HTTP/1.1 のみになります)

Go 製ソフトウェアの更新状況(10月22日時点)

自分で作った Go のプログラムだけでなく、Go で作られた市販・OSS のソフトウェアも、提供元の更新版に入れ替える必要があります。

  • Docker Engine:29.9.0 で10月8日分、29.9.2 で CVE-2026-111943 に対応。該当する eMudhra 系の証明書を使うレジストリとは、イメージの取得・送信が TLS 検証で失敗するようになります
  • containerd:v2.4.2 / v2.3.7 / v2.2.10 で10月8日分に対応(10月19日分を含む版はまだ)
  • Kubernetes:10月22日時点でパッチ版は未公開(次の 1.37.2 / 1.36.6 / 1.35.10 で対応予定)。なお 1.34 は10月27日でサポート終了です
  • Prometheus:v3.15.1 / v3.13.5。CoreDNS:v1.15.0。Argo CD:v3.5.6 / v3.4.12 / v3.3.17。cloudflared:2026.10.2 以降
  • Terraform:v1.17.0(Go 1.26.10)。v1.16.6 は CVE-2026-78669 のみ対応
  • Vault:v2.2.0(x/crypto の SSH の修正)。Consul:修正はリリース候補版 v2.1.0-rc2 のみ
  • Traefik:v3.7.15 / v2.11.59 以降。Helm:v3.22.1 / v4.3.1。Cilium:v1.20.3 / v1.19.9 / v1.18.15。Gitea:v28.2.0(これらは HTTP/2 の修正のため golang.org/x/net を更新したもので、10月19日分を含むとは明記されていません)。Hugo:v0.168.0(Go 1.27.2 でビルドされており、10月8日分のみ)
  • etcd・runc・Caddy:修正は開発ブランチに入っていますが、10月22日時点で正式版は未公開です

更新後に必ず確認すること

  • 再起動:PHP は Apache の完全な再起動と PHP-FPM の再起動、Node.js はすべてのプロセス、Go は再ビルドしたうえでの再デプロイ。コンテナはイメージを作り直してからコンテナを作り直します
  • 古いコードが残っていないか:sudo needrestart -r l(Debian/Ubuntu)、sudo dnf needs-restarting -s(RHEL 系)。/proc/<PID>/maps に(deleted)と付いたライブラリがあるプロセスは、古いものを使い続けています
  • 版の確認:PHP はパッケージの版と Web 側の PHP_VERSION、Node.js は node -v と Brotli 修正の確認コマンド、Go は go version -m <バイナリ>
  • 埋め込み機器や市販製品に含まれる PHP・Node.js・Go は、各製品の提供元の情報を確認してください

公式情報(一次情報)

免責事項

本記事は2026年10月22日時点の公開情報を Two Sheep株式会社が整理したもので、各製品の動作や安全性を保証するものではありません。作業の前に、必ず各提供元の最新情報をご確認ください。記載の社名・製品名は各社の商標または登録商標です。

データセンターに設置したサーバーの再起動、コンソール作業、機器交換など、現地での作業が必要な場合は、当社のリモートハンズサービスにご相談ください。

シェア