IBM Aspera Faspex 脆弱性 CVE-2026-123218：管理者権限を奪う認可不備と5.0.19 PL1の適用手順

社外との大容量ファイルの受け渡しに使われるIBM Aspera Faspex 5で、一般のユーザーが管理者権限を得られる認可不備CVE-2026-123218が、2026年11月9日にCISAの悪用確認済み脆弱性カタログ（KEV）へ追加されました。対象は5.0.0から5.0.19までのすべての版で、回避策はありません。この記事では、欠陥の中身とCVSSの読み方、手元の版を確かめるfaspexctlのコマンド、5.0.19 PL1の適用手順、古い版に残る7月の任意コード実行との重なり、侵害を疑うときの確認順を整理します。記述の基準は、11月10日時点で公開されている情報です。

まとめ：Faspex 5は5.0.19 PL1へ上げ、faspex-coreの版で完了を確かめる

恒久対策は5.0.19 PL1の適用だけです。IBMは回避策を示していないため、設定変更で時間を稼ぐ手段はありません。5.0.19を使っている環境は、rootでfaspexctl setupを実行すれば新しいコンテナイメージに入れ替わります。5.0.18以前の環境は、先に5.0.19へ上げてからPL1を当てる2段階になります。

完了の判定は、faspexctl versionの結果でfaspex-coreが「5.0.19 (1ce4b13, Fix Pack: 1)」になっていることです。インターネットに公開している環境で自己登録を有効にしていた場合は、更新と並行して管理者アカウントの棚卸しも行います。自社だけで公開範囲や権限設定を確かめきれない場合は、脆弱性診断・セキュリティ診断で確認を受け付けています。

CVE-2026-123218で一般ユーザーが管理者権限を得る認可不備の中身

IBMのセキュリティ公告によると、認証済みのユーザーが特定のメッセージを細工すると、ユーザーの認可チェックを迂回して管理者の権限を得られます。分類はCWE-863（不適切な認可）です。

細工したメッセージで認可を迂回するCWE-863の欠陥と影響の範囲

公告は細工の方法を公開していません。分かっているのは、ログインできる利用者なら誰でも起点になりうること、到達点が「完全な管理者権限」であることの2点です。Faspexの管理者は、ユーザーとワークグループの管理、ファイルを置くノードとストレージの設定、メールサーバーの接続先まで操作できます。

つまり、取引先とやり取りしたパッケージの中身を読まれるだけでは済みません。送信先の差し替えや、攻撃者用アカウントの作成まで起こりえます。権限の確認をサーバー側でどう組むべきかは、認可バイパスの仕組みとサーバ側で止める実装対策で整理しています。

CVSSベクトルはPR:N、説明文は認証済みユーザーという食い違い

IBMが付けたCVSS 3.1の基本値は9.8で、ベクトルはAV:N/AC:L/PR:N/UI:Nです。PR:Nは「攻撃に権限が要らない」という意味で、説明文の「認証済みユーザーが」と食い違っています。NVDの登録も同じIBMの採点をそのまま載せており、11月10日時点で独自の評価は付いていません。

どちらが正しいかを外部から決める材料はありません。運用の判断では、ログインの壁を当てにしない側で扱います。自己登録や外部ユーザーの招待でアカウントを持てる相手は社外に多く、「認証済み」は守りとしてほとんど働かないからです。

影響版5.0.0〜5.0.19と修正版5.0.19 PL1、KEV追加までの日付

公告の対象はLinux版のFaspex 5で、5.0.0から5.0.19までです。修正はFix Pack形式の5.0.19 PL1で、11月7日の公告と同時に提供されました。

11月7日の公告から2日でKEV入りし是正期限が11月12日になった経緯

CISAのKEVは11月9日に本件を追加し、米国連邦機関向けの是正期限を11月12日としました。侵害の有無を調べる手順（Forensics Triage）も求められています。ランサムウェアでの利用は「不明」の扱いです。

CISAが付けた評価では、悪用は「進行中」、攻撃の自動化は「可能」、技術的な影響は「全面」です。公告から2日での追加なので、更新の準備に使える猶予はほとんどありません。期限の決まり方はBOD 26-04の是正期限の仕組みにまとめています。

5.0.16未満に残る7月の任意コード実行2件と重なる攻撃経路

5.0.15.4以前には、7月の5.0.16の公告で直った欠陥も残っています。

NVDのCVE-2026-14958は要求権限を「高」としています。単独なら管理者でないと使えない欠陥です。ところが本件で管理者権限を取れるなら、その条件は満たされます。公告が述べている組み合わせではありませんが、5.0.16未満の環境は「一般ユーザーからサーバー上のコード実行まで届く」前提で優先度を上げてください。

10月の5.0.19と3月の5.0.15で塞がれた同梱部品の脆弱性

10月27日の5.0.19の公告は、5.0.0〜5.0.18を対象に、同梱するaxiosやHTTP/2実装など20件の脆弱性を扱っています。3月6日の5.0.15の公告は、RackのパストラバーサルやFaspex自身のXSS・HTTPヘッダーインジェクションを扱いました。

どの公告も回避策は「なし」です。5.0.19 PL1まで上げれば、これらはまとめて対象外になります。

手元のFaspex 5で版番号と登録設定を確かめるコマンドと画面

確認する項目は2つです。動いているコンテナイメージの版と、社外の人がアカウントを作れる設定になっているかです。どちらも読み取りだけで、転送を止めません。

faspexctl versionによるfaspex-core版とFix Packの確認

IBM Docsのパッチ適用の章にあるfaspexctl versionを、rootで実行します。

# 各コンテナイメージの版を表示する
faspexctl version

# 本件の判定に使う行だけを見る
faspexctl version | grep faspex-core
# 修正済みの表示: faspex-core: 5.0.19 (1ce4b13, Fix Pack: 1)

faspex-coreが5.0.19でも、括弧内に「Fix Pack: 1」が無ければ未修正です。5.0.18以前の表示なら、次の章の2段階の更新が必要になります。出力にはMariaDBとNginxの版も並ぶので、作業記録として保存しておくと後の監査で使えます。

Security画面のAccount registrationで自己登録の有無を確かめる

IBM Docsの自己登録の章によると、自己登録は既定で無効です。設定は管理画面の「Security」にある「Account registration」で、承認の要否や登録を拒むメールドメインを指定できます。

ここが有効で、しかも承認なしの設定だった環境は要注意です。メールアドレスさえあれば誰でもアカウントを作れるため、本件の「認証済み」という条件は無いのと同じになります。PL1を当てるまでの間は、自己登録を無効に戻すか承認制へ切り替えてください。ただし、既に作られたアカウントからの攻撃は止まりません。

同じFaspexを狙ったKEV掲載をjqで一覧にするスクリプト

KEVはJSONでも公開されています。Faspexの掲載だけを抜き出すと、過去の事例と並べて優先度を判断できます。

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[]
      | select(.product | test("Faspex"))
      | [.cveID, .dateAdded, .dueDate, .knownRansomwareCampaignUse] | @tsv'

11月10日時点の結果は2行です。本件と、2023年2月に追加されたCVE-2022-47986です。後者はFaspex 4系のYAML逆シリアル化の欠陥で、ランサムウェアでの利用が「確認済み」とされています。Faspexは過去にも身代金目的の攻撃で狙われた製品だということです。

5.0.19 PL1のfaspexctl setup適用とFix Pack 1の確認手順

パッチ適用の章によると、同じタグの中で新しいコンテナイメージが出た場合、FaspexのRPMを入れ替える必要はありません。5.0.19 PL1はこの形で配られています。

rootでfaspexctl setupを実行して新しいイメージへ入れ替える

# root で実行する
faspexctl version > /root/faspex_version_before.txt   # 適用前の版をファイルに記録し、適用後の確認に使う

faspexctl setup      # 同じタグの新しいコンテナイメージを取得して入れ替える
faspexctl status     # すべてのコンテナが存在し稼働しているかを見る

faspexctl version | grep faspex-core
# 期待値: faspex-core: 5.0.19 (1ce4b13, Fix Pack: 1)

RPMインストールの章のとおり、faspexctl setupはIBM Cloud Container Registry（icr.io）からイメージを取得します。外向きの通信を絞っている環境では、作業前にicr.ioへの経路を開けておかないと、取得の段階で止まります。コンテナが入れ替わる間は転送が中断するので、取引先とのやり取りが少ない時間帯を選んでください。

5.0.18以前から上げるときの順番とDB・設定のバックアップ

1. 現在の版、/opt/aspera/faspex/conf/docker配下の.env、データベースのバックアップを取る
2. IBM Fix Centralから5.0.19のRPMを取得し、IBM Docsの5.x向けアップグレード手順で更新する
3. faspexctl versionで全コンテナが5.0.19になったことを確かめる
4. 上の手順でfaspexctl setupを実行し、PL1を当てる
5. テスト用のパッケージを送受信し、ノードとメール通知が動くかを確かめる

手順2を飛ばしてPL1だけを当てることはできません。PL1は5.0.19のタグに対するパッチだからです。Faspex 5ではDockerとPodmanを同じサーバーに同居させられないため、更新の途中でランタイムを入れ替える作業は避けます。

判断：侵害調査まで進めるFaspexと更新だけで済ませてよい条件

更新だけで終えてよいのは、Faspexが社内網やVPNの内側にしか無く、アカウントを持つのが社員だけだった環境です。それ以外は、PL1の適用と並行して侵害の確認を行います。

インターネット公開と外部ユーザー・自己登録が重なった環境の扱い

Faspexは社外と受け渡すための製品なので、多くの環境がインターネットに公開され、取引先のアカウントを抱えています。この条件で5.0.19以前を動かしていた環境は、管理者権限を奪われた期間があったと見なします。KEVへの追加は実際の攻撃を意味し、公開範囲を確かめるだけでは安全と言えないからです。

5.0.16未満だった環境は、さらに一段重く扱います。前の章の表のとおり、管理者権限からサーバー上のコード実行へ進む欠陥が残っていたためです。逆に、社員しかアカウントを持たない社内専用の環境なら、更新と管理者の棚卸しで終えてよいと判断します。見送ってよい対策もはっきりさせます。WAFで特定のリクエストだけを止める方式は、細工の内容が公開されていないため設計できません。

管理者アカウントの棚卸しからパッケージ漏えいの確認までの順番

1. 管理画面のユーザー一覧で、管理者権限を持つアカウントに見覚えのないものが無いかを見る
2. 最近作られたアカウント、メールサーバーやノードの設定変更の有無を確かめる
3. 管理者と、Faspexに登録したノードのAPIユーザーの認証情報を入れ替える
4. 5.0.16未満だった場合は、docker psまたはpodman psで見覚えのないコンテナや外向き通信が無いかを調べる
5. 取引先から預かったファイルの持ち出しが疑われる場合は、報告義務の該当性を判断する

3は痕跡が無くても実施します。管理者は設定画面からノードの接続情報に触れられるため、漏れた前提で扱うのが安全です。預かったファイルに個人データが含まれていれば、個人情報保護委員会への報告義務を確認してください。暗号化や脅迫文が見つかった場合は、ランサムウェアの初動対応の手順へ切り替えます。自社運用を続けるか迷う場合は、大容量ファイル送信サービスの種類と自社構築の判断も比較材料になります。

よくある質問

IBM Aspera Faspexの脆弱性CVE-2026-123218について、運用の現場で迷いやすい点に答えます。

5.0.19に上げていれば対応は完了ですか？

完了ではありません。影響版は5.0.0から5.0.19までで、5.0.19そのものも含まれます。修正は5.0.19 PL1です。faspexctl versionでfaspex-coreが「5.0.19 (1ce4b13, Fix Pack: 1)」と表示された時点を完了の基準にしてください。括弧内にFix Packの表記が無ければ、まだ当たっていません。

Faspex 4系を使っている場合も対象ですか？

11月7日の公告が対象とするのはFaspex 5だけです。ただし公告は、影響版の一覧がサポート中の版に限られると断っています。Faspex 4系には2023年にKEVへ載ったCVE-2022-47986があり、ランサムウェアでの利用が確認されています。4系を動かしているなら、Faspex 5への移行を急ぐ理由のほうが大きいと考えてください。

KEVの是正期限11月12日は日本の企業にも適用されますか？

KEVの是正期限は、BOD 26-04にもとづき米国の連邦政府機関に課されるものです。日本の民間企業に法的な拘束力はありません。ただし、KEVへの追加は実際の攻撃が確認されたことを意味します。インターネットに公開しているFaspexは、同じ11月12日を目安にPL1の適用を終えてください。

自己登録を無効にすれば更新を待ってもよいですか？

待てません。自己登録を止めても、取引先や外部ユーザーなど既に作られたアカウントからの攻撃は防げないためです。IBMは回避策を「なし」としており、CVSSのベクトルは権限不要を示しています。自己登録の停止は、PL1を当てるまでの数時間から数日の間に入口を減らす手段にとどめてください。

悪用されたかどうかをログで判定できますか？

11月10日時点で、IBMは本件の痕跡となるログの文字列を公開していません。手がかりは、見覚えのない管理者アカウント、最近の設定変更、深夜帯の大量ダウンロードといった結果の側です。KEVが侵害調査を求めている以上、ログで何も見つからないことを「侵害なし」の根拠にはせず、認証情報の入れ替えまで進めてください。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：外部から届く要求を認可で絞る設計の基本をまとめています。
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：KEV掲載を起点に更新の順番を決める運用の作り方です。
• HULFTとは？暗号化方式（AES・高強度暗号強制モード）と配信・集信の設計、HULFT10のサポート期限を解説：企業間ファイル転送を別製品で組む場合の設計と比較材料です。