データ管理ツール『Directus』に情報漏れの脆弱性、パスワード付き共有リンクを第三者に見られる恐れ CVE-2026-61836、最新版12へ更新を

企業のデータを管理し、Webサイトやアプリの裏側でデータを出し入れする土台として世界中で使われているソフトDirectus（ディレクタス）に、情報漏れにつながる脆弱性が見つかりました。CVE-2026-61836という番号が付けられ、深刻度スコア（CVSS）は10段階中の8.6。ログインなしで、本来は別の人向けに用意された「共有リンク」の中身を、無関係の第三者がのぞき見できてしまう問題です。パスワードをかけた共有リンクでも、条件がそろえばパスワードなしで中身を取り出せます。

先にはっきりさせておきます。影響を受けるのは、2つの条件が両方そろった環境だけです。1つはデータの表示を速くする「キャッシュ機能」を自分でオンにしていること（初期設定ではオフ）、もう1つはデータを外部に見せる「共有リンク（Shares）」機能を使っていることです。どちらか一方でも当てはまらなければ、この脆弱性の影響は受けません。問題は最新版のバージョン12.0.0で修正済みで、該当する使い方をしている場合はここへ更新すれば解消します。

この記事では、Directusとは何か、なぜログインなしで他人の共有内容が見えてしまうのか、そして自分の環境が対象かどうかの見分け方までを、専門知識がなくてもわかるように順に説明します。

Directusとは何か。なぜ情報漏れが起きるのか

Directusは、すでにあるデータベース（顧客名簿や商品情報などを整理してためておく仕組み）に接続するだけで、データを読み書きするための窓口（API）と、担当者がブラウザで中身を編集できる管理画面を自動で用意してくれる、オープンソースのバックエンドソフトです。この分野はヘッドレスCMS（表示部分を持たず、データの管理だけを担うコンテンツ管理システム）とも呼ばれ、Webサイトやスマホアプリのデータをまとめて扱う土台としてよく使われます。

開発元のGitHubページには約3万4千個の「スター（お気に入り）」が付き、海外ではTripadvisorやAdobe、メルセデス・ベンツといった企業での採用も伝えられています。無料で始められて自社サーバーに置いて使えるため、開発者や社内の情報システム部門に広く知られた存在です。

今回問題になったのは、Directusが持つ「共有リンク（Shares）」という機能です。これは、管理画面にログインしていない社外の人にも、特定のデータだけを見せるためのURLを発行できる仕組みで、URLごとに「誰に何を見せるか」の権限や、必要に応じてパスワードを設定できます。ところが、表示を速くするための「キャッシュ」（一度作った表示結果を一時的にため込み、次回はそれを使い回すしくみ）と組み合わさったときに、そのため込んだ結果が、本来見せるべきでない相手にまで配られてしまうのが、この脆弱性の中身です。

脆弱性の概要

CVE-2026-61836：共有リンクの中身が別の人に配られる

この脆弱性は、Directusが「どの表示結果を、どの利用者のものとして覚えておくか」を取り違えることから起きます。要点を下の表にまとめます。

脆弱性を報告したのはtr4ce-ju氏で、GitHubのセキュリティアドバイザリ（GHSA-c6w9-5g5j-jh2p）として2026年6月24日に公開され、同日リリースの12.0.0で修正されました。米国のNVDにCVE-2026-61836として登録されたのは7月15日です。

誰が何のために狙うのか

分類コードや数値だけでは、「自分に関係あるのか」が伝わりにくいものです。この穴を悪用するのはどんな相手で、何をして、何が漏れるのかを整理します。

狙うのは高度な技術を持つ攻撃者に限りません。想定されるのは、共有リンクのURLを手にした人や、そのURLにたどり着いた匿名の第三者です。共有リンクは社外にも配られるものなので、URLさえ知っていれば誰でも接触できます。

そうした相手がこの穴を使ってできるのは、本来は別の人向け（あるいはパスワードで守られていたはず）の共有内容を、ため込まれた表示結果ごと横取りして読むことです。誰かが一度その共有を開いて表示結果がキャッシュに残ると、後から来た匿名のアクセスや、別の共有リンクを持つだけの人が、同じ中身を受け取れてしまいます。パスワード付きの共有でも、いったんキャッシュに載れば、以降はパスワードのやり取りなしで中身を引き出せると報告されています。

漏れる範囲は、その共有リンクにどんな権限を割り当てていたかで変わります。権限を細かく絞っていれば主キー（データの見出しにあたる番号）程度で済みますが、閲覧範囲を広く許していれば、その権限で見える情報がまるごと外部に出ます。Directusを運用する企業・組織にとっては、限定公開のつもりだったデータが不特定の相手に渡ることが最大の痛手であり、そのサービスを利用する人にとっては、自分の情報が意図しない相手に見られる可能性がある、という形で影響します。だからこそ、次に説明する「自分が対象か」の見分けが重要になります。

何が起きているのか。仕組みを分解する

ここからは少し技術寄りの説明です。仕組みを知りたい方向けなので、対策だけ知りたい方は読み飛ばして構いません。

キャッシュは、同じ要求に毎回ゼロから答えを作らずに済むよう、「この要求にはこの答え」という対応をラベル（キャッシュキー）付きで保存しておくしくみです。次に同じラベルの要求が来たら、保存済みの答えをそのまま返します。速さのための工夫ですが、ラベルの付け方を誤ると、別人の答えを取り違えて返してしまいます。

Directusは、このラベルを「バージョン・要求先のパス・検索条件・利用者（アカウント）」の4つで作っていました。問題は、ここに「その人がどの権限で・どの共有リンクとして見ているか」という認可の情報（share・role・admin・policiesなど）が含まれていなかった点です。とくに共有リンク経由のアクセスでは利用者が「なし（匿名）」として扱われるため、すべての共有リンクと匿名アクセスが同じラベルになってしまい、ある共有の答えが、別の共有を持つ人や匿名の人にそのまま配られました。技術的には、機密情報を含む結果をキャッシュしてしまう不備（CWE-524）と、利用者が操作できる値を鍵にした認可の回避（CWE-639）が重なった形です。

やっかいなのは、この誤りが時間をまたいで残ることです。キャッシュには保持期限（CACHE_TTL、一般に5〜30分程度）があり、その間は誤った配信が続きます。保存先にRedisのような外部の保管庫を使っている場合、サーバーを再起動しても汚れたキャッシュが生き残ることがあります。パスワード保護についても、パスワードを知る正規の人が一度開いてキャッシュを作ってしまえば、その後はパスワードの確認を経ずに中身が取り出せる、という順序で回避が成立します。

自分は影響を受けるのか。条件の早見表

この脆弱性で最も大事なのは、「自分のDirectusが条件に当てはまるか」です。キャッシュを初期設定のまま使っている（オフ）なら、この問題の影響は受けません。下の表で確認してください。

キャッシュを使っているかどうかは、設定のCACHE_ENABLEDがtrueになっているかで判断できます。初期状態ではfalse（オフ）のため、表示速度を上げるために自分でオンにした覚えがなければ、多くの場合は対象外です。ただし、共有リンクを実際に使ってデータを外部に見せている本番環境でキャッシュもオンにしている場合は、条件がそろうため優先して更新してください。

発見から公開までの経過

この脆弱性は、修正が済んでから正式な番号が付くまでに約3週間あります。時系列を押さえておくと状況を判断しやすくなります。

← スワイプで移動

今すぐやるべきこと

対応はシンプルです。Directusを12.0.0以降へ更新する。これで、キャッシュのラベルに権限や共有の情報が正しく含まれるようになり、問題は解消します。更新の手順や変更点はDirectus公式のリリースノートで確認できます。

すぐに更新できない事情がある場合は、応急処置としてキャッシュ機能を一時的にオフにする（CACHE_ENABLEDをfalseに戻す）ことで、この経路での漏れを止められます。すでにキャッシュに誤った内容が残っている可能性があるため、更新やキャッシュ停止の後は、保持していたキャッシュを消去（パージ）しておくと確実です。Redisなどの外部保管庫を使っている場合は、そちらのデータも消し込みます。

Directusのように自社サーバーで動かすオープンソースのソフトは、導入が手軽な一方で、修正情報を自分で追い続ける必要があります。使っているオープンソース部品にどんな脆弱性が出ているかをまとめて点検したいときは、オープンソースの安全性を確認する方法をまとめた記事もあわせて参考にしてください。

全環境が対象ではない。それでも今知る意味

改めて整理します。CVE-2026-61836は危険度8.6ですが、影響するのは「キャッシュを自分でオンにし、かつ共有リンク機能を使っている」環境に限られ、実際に悪用された報告も今のところありません。多くのDirectus利用者にとっては、あわてる必要のないニュースです。

それでも取り上げるのは、この2つの条件がそろう本番環境は決して珍しくないからです。表示を速くするためにキャッシュをオンにし、社外にデータを見せるために共有リンクを使う、というのはよくある組み合わせです。しかも今回は、パスワードで守っていたはずの共有までのぞかれうる点が見過ごせません。「速くするための工夫が、見せてはいけない相手にまで答えを配ってしまう」という構図は、キャッシュを使うあらゆるシステムに通じる教訓でもあります。

当ブログでは、こうしたデータ管理・CMS系のソフトに見つかった脆弱性を継続して追っています。ログインなしで情報が露出する恐れが指摘された企業向けCMS Sitefinityの事例や、ブログ作成ツールGhostの事例も、あわせて確認しておくと、この分野で繰り返し起きる問題のパターンが見えてきます。

よくある質問

Q. Directusを使っているが、キャッシュはオンにしていない。何かすべき？

A. 今回のCVE-2026-61836に関しては、キャッシュがオフ（初期設定のまま）なら影響を受けません。ただし通常のセキュリティ更新は続けてください。心配な場合は12.0.0へ更新しておくのが確実です。

Q. パスワード付きの共有リンクなら安全では？

A. 条件がそろうと安全ではありません。パスワードを知る人が一度その共有を開いて表示結果がキャッシュに残ると、以降はパスワードのやり取りなしで中身を取り出される可能性があります。該当する場合は12.0.0へ更新してください。

Q. データを書き換えられたり、サービスを止められたりする？

A. 今回の脆弱性は情報漏れ（機密性）に限られ、データの改ざんやサービス停止は起きません。ただし、限定公開のつもりのデータが外部に渡ること自体が重大な問題です。

参照元

• ▸ NVD - CVE-2026-61836（2026年7月15日公開）
• ▸ GitHub Security Advisory - GHSA-c6w9-5g5j-jh2p（2026年6月24日）
• ▸ Directus - リリースノート（12.0.0）
• ▸ Directus 公式サイト
• ▸ Directus - GitHubリポジトリ