AWS ParallelCluster 3.14.1 以前の稼働中クラスターに CVE-2026-25506 対応パッチを適用してみた
はじめに
2026 年 2 月 17 日に AWS ParallelCluster 3.14.2 が CVE-2026-25506 対応としてリリースされました。
本件はバッファオーバーフローにより MUNGE の MAC サブキーが漏洩する脆弱性です(CVSS 7.7 High)。ローカルアクセス権を持つ攻撃者が鍵を抽出し、root を含む任意ユーザーの認証情報を偽造できる可能性があります。MUNGE を 0.5.18 にアップグレードすることで対処できます。
しかし、運用中のクラスターをすぐに切り替えられないケースもあります。本記事では、3.14.1 以前で稼働中のクラスターにパッチを適用する手順を紹介します。
手順は AWS 公式の Wiki を参考にし試してみました。
対応の概要
もっと手軽な方法でパッチ充てを検討した結果、対応は以下の 2 ステップです。
- ヘッドノードで MUNGE 0.5.18 をビルド・インストールする
- コンピュートノードにカスタムアクションでパッチを配布する
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| ParallelCluster | 3.14.0 |
| OS | Ubuntu 24.04 |
| MUNGE(アップグレード前) | 0.5.16 |
ヘッドノードのアップグレード
検証用のクラスターを用意しました。

現在のバージョン確認
現在の MUNGE バージョンを確認します。
munged --version
予定どおり脆弱性を抱えているバージョンです。
munge-0.5.16 (2024-03-15)
既存ファイルのバックアップ
アップグレード前に既存の MUNGE 関連ファイルをバックアップします。
MUNGE_FILES=(
/etc/munge/
/usr/bin/munge
/usr/bin/remunge
/usr/bin/unmunge
/usr/sbin/mungekey
/usr/sbin/munged
/usr/lib/systemd/system/munge.service
/usr/lib*/libmunge*
)
sudo rsync -aR "${MUNGE_FILES[@]}" /opt/parallelcluster/sources/munge-backup
MUNGE 0.5.18 のビルドとインストール
MUNGE 0.5.18 のソースをダウンロードします。
MUNGE_VERSION="0.5.18"
sudo mkdir -p /opt/parallelcluster/sources
sudo curl -fsSL -o /opt/parallelcluster/sources/munge-${MUNGE_VERSION}.tar.xz \
https://us-east-1-aws-parallelcluster.s3.us-east-1.amazonaws.com/archives/dependencies/munge/munge-${MUNGE_VERSION}.tar.xz
sudo tar -xvf /opt/parallelcluster/sources/munge-${MUNGE_VERSION}.tar.xz -C /opt/parallelcluster/sources
cd /opt/parallelcluster/sources/munge-${MUNGE_VERSION}
OS に応じたライブラリディレクトリを設定し、ビルド・インストールします。
grep -qi ubuntu /etc/os-release && MUNGE_LIBDIR="/usr/lib" || MUNGE_LIBDIR="/usr/lib64"
sudo ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=${MUNGE_LIBDIR}
sudo make install
MUNGE サービスの再起動
sudo systemctl daemon-reload
sudo systemctl restart munge
動作確認
アップグレード後のバージョンを確認します。
munged --version
脆弱性対処済みのバージョンになりました。
munge-0.5.18 (2026-02-10)
MUNGE サービスの稼働状態を確認します。
sudo systemctl status munge
● munge.service - MUNGE authentication service
Loaded: loaded (/usr/lib/systemd/system/munge.service; enabled; preset: enabled)
Active: active (running) since Mon 2026-02-16 23:52:52 UTC; 14s ago
Docs: man:munged(8)
Process: 21491 ExecStart=/usr/sbin/munged $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 21495 (munged)
Tasks: 4 (limit: 2275)
Memory: 1.3M (peak: 1.7M)
CPU: 17ms
CGroup: /system.slice/munge.service
└─21495 /usr/sbin/munged
MUNGE の認証動作を確認します。
sudo munge -n | unmunge
STATUS: Success (0) が表示されれば成功です。
STATUS: Success (0)
ENCODE_HOST: ip-10-0-0-131.ap-northeast-1.compute.internal (10.0.0.131)
ENCODE_TIME: 2026-02-17 00:46:40 +0000 (1771289200)
DECODE_TIME: 2026-02-17 00:46:40 +0000 (1771289200)
TTL: 300
CIPHER: aes128 (4)
MAC: sha256 (5)
ZIP: none (0)
UID: root (0)
GID: root (0)
LENGTH: 0
Slurm でジョブが実行できることも確認しますと手順にあったのですが、何も結果が返ってきませんでした。
srun hostname
コンピュートノードのアップグレード
コンピュートノードには、ヘッドノードでビルドしたバイナリをカスタムアクションで配布します。
バイナリの共有ディレクトリへのコピー
ヘッドノードでビルドした MUNGE バイナリを共有ディレクトリにコピーします。
MUNGE_FILES=(
/usr/bin/munge
/usr/bin/remunge
/usr/bin/unmunge
/usr/sbin/mungekey
/usr/sbin/munged
/usr/lib/systemd/system/munge.service
/usr/lib/sysusers.d/munge.conf
/usr/lib*/libmunge*
)
sudo rsync -aR "${MUNGE_FILES[@]}" /opt/parallelcluster/shared/.munge/
カスタムアクションスクリプトの作成
コンピュートノード起動時にバイナリを配布するスクリプトを作成します。
#!/bin/bash
set -ex
sudo rsync -a /opt/parallelcluster/shared/.munge/usr/ /usr/
sudo systemctl daemon-reload
作成したスクリプトを S3 バケットにアップロードします。S3 バケットの名前(devio-custom-boostrap-files)はご自身の環境に置き換えてください。
aws s3 cp PatchMunge.sh s3://devio-custom-boostrap-files/patch-munge/PatchMunge.sh
クラスター設定の更新
クラスター設定ファイルの SlurmQueues に S3 アクセス権限と OnNodeStart カスタムアクションを追加します。
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-name
# ... 既存の設定 ...
Iam:
S3Access:
- BucketName: devio-custom-boostrap-files
EnableWriteAccess: False
CustomActions:
OnNodeStart:
Script: s3://devio-custom-boostrap-files/patch-munge/PatchMunge.sh
S3Access で S3 バケットへの読み取り権限を付与しています。カスタムアクションスクリプトの取得に必要な設定です。
クラスターの更新と再起動
コンピュートフリートを停止し、クラスター設定を更新した後、フリートを再起動します。
フリートの停止・開始手順は以下の記事を参考にしてください。
コンピュートノードの動作確認
テストジョブをサブミットしてコンピュートノードを起動します。

コンピュートノードにログインし、MUNGE のバージョンを確認します。
sudo su - ubuntu
munged --version
脆弱性対処済みのバージョンになりました。
munge-0.5.18 (2026-02-10)
コンピュートノードでも MUNGE 0.5.18 に更新されたことを確認できました。
まとめ
ParallelCluster 3.14.1 以前の稼働中クラスターで CVE-2026-25506 に対応する方法を紹介しました。ヘッドノードで MUNGE をビルド・インストールし、コンピュートノードにはカスタムアクションで配布します。
おわりに
今回のパッチ充て作業は地味に手間でした。クラスターの管理に不慣れなら ParallelCluster 3.14.2 でクラスターを新規作成し、移行する方を推しておきます。この様な運用作業は PCS(Parallel Computing Service)d だと AWS さんが管理してくれるので楽で良いかもしれないですね。







