Mendix SAMLに署名検証欠陥、アカウント乗っ取り

Siemensは2026年9月3日、ローコード開発プラットフォーム「Mendix」向けのSAMLモジュールに、SAMLレスポンスの署名検証が不十分な脆弱性（CVE-2026-80465）があると公表しました。特定のSSO構成では、認証を受けていない遠隔の攻撃者が他人のアカウント（セッション）を乗っ取れる可能性があります。CVSS v3.1で8.7、v4.0で8.8の「重要」レベルです。

対応は「モジュールを修正版に上げてアプリを再デプロイする」の一択で、Siemens公表時点で回避策（ワークアラウンド）は示されていません。厄介なのは、この更新がプラットフォーム側では自動的に適用されない点です。

この記事でわかること

  • Mendix SAMLモジュールとは何で、誰が知らないうちに使っているのか
  • CVE-2026-80465の影響バージョンと修正版（一覧表）
  • 自社に該当があるかを情シス側から確認する手順
  • ローコード内製アプリの脆弱性対応で現場がつまずくポイント

Mendix SAMLモジュールとは何ですか？

Mendixとは、業務アプリを画面上の部品の組み立てで開発できるローコード開発プラットフォームです。2018年からSiemens傘下にあり、同社のソフトウェア群「Siemens Xcelerator」の一部として提供されています（Mendix公式）。

使うのは主に、情報システム部門というより事業部門・現場部門です。「Excelとメールで回していた申請フローをWebアプリにしたい」といった内製開発で採用されます。製造業では、SiemensのTeamcenter（PLM）やOpcenter（MES）、Polarion（ALM）に接続する拡張アプリをMendixで作る使い方も公式に案内されています。

そして今回の対象であるSAMLモジュールは、そのMendixアプリのログインを社内IdP（Entra ID／ADFS／Shibboleth等）に委任するための部品です。Mendixの公式ドキュメントによれば、SAML 2.0でIdPと連携し、複数IdPの同時利用やシングルログアウト、ログイン試行の監査証跡に対応しています（Mendix Docs）。

ここが「自分ごと」になるポイントです。情シスが「うちはMendixを導入していない」と思っていても、事業部門が内製アプリを立て、そのアプリのSSOを情シス管理のIdPに繋いでいることがあります。その入口の部品が今回壊れている、という話です。

何が起きたのか

Siemensのアドバイザリ SSA-887643 は、脆弱性を次のように説明しています。影響を受けるバージョンのモジュールはSAMLレスポンスの署名を正しく検証しないため、特定のSSO構成において、未認証の遠隔攻撃者がアカウント（セッション）を乗っ取れる可能性がある——というものです。CWE分類はCWE-347「暗号署名の不適切な検証」です。

SAML認証は、IdPが発行した「この人は本人です」という応答（SAMLレスポンス）に電子署名を付け、受け取る側のアプリがその署名を検証することで成立しています。署名検証が甘いということは、その本人確認の根拠そのものが崩れるということです。パスワードの強度もMFAの有無も、ここを迂回されれば関係がありません。

影響を受けるバージョンと修正版

製品名（Siemens表記） 影響バージョン 修正版
Mendix SAML (Mendix 9.24 compatible) V3.6.27 未満 V3.6.27 以降
Mendix SAML (Mendix 10 compatible) V4.2.3 未満 V4.2.3 以降
Mendix SAML (Mendix 11 compatible) V4.2.3 未満 V4.2.3 以降

Mendix本体のバージョンではなくSAMLモジュールのバージョンで判定する点に注意してください。「Mendix 11だから新しいので大丈夫」とはなりません。

CVSSはなぜ「攻撃条件が高い」のに8点台なのですか？

スコープ（影響範囲）が変わる評価が入っているためです。公表されたベクターは以下のとおりです。

  • CVSS v3.1：8.7 / AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
  • CVSS v4.0：8.8 / AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

v3.1では攻撃条件の複雑さが「高（AC:H）」＝誰でも即座に成立するわけではない一方、権限不要（PR:N）で、影響が脆弱なコンポーネントの外（＝連携先のシステムやデータ）に及ぶ（S:C）と評価されています。v4.0では利用者の受動的な関与（UI:P）が加味されています。「条件付きだが、成立すれば認証の土台ごと抜かれる」と読むのが実務的です。

想定されるリスク

  • 他人になりすましての業務データ閲覧・操作。乗っ取られるのが一般利用者とは限らず、アプリの管理者アカウントであれば設定変更まで届きます。
  • ログ上は「正規のSSOログイン」に見える。IdP側で異常なサインインとして検知しにくく、発見が遅れやすい類の攻撃です。
  • 連携先への波及。Mendixアプリは基幹システムやPLM/MESへのコネクタを持つことが多く、アプリ1本の乗っ取りが「その先」への足がかりになり得ます（S:C評価はこの点を反映しています）。

自社が該当するか、どう確認しますか？

情シスの立場では、まず「Mendixアプリが社内に存在するか」から入る必要があります。次の順で当たるのが現実的です。

  1. IdP側の連携アプリ一覧を見る。Entra IDやADFS、Oktaなどの管理画面で、登録済みのSAML連携アプリ（証明書利用者信頼／エンタープライズアプリケーション）を棚卸しします。情シスが把握していないMendixアプリでも、SSOを使っている以上IdPには必ず登録が残っています。ここが一番確実な入口です。
  2. 該当アプリの開発担当（事業部門またはベンダー）に、SAMLモジュールのバージョンを確認する。Mendixでは、Marketplaceのモジュールをアプリのプロジェクト内に取り込む形で組み込みます。Studio Proでアプリを開き、モジュール一覧のSAMLの版数を見てもらうのが確実です。
  3. 修正版へ更新し、再ビルド・再デプロイしてもらう。ここが今回の肝です。

3点目を強調するのは、この脆弱性はMendixのプラットフォーム側が勝手に直してくれる種類のものではないからです。モジュールはアプリの一部として同梱されるため、アプリごとに更新して作り直さない限り、古い署名検証コードがそのまま動き続けます。「クラウド（Mendix Cloud）で動いているからベンダーが面倒を見てくれるはず」という期待は、この件では通用しません。

現場目線の課題：資産台帳に載らないアプリをどう追うか

正直なところ、この手の脆弱性で一番しんどいのは技術的な難しさではなく、「誰が作ったのか分からないアプリの担当者を探すところ」です。ローコードは「情シスを待たずに現場が作れる」ことが価値なので、その裏返しとして、購買記録にもソフトウェア資産管理台帳にも残らないアプリが増えます。異動でオリジナルの作成者がいなくなり、実質的に誰も保守していないアプリが動き続けている、という光景は珍しくありません。

そのため、対処と並行して「次に同じことが起きたときに30分で名寄せできる状態」を作っておく価値があります。具体的には、IdPの連携アプリ一覧に「業務所管部署」と「開発・保守の連絡先」を必ず記録しておくことです。SSOを許可する条件として運用に組み込めば、情シスの権限の範囲で無理なく実施できます。今回のような「SSO部品の脆弱性」は今後も繰り返し出るため、この一覧はそのたびに効きます。

同種の話は、Appsmithに保存型XSS、内製ツール基盤の盲点やn8nに脆弱性34件 認証情報の窃取が可能でも触れています。内製化基盤は「便利な道具」であると同時に「情シスの視界の外にある認証の入口」でもあります。

情シスはどうすべきか

個別の対応は上記のとおりですが、体制面はすでに公的機関が整理した指針があるため、自前でチェックリストを作るより既存の公的資料に沿って点検するほうが早く、説明もしやすいです。

あわせて、地味ですが効くのが現場部門への啓発です。「内製アプリを作るのは歓迎、ただしSSOを繋ぐときは必ず情シスに一報を」という一線を共有できているかどうかで、脆弱性公表時の初動速度がまったく変わります。

まとめ

  1. Mendix SAMLモジュールに署名検証の不備（CVE-2026-80465、CVSS v3.1 8.7／v4.0 8.8）。特定のSSO構成で未認証のアカウント乗っ取りにつながる恐れがあります。
  2. 修正版はMendix 9.24系がV3.6.27、Mendix 10／11系がV4.2.3。判定はMendix本体ではなくSAMLモジュールの版数で行い、アプリごとに更新・再デプロイが必要です。
  3. 情シスの現実的な入口はIdPの連携アプリ一覧。ここに所管部署と保守連絡先を紐づけておくと、この種の脆弱性に毎回効きます。

関連記事

出典

タイトルとURLをコピーしました