IBM Aspera FaspexにCVSS 9.8の認可回避、管理者権限まで一直線だった。CISAの実悪用入りで、連邦機関の期限は11月12日

まず初めに

ファイル転送の金庫室に、伝言メモ1枚で管理者室へ通される裏口があった。しかもIBMの説明文と深刻度の計算式で、裏口の前で必要な身分証の有無が食い違っている。文章では「認証済みの利用者」、計算式の前提条件（PR:N）は「権限不要」。どっちが本当でも、管理者としては最悪の想定で動くしかない。金庫の鍵の話で、解釈の余地は贅沢品である。

※個人の感想です

何が起きたのか

IBMは2026年11月7日に初版を公開したセキュリティ情報で、IBM Aspera Faspex 5.0.19 PL1が、認可回避の脆弱性へ対処したことを明らかにしました。同社によると、対象製品の利用者が特定のメッセージを細工することで、利用者認可を回避し、製品の管理者権限を全面的に得られる可能性がある、ということです。

脆弱性の分類は、認可の不備を示すCWE-863です。IBMが採点者となったCVSSの基本値は9.8で、ベクトルは「CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H」と公表されています。ネットワークから到達でき、攻撃の複雑さは低く、機密性・完全性・可用性への影響はいずれも高い、という評価です。

ここで読み手が引っかかる食い違いがあります。IBMの説明文は「認証済みの利用者（an authenticated user／an authorized user）」が細工したメッセージを送る、という書き方です。一方でCVSSベクトルの「PR:N」は「権限は不要」という前提を表します。どちらが実際の前提に近いかは、公開情報だけでは確定できません。したがって運用現場では、より厳しい側、つまり「低い権限のアカウント、あるいは条件次第では認証なしでも届き得る」という前提で棚卸しをするのが安全です。外部に開放された利用者アカウントやゲスト相当のアカウントが残っていないか、という確認も同じ理由で必要になります。

対象と修正の確認方法

対象は、IBM Aspera Faspexの5.0.0から5.0.19までの全ての5系リリースです。IBMが強く推奨する対処は、Linux向けの修正版「5.0.19 PL1」への更新であり、手順の先で、faspex-coreコンテナイメージが「5.0.19」で、ビルド識別子「1ce4b13」、Fix Pack「1」と表示されることを検証するよう求めています。バージョン番号だけ見て「5.0.19だから大丈夫」とは言えないのが、この製品の注意点です。修正前の最終版も5.0.19を名乗るため、Fix Packの表示まで含めて確認する必要があります。

項目	内容
脆弱性	CVE-2026-123218（CWE-863、認可の不備）
IBMの評価	CVSS 9.8（Critical）
対象	IBM Aspera Faspex 5.0.0〜5.0.19
修正	5.0.19 PL1（Linux）。faspex-coreイメージの表示で検証
回避策	なし（IBMの公表）
実悪用	米CISAがKEVへ追加（2026年11月9日）。連邦機関の期限は11月12日

回避策や緩和策について、IBMは「None（なし）」と明記しています。つまり、設定変更で時間を稼ぐ手札は無く、更新そのものが対処です。更新できない環境では、製品の利用停止やネットワークからの切り離しを含めた判断が、CISAの案内でも選択肢として示されています。

CISAの実悪用入りが意味すること

CISAは2026年11月9日、この脆弱性をKEVカタログへ追加しました。KEVへの掲載は、CISAが実際の悪用の証拠を持っていることを意味します。もっとも、カタログの項目は、誰が、どの組織を、どの程度攻撃したかまでは明らかにしません。IBMのセキュリティ情報自体も、悪用の有無には触れていません。「攻撃の詳細は不明だが、使われたことは分かっている」というのが、公開情報から言える正確な線です。

同じ11月9日には、FreeSWITCHやGPUStack、OpenSSHの脆弱性もKEVへ追加され、いずれも期限は11月12日とされました。本誌でも、OpenSSHの musl 環境向け問題（OpenSSHの脆弱性を解説した記事）などを取り上げています。11月12日という期限は米連邦機関向けのものですが、悪用が始まっている製品については、日本の組織にとっても優先順位の目安にはなります。あわせてCISAは、この件ではフォレンジック・トリアージが必要だとしています。パッチを当てる前に、管理者アカウントの不審な追加や、設定変更の痕跡を確認しておく、という意味です。権限昇格の穴は、当てて終わりではなく「既に管理者を取られていないか」の確認とセットで扱うのが定石です。

IT Postの見方

IT Postでは、この件で一番厄介なのは、深刻度9.8という数字よりも、「修正済みかどうかがバージョン番号だけでは判別できない」点だと考えます。5.0.19のままFix Pack表示を確認する、という一手間を飛ばすと、棚卸しの表では「対応済み」、実機では「穴あき」のまま残る。監査の表と実機の食い違いほど、後から効いてくる事故はありません。ファイル転送基盤は、置かれているデータの性質上、侵入の到達点として旨みが大きい製品でもあります。だからこそ、更新の完了条件を「イメージの表示文字列まで一致すること」と定義して、証跡を残す運用が要ると考えます。

今後どうなりそうか

期限の11月12日を過ぎると、未対応の導入先は、攻撃者側のスキャン対象として残り続けることになります。IBMからは攻撃手法の詳細は出ていませんが、KEV掲載済みという事実だけで、悪用の試行は増えるのが通例です。導入先では、更新の実施、管理者アカウントと外部公開アカウントの棚卸し、トリアージの記録、という3点をひとまとめに進めるのが現実的です。