【更新 2026-08-19】本記事を見直し、修正しました。主な修正点：JVN iPedia への登録は2件とも行われていた点（CVE-2026-13380＝JVNDB-2026-028657）を訂正、影響を受けるバージョンの表記を一次情報（SRAアドバイザリ／NVD）の記載に合わせ、CVE-2026-13380 に NVD が付与した CVSS v3.1 基本値を併記しました。
遠隔医療（テレヘルス）プラットフォーム「VSee Clinic」に、深刻度の高い脆弱性が2件公開されました。1件は認証不要でSFTPの接続情報が平文のまま漏れるもの（CVE-2026-13380、CVSS v4.0で9.0＝Critical）、もう1件は認証済みユーザーが他人のファイルを列挙・取得・削除できるIDOR（CVE-2026-13381、同8.7＝High）です。修正版はすでに提供されており、VSee Clinic 7.1.26.1 / API 1.3.0.1 以降へ更新すれば解消します。
「うちは遠隔医療なんてやっていない」と思った方こそ、後述の「自社に関係あるのか」の節だけは読んでください。この製品はSDK/API として他社のアプリに組み込まれる形でも提供されています。
この記事でわかること
- VSee Clinic とは何をする製品で、どこに組み込まれて動いているのか
- 公開された2件の脆弱性の中身と、影響を受けるバージョン・修正版
- 「自社は該当するのか」を判定するための具体的な確認手順
- IDOR（安全でない直接オブジェクト参照）という穴が、自社の内製Webアプリにも潜んでいる理由
VSee Clinicとは何者か
VSee Clinic とは、医療機関がオンライン診療（ビデオ診察）を行うためのクラウド型プラットフォームです。予約管理、ビデオ診察、遠隔での患者モニタリング、電子署名、請求までを一通り扱います。
使うのは主に病院・クリニック・遠隔診療サービス事業者で、米国の HIPAA（医療情報の保護法制）準拠をうたう製品です。日本国内での知名度は高くありません。
ただし重要なのは3点目です。VSee は完成品のサービスだけでなく、他社が自前のヘルスケアアプリを作るための SDK / API としても提供されています（同社サイトは「1週間でテレヘルスアプリを構築できる」構成部品として案内しています）。同社サイトの記載によれば、導入先には大手医療機器・医薬品流通企業や大学病院、政府機関なども含まれるとされています。
つまり、「VSee」という名前で契約した覚えがなくても、委託先や関連会社が導入したオンライン診療アプリ・健康相談アプリの内部で VSee のコンポーネントが動いている可能性があるということです。「うちは使っていない」と即断せず、後述の手順で確認してください。
何が起きたのか
米セキュリティ企業 Security Risk Advisors（SRA）の研究部門が2件の脆弱性を発見し、2026年7月20日にアドバイザリと CVE が公開されました。2件とも8月17日に JVN iPedia へ登録されました（IDOR の CVE-2026-13381 が JVNDB-2026-028656、SFTP認証情報露出の CVE-2026-13380 が JVNDB-2026-028657）。
| CVE | 内容 | 深刻度 | 認証の要否 |
|---|---|---|---|
| CVE-2026-13380 | 3つの認証不要のエンドポイントのHTTP応答に、SFTPの接続情報が平文で含まれる | CVSS v4.0：9.0（Critical）／NVDのv3.1：7.5（High） | 不要 |
| CVE-2026-13381 | ファイルAPI（/v1.3.0/api/files）の remark パラメータを書き換えると、他ユーザーのファイルを列挙・取得・削除できる（IDOR／CWE-639） |
CVSS v3.1：8.1／v4.0：8.7（High） | 必要（一般利用者権限で可） |
CVE-2026-13380 は、対象サーバで SFTP連携が設定されている場合にのみ認証情報が応答に載る、という条件付きです。ただしその条件を満たしていれば、攻撃者はログインすら必要なく、応答を1回観測するだけで接続情報を手に入れられます。具体的にどのエンドポイントかは、悪用を避けるため公開されていません。
影響を受けるバージョンと修正版
| 製品 | 影響を受けるバージョン | 修正版 |
|---|---|---|
| VSee Clinic | 7.1.26（アドバイザリ表記：7.1.26 以上 7.1.26.1 未満） | 7.1.26.1 以降 |
| VSee Clinic API | 1.3.0（同：1.3.0 以上 1.3.0.1 未満） | 1.3.0.1 以降 |
SRAのアドバイザリと NVD が影響ありと明記しているのは 7.1.26 / API 1.3.0 です。それより古いバージョンは「影響なし」とも書かれていないため、7.1.26.1 未満はすべて更新対象として扱うのが安全です。
開示のタイムラインは、2026年6月16日に SRA がベンダーへ報告、6月24日にベンダーが修正版をリリース、7月20日に公表、という順です。公表時点ですでに修正版があるため、対応の第一歩はバージョン確認と更新になります。
なぜこの2件は危険なのか
認証情報の露出は「そのシステムの外」に被害が広がる
CVE-2026-13380 の CVSS v4.0 ベクタは CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N です。注目すべきは末尾の SC:H/SI:H、つまり後続システムへの影響が「高」と評価されている点です。
漏れるのは VSee Clinic 自身のデータではなく、連携先のSFTPサーバへの鍵です。医療の現場でSFTPが使われるのは、検査結果・レセプト・患者名簿といったファイルを別システムと受け渡す用途が中心です。そこに正規の認証情報でアクセスされると、VSee Clinic 側のログをいくら見ても異常は見つかりません。侵入経路と被害範囲が別のシステムに分かれるのが、この種の脆弱性のいやらしさです。
IDORは「正規のアクセス」に見えるので気づけない
IDOR（Insecure Direct Object Reference＝安全でない直接オブジェクト参照）とは、リクエスト中のID等のパラメータを書き換えるだけで、本来アクセス権のない他人のデータに触れてしまう欠陥です。今回は remark というパラメータがその役割を果たしていました。
厄介なのは、攻撃に特別な道具が要らないことです。ログイン済みのアカウントが1つあれば、ブラウザの開発者ツールでパラメータを1文字書き換えるだけで成立します。しかもサーバから見れば「認証済みユーザーからの正常なAPIリクエスト」なので、WAFにも異常検知にも引っかかりにくい。今回はさらに削除まで可能なので、情報漏えいだけでなく診療記録の消失にも直結します。
権限設計の考え方そのものは目新しくありません。最小権限の原則を実装レベルで徹底できていたか、という古典的な問題です。同種の認可バイパスはApache ActiveMQの事例など、製品を問わず繰り返し出ています。
自社に関係あるのか──「使っていない」の確認手順
日本の一般的な事業会社で VSee Clinic を直接契約しているケースは多くないでしょう。ただし、次のような形で関係している可能性があります。
- 健康保険組合・産業医面談・従業員向けオンライン健康相談で、外部のオンライン診療サービスを利用している
- 医療・ヘルスケア関連の受託開発や自社サービスで、テレヘルスSDKを組み込んでいる
- グループ会社や委託先が導入したアプリの基盤として使われている
該当判定は、製品名だけを探しても見つからないことがあります。次の順で確認するのが現実的です。
- 通信ログから探す：プロキシ／DNS／ファイアウォールのログに
vsee.com配下のドメインへの通信がないか検索する。名前を知らずに使っている場合、ここに痕跡が出ます。 - APIパスで探す：自社が運用・開発しているアプリのリバースプロキシやAPIゲートウェイのログに
/v1.3.0/api/を含むパスがないか確認する。 - SFTP連携の有無を確認する：CVE-2026-13380 はSFTP連携が設定されている場合のみ成立します。該当製品を使っていて連携がある場合は、更新に加えてSFTPの認証情報をローテーション（変更）してください。修正版を当てても、すでに漏れた情報は無効になりません。
- 委託先・ベンダーに問い合わせる：オンライン診療系のサービスを利用しているなら、使用コンポーネント（SBOM）と今回の2件への対応状況を書面で確認する。
4番目は面倒ですが、SDK組み込み型の製品は資産管理台帳に載らないのが最大の問題です。台帳に「VSee」と書かれていないことは、使っていない証拠にはなりません。この構造はサプライチェーン攻撃で繰り返し語られてきた弱点と同じものです。
現場目線の所感
正直なところ、この手の「海外製SaaSの、しかも自社が直接契約していないかもしれない製品」の脆弱性情報は、情シスにとって最も扱いに困る類です。CVSS 9.0 と言われても、まず自社が該当するかどうかを調べる時点で半日が溶ける。しかも調べた結果「該当なし」だった場合、その半日は何も生みません。
それでも今回、確認する価値があると考えたのは、漏れるものが「連携先SFTPサーバの認証情報」だからです。ファイル連携の口は、たいてい何年も前に作られ、担当者が異動し、パスワードは変わっていません。仮に漏えいしても、当分誰も気づけない性質のものです。逆に言えば、この記事をきっかけに「そういえばうちのファイル連携用アカウント、いつからあのパスワードだったか」と棚卸しできるなら、該当なしでも収穫はあります。
もう一つ。今回のベンダー対応は、報告から修正リリースまで8日と速い部類です。それでも公表から情報が日本語で届くまでには1か月近くかかっています。この時間差は、海外製SaaSを使う限り常について回ると考えておくべきでしょう。
情シスはどうすべきか
個別の対策チェックリストを自作するより、公的機関の指針に沿って進めるほうが確実で、経営層への説明もしやすくなります。
- 医療情報を扱う場合：厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」。外部サービス利用時の責任分界や委託先管理の考え方がまとまっており、ベンダーへの確認事項を組み立てる土台になります。
- Webアプリの実装・調達で見るべき点：IPA「安全なウェブサイトの作り方」。今回のIDORのようなアクセス制御の不備は、まずここで説明されている観点を発注仕様や受入テストに落とすのが早道です。
- 体制づくり全般：IPA「中小企業の情報セキュリティ対策ガイドライン」。委託先管理の項が、SDK組み込み型サービスの棚卸しにそのまま使えます。
あわせて、利用部門への地道な啓発も効きます。医療・健康系のアプリは現場部門が単独で契約しがちで、情シスが存在自体を知らないことが珍しくありません。「外部サービスを契約する前に一声かけてほしい」を繰り返し伝えるほうが、事後の調査コストよりはるかに安く済みます。
中長期の視点：IDORは自社の内製アプリにもある
今回の IDOR は、VSee 固有の失敗ではありません。「ログイン済みなら、そのIDのデータは見せてよい」という暗黙の前提で書かれたコードは、どこの社内システムにもあります。顧客ポータル、申請システム、ファイル共有、いずれも「認証」は作り込むのに「認可」は素通りになりがちです。
脆弱性診断を発注するときは、「別アカウントで他人のリソースIDを指定したときの挙動」を明示的にテスト項目に入れているかを確認してください。自動スキャナはIDORを見つけるのが苦手で、複数アカウントを使った手動検証が必要になります。この観点が抜けた診断は、報告書は薄いのに穴は残ったまま、という結果になりがちです。
なお深刻度の読み方はCVSSの解説記事も参考にしてください。今回のように v3.1 で 8.1、v4.0 で 8.7 と数値がずれるケースは今後も増えます。
まとめ
- VSee Clinic に2件の脆弱性。認証不要でSFTP接続情報が平文露出（CVE-2026-13380、CVSS 9.0）と、他人のファイルを取得・削除できるIDOR（CVE-2026-13381）。修正版 7.1.26.1 / API 1.3.0.1 が提供済み。
- 直接契約していなくても、SDK/API として他社アプリに組み込まれている可能性がある。通信ログの
vsee.com検索と委託先への確認で棚卸しを。SFTP連携がある場合は更新に加えて認証情報のローテーションが必須。 - IDOR は自社の内製Webアプリにも同じ形で潜む。診断の発注時に「他人のIDを指定したときの挙動」をテスト項目へ明記する。
出典
- JVN iPedia：VSeeのVSee Clinic等の複数製品におけるユーザ制御の鍵による認証回避に関する脆弱性（JVNDB-2026-028656）
- JVN iPedia：VSeeのVSee Clinic等の複数製品における複数の脆弱性（JVNDB-2026-028657）
- NVD：CVE-2026-13381 ／ CVE-2026-13380
- Security Risk Advisors Labs：VSee Clinic Advisory（発見者による技術詳細・開示タイムライン）
- VSee 公式サイト：vsee.com（製品概要・SDK提供形態）
- 厚生労働省：医療情報システムの安全管理に関するガイドライン 第7.0版（令和8年6月）
- IPA：安全なウェブサイトの作り方
