Collibra Agentに脆弱性2件、未認証でRCE

データカタログ基盤「Collibra」のエージェントに、深刻な脆弱性が2件公表されています。認証不備（CVE-2026-10622）とZIP展開時のパストラバーサル（CVE-2026-10621）で、この2つを連鎖させると、認証なしの攻撃者がWebシェルを設置してリモートコード実行に至ると報告されています。CERT/CCの公表は2026年6月2日、JVNでの注意喚起は6月3日です。

厄介なのは、Collibraを導入したのが情シスではなく、データ活用推進部門やDX部門であるケースが多い点です。「うちはCollibraなんて使っていない」と即断する前に、社内サーバでエージェントが動いていないかを確認してください。修正版はすでに提供されています。

この記事でわかること

• Collibraとは何をするもので、社内のどこに常駐しているのか
• 2件の脆弱性の内容と、なぜ連鎖するとRCEになるのか
• 影響を受けるバージョンと修正版の一覧
• 「使っていないつもり」の組織が該当有無を確かめる具体的な手順

Collibraとは何か、そのエージェントはどこにいるのか

Collibra（コリブラ）とは、社内に散らばったデータの所在・意味・品質・利用ルールを一元管理するための、データカタログ／データガバナンスのプラットフォームです。ベルギー発祥のベンダーが提供しており、日本国内でも導入事例が報じられています。

使うのは主に、データ活用を推進する部門です。「この売上データはどのシステムが持っていて、誰が更新していて、個人情報を含むのか」を整理し、分析部門が安全にデータを使えるようにするのが役割です。つまり、情シスのセキュリティ担当が主管する製品ではないことが多い——ここが今回の落とし穴になります。

提供形態はSaaS版（Collibra Platform）と、自社で立てる自己ホスト版（Collibra Platform Self-Hosted、いわゆるオンプレミス版）の2つがあります。そして今回問題になったCollibra Agent は、ホストシステムにインストールされる独立したサービスで、Web管理画面とは別のポートで待ち受けます（CERT/CCの記述）。関連して、オンプレのJobserverを使う構成ではCollibra Consoleも社内サーバに同居します。

ライブラリのように他社製品へ同梱されるタイプの部品ではありませんが、実務上の見え方はよく似ています。「事業部門が契約したSaaSに付随して、社内ネットワークの中にエージェントが1台立っている」という形で存在し、情シスの資産管理台帳には載っていない。これが最も危険なパターンです。

何が起きたのか：認証不備とZip Slipの2件

CERT/CCが Vulnerability Note VU#873170 として公表した内容は次のとおりです。

なお、このCVSSスコアはCISAのADP（Authorized Data Publisher）による評価で、記事執筆時点でNVD自身の評価はまだ付与されていません。ベンダー独自の評価とは差が出る可能性があります。

なぜ2件が連鎖するとRCEになるのか

答えは「入口」と「実行」がきれいに揃ってしまうからです。CVE-2026-10622で認証をすり抜けてリストアAPIに到達し、CVE-2026-10621でWebからアクセスできるディレクトリにJSPファイルを書き込む。あとはそのJSPをブラウザから叩けば、サーバ上で任意のコードが動きます。いわゆるWebシェルの設置です。

単体では「情報が少し漏れる」「ファイルが書ける」で済む脆弱性が、組み合わさると未認証RCEになる。パッチ適用の優先度を単体のCVSSだけで決めると読み違える典型例です。

「外に出していないつもり」が効いていなかった可能性

CERT/CCの記述で実務上いちばん重いのはここです。脆弱なRESTエンドポイントをホストするWebサービスが、インストーラスクリプトに渡した設定にかかわらず、利用可能なすべてのネットワークインターフェースにバインドしていたことが観測されています。

つまり、構築時に「このIPだけで待ち受けるよう指定した」つもりでも、実際には全インターフェースで口を開けていたことになります。設計書やパラメータシート上の記載を信じるのではなく、稼働中のサーバで実際のリッスン状態を確認するしかありません。この手の「設定した内容と実際の挙動が食い違う」問題は、管理系サーバの脆弱性全般で繰り返し見られるパターンです。

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

NVDの記載では、SaaS版は各系列でこれらのビルド未満が影響を受けるとされています。SaaS版はベンダー側で更新が進む一方、自己ホスト版とその周辺コンポーネントは利用者側で更新する必要があります。公表から2か月以上が経過しているため、まだ手つかずであれば時間的な猶予は少ないと考えてください。

自社が該当するかをどう確かめるか

「情シスが知らないところに立っている」ことが本件の本質なので、確認は資産の洗い出しから始めます。

• 導入有無を部門に聞く：データ活用推進、DX、経営企画、データマネジメント担当。Collibraに限らず「データカタログ」「データガバナンスツール」という言い方で聞くと当たりやすくなります。
• オンプレ構成の有無を確認する：SaaS契約でも、Jobserver や Collibra Console、エージェントが社内サーバに置かれていることがあります。契約書ではなく構成図で確認してください。
• 実際のリッスン状態を見る：該当サーバで ss -ltnp（Linux）や netstat -ano（Windows）を実行し、Web管理画面とは別ポートで待ち受けているプロセスが 0.0.0.0（全インターフェース）にバインドしていないかを確認します。エージェントの待ち受けポートは構築時の設定に依存するため、インストール時のパラメータと突き合わせてください。
• 到達性を確認する：/rest/ 配下が、業務上必要のないネットワークセグメントやインターネットから到達できないかを外側から検証します。
• ログを遡る：/rest/restore へのPOSTや、Webアクセス可能なディレクトリに見覚えのない .jsp ファイルが増えていないかを確認します。

CERT/CCが示す回避策も「管理インターフェースへのアクセスを可能な限り制限する」「信頼できないネットワークにRESTエンドポイントを晒さない」という、ネットワーク側の封じ込めです。修正版の適用がすぐにできない場合は、まずここを固めることになります。管理画面をネットワーク的に隔離する考え方は、ZTNAの記事で整理した「必要な人だけが必要な資源に到達する」設計と同じ発想です。

現場目線の課題：台帳に載らないサーバとの終わらない追いかけっこ

正直に言えば、この種の脆弱性でいちばんしんどいのは、技術的な難しさではありません。「そのサーバの存在を知らなかった」という一点です。

データ活用の機運が高まるほど、事業部門は自分たちの判断でツールを契約します。SaaSだから情シスの手を借りずに始められる——その触れ込み自体は正しいのですが、実際には連携のためのエージェントやジョブ実行サーバが社内に降りてくる。契約はSaaS、実体はオンプレ。この非対称が、資産管理台帳とネットワーク実態のズレを毎年少しずつ広げていきます。

加えて、こうしたデータ基盤系のツールは定義上「社内のあらゆるデータの目録」を持っています。侵入されたときに漏れるのは、そのサーバ上のファイルだけではありません。どのシステムにどんな機微データがあるかという、攻撃者にとっての設計図です。優先度を判断するときは、サーバ1台の重要度ではなく、そこに集まっているメタデータの意味で考えたほうが実態に合います。

同じ構図は、Apache AirflowやRayのようなデータ／AI基盤の脆弱性でも繰り返されています。「開発・分析の人たちの領域だから」と線を引いた瞬間に、そこが盲点になります。

情シスはどうすべきか

個別の対処は前述のとおりですが、根本は「部門導入のツールをどう把握するか」という運用の問題です。自前でチェックリストを作り込むより、公的機関の指針を土台にしたほうが、経営層への説明にも使えて効率的です。

• 中小企業の情報セキュリティ対策ガイドライン（IPA）：情報資産の洗い出しと管理の考え方が整理されています。台帳運用の見直しはここから。
• 対策のしおり（IPA）：事業部門への啓発資料として使えます。「ツールを入れる前に情シスに一声かけてほしい」を、感情論でなく資料で伝えるための材料です。
• セキュリティインシデント対応 机上演習教材（IPA）：「知らないサーバが侵害された」というシナリオは演習題材として現実的です。

あわせて、地道ではありますが、事業部門との定期的な対話を仕組みにしておくことが結局いちばん効きます。禁止して隠されるより、申告してもらったほうが安全です。

中長期の視点

データガバナンス基盤は今後さらに増えます。生成AIの社内活用が進むほど「どのデータをAIに食わせてよいか」を管理する必要が出てきて、その受け皿としてデータカタログが選ばれるからです。データを守るために入れた仕組みが、守るべきデータの地図ごと狙われるという構図は、これから一般的になっていくと考えたほうがよいでしょう。

導入時に情シスが関与できる余地を作っておくこと、そして最低限「社内で待ち受けている口」の一覧を定期的に更新できる体制を持つこと。この2つが、次に同種の勧告が出たときの初動速度を決めます。

まとめ

1. Collibra Agentに認証不備（CVE-2026-10622、CVSS 8.2）とZip Slipによるパストラバーサル（CVE-2026-10621、CVSS 7.5）の2件。連鎖するとWebシェル設置による未認証RCEに至ると報告されています。
2. インストーラの設定にかかわらず全ネットワークインターフェースにバインドしていた観測があり、「外に出していないつもり」が通用しない可能性があります。稼働中サーバでリッスン状態を実測してください。
3. 修正版はSaaS版・自己ホスト版とも提供済み。まずは「そもそも社内にあるか」の確認から。データ活用部門が契約し、情シスの台帳に載っていないケースを想定して洗い出すことが要点です。

出典

• JVNVU#95031413 Collibra Platform Agentにおける複数の脆弱性（JVN、2026年6月3日）
• VU#873170: Collibra Agent contains improper authentication and path traversal vulnerabilities（CERT/CC、2026年6月2日）
• NVD – CVE-2026-10621
• NVD – CVE-2026-10622