【ITニュース解説】One Key for Every PBX: The Issabel Framework Hardcoded JWT Flaw (CVE-2026-89026)

Issabel Frameworkというオープンソースの統合コミュニケーションプラットフォームに、極めて深刻なセキュリティ上の弱点が発見された。このプラットフォームは、ビジネスの電話システムやボイスメールなどを管理するAsteriskを基盤としている。今回の脆弱性は「CVE-2026-89026」として記録され、その深刻度を示す共通脆弱性評価システム（CVSS）の基本スコアは9.8と、最高レベルに近い評価を受けている。これは、容易に悪用され、システムに壊滅的な被害をもたらす可能性を示している。

この脆弱性の根本原因は、Issabel Frameworkの「pbxapi」というコンポーネントにあった。「pbxapi」は、外部からの操作を受け付けるプログラムの入り口であり、ここではユーザーの認証情報を検証するためにJSON Web Token（JWT）が使用される。JWTは、情報の正当性を証明するためのデジタルな署名が付与されたトークンであり、この署名には「HS256署名キー」という秘密の文字列が用いられる。しかし、Issabel Frameworkでは、この重要なHS256署名キーが、すべてのインストール済みシステムで同じ値として、プログラムのコード内に直接「ハードコード」されていた。本来、このような秘密のキーはシステムごとにユニークな値を持つべきであり、安全に管理される必要があるが、Issabelの場合、出荷時点で共通のキーが設定されていたのである。

この共通のキーが外部に漏洩した場合、攻撃者はどのようなIssabelシステムに対しても有効なJWTを偽造できてしまう。攻撃者はこの偽造したトークンを使い、「pbxapi」が提供する管理機能の一つである「originate関数」を呼び出すことができる。「originate関数」は、Asteriskに対し「System」という特別なパラメータを渡す能力を持つ。この「System」パラメータに、攻撃者が任意のコマンド文字列を渡すと、Asteriskはその命令を、Asteriskが動作するサーバーの権限でそのまま実行してしまう。これにより、攻撃者は認証情報や事前のアクセスなしに、ネットワークから「pbxapi」のエンドポイントにアクセスできれば、ターゲットのサーバー上で任意のコードを実行できてしまう。この攻撃には高度な技術は不要であり、メッセージ認証コード（HMAC）の計算が可能な一般的なスクリプト言語があれば実行できるため、非常に広範囲な攻撃に繋がりやすい。実際に、2026年9月9日には悪用された証拠が確認されており、攻撃コードも公開されている状況だ。

この脆弱性がもたらす影響は、単に電話システムが一時的に利用できなくなるという範囲を超え、企業の重要な情報資産全体に及ぶ可能性がある。PBX（構内交換機）は、現代のITネットワークにおいて孤立した存在ではない。通常、電話番号のルーティング情報、社員の連絡先データ、通話履歴（通話詳細記録、CDR）、そして顧客管理システム（CRM）などの基幹業務システムと密接に連携している。Asteriskが稼働するサーバー上で攻撃者がコード実行の権限を獲得すると、そのサーバーを完全に制御下に置くことが可能となる。

具体的には、攻撃者は通話経路を不正に変更し、多額の国際電話料金を発生させる「トール詐欺」を仕掛けたり、録音された通話内容やボイスメールを傍受して、企業の機密情報を窃取したりすることが可能となる。また、内線電話の認証情報を盗み出し、それを足がかりに企業の他のシステムへの不正アクセスを試みることもありうる。さらに、侵害したAsteriskサーバーを拠点として、そこから内部ネットワークの他のサーバーやデバイスへと侵入を広げる「ラテラルムーブメント」を行う可能性もある。Asteriskは一般的に、セキュリティを考慮し、最低限の権限を持つユーザーで実行されることが多いが、今回の脆弱性ではアプリケーションのコンテキストで完全なコード実行が可能であるため、その影響は極めて大きいと言える。

この深刻な脆弱性からシステムを保護するためには、迅速かつ確実な対策が必須である。まず、Issabel Frameworkの提供元からリリースされている公式の修正プログラムを適用し、ハードコードされたキーを削除することが最も重要だ。修正適用後は、各Issabelシステムで、必ず新しい署名シークレット（キー）を生成し、古いキーと置き換える必要がある。これは、既に公開されてしまった共通のキーは、攻撃者に知られている可能性が非常に高いためだ。

アップグレードが完了したら、いくつかの重要な確認を行うべきである。古いキーで署名されたJWTがシステムによって拒否されることを確認し、脆弱性が確実に解消されたことを検証する。次に、「pbxapi」のエンドポイントが、インターネットなどの信頼できない外部ネットワークからアクセスできないように、ファイアウォールなどのネットワーク設定を厳重に見直し、アクセスを制限することが極めて重要である。また、脆弱性が悪用された可能性のある期間のAsteriskのログファイルをすべて保持し、不正なアクセスや異常な活動がないかを詳細に調査できるように準備しておく必要がある。通話詳細記録を注意深く確認し、不審な国際電話の発信先がないか、予期せぬ管理者アカウントが作成されていないか、そして攻撃者がシステム内に不正なスケジュールタスクや、システムを遠隔操作するためのウェブシェルを仕込んでいないかを徹底的に確認することも欠かせない。

もし、すぐにシステムのアップグレードをスケジュールできない緊急時には、一時的ながら有効な対策が存在する。この脆弱性はユーザーの操作を必要とせず、「pbxapi」のエンドポイントが直接的な攻撃の入り口となるため、ネットワーク層で「pbxapi」へのアクセスを制限することが非常に効果的だ。例えば、ファイアウォールを設定して、特定の安全なIPアドレスからのみアクセスを許可するなどの措置が考えられる。

この脆弱性に関する公開情報では、具体的にどれくらいのIssabelシステムがインターネットに公開されていたか、あるいは実際にどれくらいのシステムが攻撃を受けたかについての詳細な数値は示されていない。しかし、Shadowserverによる悪用の確認は、この脆弱性が現実世界で既に狙われていることを明確に示している。脆弱性の深刻度を示すCVSSスコアは、あくまで脆弱性そのものの潜在的な危険性を示すものであり、各々のシステムが受けるリスクは、「pbxapi」がインターネットに直接露出しているかどうかに大きく左右される。Issabel Frameworkを利用している全ての組織は、これらの情報と対策の重要性を理解し、システムのセキュリティを確保するための迅速な行動が求められる。