Mnestix Browserで認証なしにAPIキー流出、修正版あり
Eclipse Mnestix Browserの1.6.0以上2.3.0未満で、認証なしの攻撃者にバックエンドのAPIキーを抜き取られる脆弱性が公表されました。運用中の組織は2.3.0へ更新し、APIキーの交換と利用ログの確認もしてください。
急ぎ度: 至急
CVSS v4は9.2で、認証なしにネットワーク経由で悪用でき、標準の導入手順の構成がそのまま該当し、修正版2.3.0が出ているためです。
関係があるか
Mnestix Browser 1.6.0以上2.3.0未満を自社で動かしている組織が対象です。とくに、認証機能を無効にした構成や、インターネットや広い社内ネットワークから届く場所に置いている環境は優先して確認してください。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Eclipse Mnestix（Mnestix Browser） | 1.6.0以上2.3.0未満 | 2.3.0 |
| Eclipse Mnestix（Mnestix Browser）1.3.0から1.5.x | CVEの対象外です。ただし報告では、サーバー側から任意のURLへ接続させる経路は1.3.0から存在するとされています | CVEの記録に記載はありません。2.3.0への更新で解消する見込みです |
確かめ方
- 1稼働中のMnestix Browserの版を、コンテナーイメージのタグまたは配布物の版表記で確認します。1.6.0以上2.3.0未満なら該当します。
- 2環境変数MNESTIX_BACKEND_API_KEYを設定しているかを確認します。設定していれば、そのキーが流出した可能性を前提に扱います。
- 3AUTHENTICATION_FEATURE_FLAGの設定値と、サービスをどこまで公開しているか（インターネット、社内全体、特定の拠点のみ）を確認します。
何が起きたか
Mnestix Browserに、認証なしでバックエンドAPIキーを外部へ持ち出せる脆弱性があります。キーはサーバーが内部で使う資格情報で、設定済みのすべてのInfrastructureのものが対象です。
Mnestix BrowserはNext.jsで作られており、画面からの要求を受けてサーバー側で処理する関数をいくつか公開しています。この関数が、利用者側から渡された接続先URLをそのままサーバーから取得しに行き、その際にバックエンド用のAPIキーを要求に付けて送り、結果も返してしまうのが原因です。Eclipse Foundationの報告では、キーを渡せる相手が限られておらず、サーバー自身が届く内部アドレスやクラウドのメタデータ領域の内容も読み出せるとされています。脆弱性の種類はCWE-918（SSRF）とCWE-522（資格情報の保護不足）で、報告は認可の欠落（CWE-862）も一因に挙げています。
元の報告はAI支援の解析で作られたもので、人による確認は済んでいないと冒頭に明記されています。報告自身は重要度をHighとしていますが、CVEとして公表された評価はCVSS v4で9.2のcriticalです。修正版は2.3.0で、公表は2026年11月3日です。
攻撃の流れ
-
1
外部から到達
攻撃者がネットワーク経由でMnestix Browserに接続します。ログインは要りません。
-
2
接続先を指定
サーバー側の関数に、任意の接続先URLを渡します。
-
3
キー付きで代行
サーバーがそのURLへAPIキーを付けて要求を送り、応答も返します。
-
4
キーと情報の流出
バックエンドのAPIキーや、サーバーから届く内部サービスの応答が攻撃者に渡ります。
どう悪用されるか
悪用に必要なのは、Mnestix Browserにネットワークから届くことだけです。CVSS v4のベクターでは、認証は不要、攻撃の複雑さは低く、利用者の操作も要りません。報告は、標準の導入手順（compose.ymlでAUTHENTICATION_FEATURE_FLAGがfalse）の構成で、事前の条件なしに再現できたとしています。
被害は2つあります。1つはバックエンドAPIキーの流出で、そのキーが守っている運用側のAAS基盤を、攻撃者が直接呼び出せるようになります。もう1つは、サーバーを踏み台にした内部への接続です。内部サービスの応答の読み取りや、クラウドのメタデータ領域へのアクセスが起こり得ます。CVSS上、影響は機密性に偏っており、改ざんや停止は想定されていません。
今すぐやること
-
1
稼働中の版を確認する
コンテナーで運用している場合は、使っているイメージのタグを確認します。1.6.0以上2.3.0未満なら、次の手順へ進みます。
docker compose images -
2
2.3.0へ更新する
Mnestix Browserを修正版の2.3.0に更新します。検証環境で表示と接続を確認し、そのまま本番へ反映してください。インターネットに公開している環境を最優先にします。
-
3
更新後にAPIキーを交換する
更新を終えてから、MNESTIX_BACKEND_API_KEYを新しい値に変えます。更新前に交換すると、新しいキーも同じ経路で抜き取られるおそれがあります。バックエンド側でも旧キーを無効にします。
-
4
侵害の跡を調べる
公開期間中のアクセスログや、プロキシ・ファイアウォールの外向き通信ログに、見覚えのない宛先への接続や、通常と違う頻度の要求がないかを調べます。バックエンド側のAPI利用ログも、不審な送信元がないか見ます。
-
5
ベンダーの告知を確認する
Eclipse Mnestixのリリースノートと、Eclipse Projectsのセキュリティ告知で、更新手順と追加の注意事項を確認します。
すぐ更新できないとき
すぐに更新できないときのつなぎとして、Mnestix Browserへ届く範囲を、信頼できるネットワークと必要な利用者だけに絞ります。インターネットに公開しているなら、いったん止めるか、VPNや接続元IPの制限の内側に移してください。サーバーから内部アドレスやメタデータ領域への外向き通信を制限するのも有効です。ただし、これらは公式の回避策ではなく、根本の解消にはなりません。更新までの期間は短くし、更新後にAPIキーを交換します。
背景
Mnestix Browserは、Eclipse Mnestixプロジェクトが公開しているWebアプリで、報告ではバックエンドのAAS（Asset Administration Shell）基盤とつながって動くものとして扱われています。ブラウザーから見える画面の裏で、サーバーがバックエンドの基盤に問い合わせます。そのため、サーバーはバックエンド用のAPIキーを自分で持っています。今回の問題は、このキーの持ち主であるサーバーが、利用者から渡された接続先に対してもそのキーを付けて要求を送ってしまうことにあります。
SSRFは、サーバーを踏み台にして外から届かない場所へ接続させる脆弱性です。サーバーが持つ資格情報が一緒に送られると、流出の被害は内部の閲覧にとどまりません。報告によると、標準の導入手順の構成が最初から該当します。そのため、手順どおりに立てた検証環境や試験運用の環境が、そのまま公開されていないかも見ておく必要があります。
よくある質問
Q.AUTHENTICATION_FEATURE_FLAGを有効にしていれば影響は避けられますか。
Q.元の報告がAI生成とされているなら、情報の信頼性は低いのではありませんか。
まだ分かっていないこと
- 実際の攻撃での悪用が確認されたかどうかは、示されていません。
- 更新前の環境でキーの流出を確認できる、ログ上の具体的な痕跡や指標は示されていません。
- 公式の回避策は示されていません。
2026年11月6日 訂正：よくある質問の答えを修正しました。報告は、認証を有効にした構成でもログインした利用者にはSSRFが通ると書いています。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 修正版 |
|---|---|---|---|
| Eclipse Foundation | Eclipse Mnestix |
1.6.0 以上 2.3.0 未満 |
2.3.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
In Eclipse Mnestix Browser versions 1.6.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to exfiltrate the MNESTIX_BACKEND_API_KEY for all configured Infrastructures.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory Eclipse Foundation の報告
- web emo@eclipse.org
- web emo@eclipse.org
- web nvd.nist.gov
- web github.com