Cal.com 脆弱性が2025年12月から2026年1月にかけて立て続けに公開された。スケジューリング（予約調整）OSSとして知られるCal.com（GitHubリポジトリはcalcom/cal.comからcalcom/cal.diyへ改称）で、CVSS9.9〜10.0の重大（Critical）脆弱性が3件、約40日間のうちに相次いで公開されている。うち2件は認証バイパス、1件は未認証でのリモートコード実行（RCE）だ。さらにCal.com, Inc.は2026年4月、「AI駆動の攻撃者からコードを守るため」を理由に本体のクローズドソース化を発表しており、その直前にこれだけの重大CVEが集中していたという時系列は、日本語でまだ解説されていない。この記事では3件のCVEの技術的な中身と、自己ホスト環境の確認コマンドを整理する。
この記事はサプライチェーン全体の防御を扱うサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストの個別事例として、Cal.com/cal.diyの重大CVE3件に絞って扱う。
- ・正体：Cal.com, Inc.が開発するスケジューリングOSS。GitHubリポジトリは
calcom/cal.comからcalcom/cal.diyへ改称・分離され、ライセンスもAGPL-3.0からMITへ変更された。 - ・何が起きた：2025-12-03〜2026-01-13の約40日間にCVSS9.9〜10.0の重大脆弱性が3件公開された（認証バイパス2件・未認証RCE1件）。
- ・時系列のねじれ：この直後の2026年4月、Cal.com, Inc.は「AI駆動の攻撃者対策」を理由にクローズドソース化を発表している。
- ・自環境の確認：
package.jsonのversionまたはDockerイメージタグを見て6.0.7以上かを確認する（3件すべての修正を含む最小バージョン）。 - ・注意：旧AGPL-3.0版から更新するとライセンス条件（コピーレフト義務）も変わる。
Cal.com 脆弱性の正体——cal.diyへの改称と何が起きたのか
Cal.comは、Google CalendarやOutlookと連携して面談・面接・予約枠の調整を自動化するスケジューリングツールで、Cal.com, Inc.（企業）が開発している。GitHub API実測（2026-08-08時点）では⭐47,328・fork 14,684、TypeScript主体（約18MB）のNext.js/Reactアプリケーションで、コミット総数は約16,484、contributor数は約969（いずれもLink headerのページ数由来の概算値）。最新リリースはv6.2.0（2026-03-01公開）で、企業主導ながら本番運用実績の多いプロダクトだ。
まず押さえておく必要があるのは、リポジトリ名がすでに変わっているという点だ。従来のcalcom/cal.comは、現在はcalcom/cal.diyという名前に改称・分離されている。GitHub APIでcalcom/cal.comにリクエストすると301 Moved Permanentlyが返り、calcom/cal.diyのリポジトリIDへリダイレクトされることを確認済みだ。ブックマークや過去記事のリンクがcalcom/cal.comのままだと、404にはならず自動転送されるため名前が変わったことに気づきにくい。
ライセンスも同時に変更されている。cal.diy分離時に、旧calcom/cal.com時代のAGPL-3.0からMITへ切り替わった（Cal.com公式ブログで確認できる）。LICENSEファイル原文は「Copyright (c) 2020-present Cal.com, Inc.」のMIT全文で、README/GitHub API（"license":"mit"）とも一致している。
① 何ができる：Cal.com/cal.diyはGoogle Calendar等と連携する予約調整・スケジューリングOSS ② 何を解決する：面談・面接調整の往復連絡を自動化する ③ 何を代替できる：Calendly等の商用SaaSのセルフホスト代替
商用SaaS本体（cal.com、現在は非公開コード）とセルフホストOSS版（cal.diy）が分離されている構造も見落とせない。今回解説する3件のCVEは、いずれもこのセルフホスト版（cal.diy、旧cal.com）に対して公開されたものだ。star/fork数、コミット数、リリース頻度のいずれも実運用されている大規模プロダクトの水準にあり、「star数だけの見せかけ」ではなく実際に多数の環境で動いているツールである点が、今回の脆弱性の影響範囲を考えるうえで重要になる。
タイムライン：重大CVE3件からクローズドソース化発表まで
3件のCVEは、GitHub Security Advisories（GHSA）の一次情報に基づくと、いずれもCVSS9.9〜10.0のCritical評価で、約40日間のうちに連続して公開されている。
| 日付 | 出来事 |
|---|---|
| 2025-12-03 | CVE-2025-66489（GHSA-9r3w-4j8q-pw98）公開。CVSS9.9、authorize()のロジック不備による認証バイパス |
| 2025-12-07 | CVE-2025-71389（GHSA-qjx2-5xqp-cpf4）公開。CVSS10.0、同梱Next.jsのRSC処理に起因する未認証RCE |
| 2026-01-13 | CVE-2026-23478（GHSA-7hg4-x4pr-3hrg）公開。CVSS10.0（CVSS4.0表記）、NextAuth JWTコールバックのなりすまし |
| 2026年4月 | Cal.com, Inc.が「AI駆動の攻撃者からコードを守るため」としてクローズドソース化を発表 |
この並びから読み取れるのは、closed-source化の発表が唐突な方針転換ではなく、その直前の2か月間に立て続けに起きた重大インシデントの延長線上にあるという構図だ。日本語では「クローズドソース化の是非」を論じた記事（livedoor news・au Webポータルによる転載）は存在するが、その根拠となりうるCVE群そのものを解説した記事は見当たらない。closed-source化の経緯（cal.com公式ブログ、The New Stack記事）はあくまで文脈として押さえ、以下では3件のCVEそれぞれの技術的な中身を見ていく。
CVE-2025-66489／CVE-2025-71389：認証バイパスと未認証RCEの中身
最初に公開されたCVE-2025-66489（GHSA-9r3w-4j8q-pw98、CVSS9.9）は、authorize()関数内のロジック不備が原因の認証バイパスだ。GHSAの記載によれば、TOTP（二要素認証）コードを送信するだけでパスワード検証自体をスキップできてしまう欠陥で、2要素認証の有無にかかわらず影響が及ぶ。影響バージョンは5.9.7以下、修正版は5.9.8で公開されている。
4日後に公開されたCVE-2025-71389（GHSA-qjx2-5xqp-cpf4、CVSS10.0）は、Cal.comに同梱されているNext.jsのRSC（React Server Components）リクエスト処理が原因だ。攻撃者が制御する入力がデシリアライズされてしまう欠陥で、上流のNext.js側CVE（CVE-2025-55182）に由来する。未認証の状態からリモートコード実行につながりうる点が、CVSSスコアが満点の10.0になっている理由といえる。影響バージョンは5.9.9未満、修正版は5.9.9だ。
TOTPコードのみ送信"] --> B["authorize()のロジック不備
パスワード検証をスキップ"] B --> C["2FA有無を問わず
認証バイパスが成立"] D["CVE-2025-71389
攻撃者制御の入力を送信"] --> E["同梱Next.jsのRSC処理が
入力をデシリアライズ"] E --> F["未認証のまま
リモートコード実行（RCE）"]
2件は原因のレイヤーが異なる（片方は認可ロジック、もう片方は同梱フレームワークの入力処理）が、公開日が4日しか離れておらず、どちらも認証を経ずに到達できる点が共通する。特にCVE-2025-71389は「未認証RCE」という最も深刻な部類の脆弱性であり、修正版5.9.9未満のインスタンスをインターネットに公開したまま運用している場合はリスクが高い。
参考として、同リポジトリでは過去にもCritical/High級の事例がある。GHSA-vgj7-76cw-h6f8（XSS、High、2024-12-04）やGHSA-p3f6-52gv-cj7m（リポジトリ乗っ取り、Critical、2024-04-08）だ。ただしこれらは今回の主役である2025-12〜2026-01の3件とは別の時期・別の脆弱性であり、混同しないよう分けて扱う。
なお同時期に公開されたAxiosのCVE-2026-40175（CVSS10.0）も同じ満点評価のRCE系事例で、依存ライブラリ経由の脆弱性がCVSS上限に達する構図が2026年に入り繰り返し観測されている。
CVE-2026-23478：NextAuth JWTコールバックのなりすまし脆弱性
2026-01-13に公開されたCVE-2026-23478（GHSA-7hg4-x4pr-3hrg）は、CVSS4.0スコアリングで10.0（Critical）となっている。対象はcal.diyが実装するカスタムNextAuth JWTコールバックで、影響バージョンは3.1.6以上6.0.7未満、修正版は6.0.7だ。
GHSAの記載によれば、原因はJWTコールバックの検証不備にある。セッション更新（trigger === "update"）が発生したとき、クライアント側から送られてくるemailフィールドの値を検証せずにそのまま受理してしまう実装になっていた。結果として、攻撃者はsession.update({email: "[email protected]"})のようなリクエストを送るだけで、任意の被害者になりすますことができる。
update トリガーを発火"] --> B["session.update()に
被害者のemailを指定"] B --> C["JWTコールバックが
クライアント制御のemailを未検証で受理"] C --> D["JWTのemailクレームが
被害者のものに書き換わる"] D --> E["攻撃者のセッションが
被害者になりすます"]
この脆弱性が厄介なのは、攻撃に必要な権限が「自分自身の有効なセッション」だけという点だ。特別な権限昇格や事前の情報収集を必要とせず、ログイン済みユーザーであれば誰でも他人になりすませてしまう構造になっている。NextAuth自体の実装ではなく、cal.diyがNextAuthを組み込む際のカスタムJWTコールバック実装に問題があった点も特徴で、next-auth 脆弱性｜認可チェックがfail-openするGHSA2件、v5ベータが対象で扱った「NextAuth本体側」のfail-open脆弱性とは根本原因が異なる。フレームワーク自体の欠陥と、フレームワークを使うアプリ側の実装ミスは切り分けて理解する必要がある。
3件のCVEを一覧にすると次のようになる。
| CVE / GHSA | CVSS | 概要 | 影響バージョン | 修正バージョン | 公開日 |
|---|---|---|---|---|---|
| CVE-2025-66489 / GHSA-9r3w-4j8q-pw98 | 9.9 (Critical) | authorize()のロジック不備。TOTPコードのみで認証バイパス |
≤5.9.7 | 5.9.8 | 2025-12-03 |
| CVE-2025-71389 / GHSA-qjx2-5xqp-cpf4 | 10.0 (Critical) | 同梱Next.jsのRSC処理が入力をデシリアライズ。未認証RCE | <5.9.9 | 5.9.9 | 2025-12-07 |
| CVE-2026-23478 / GHSA-7hg4-x4pr-3hrg | 10.0 (Critical, CVSS4.0) | JWTコールバックがクライアント制御のemailを未検証で受理。なりすまし | ≥3.1.6 <6.0.7 | 6.0.7 | 2026-01-13 |
CVSSスコアの数値だけを横並びで比べると3件ともほぼ満点に近いが、CVE-2026-23478はCVSS4.0でのスコアリングと明記されている一方、他の2件がCVSS3.x系かどうかはGHSA上の表記からは断定できない。スコアリングのバージョンが揃っていない可能性がある以上、数値の微差にこだわるより「未認証で到達できるか」「特別な権限が要らないか」という条件面で優先度を判断するほうが実務的だ。
自分の環境がCal.com 脆弱性に該当するか——確認コマンドと対策
3件のCVEはそれぞれ修正バージョンが異なる（5.9.8／5.9.9／6.0.7）ため、「最近アップデートした」というだけでは古い脆弱性を見落とす可能性がある。基準にすべきは6.0.7以上かどうかの一点だ。
# ① self-hosted cal.diy/cal.com のバージョン確認（package.jsonから）
cat package.json | grep '"version"'
# ② Docker運用の場合はイメージタグを確認
docker inspect <container> --format ''
# ③ 3件のCVEすべてを回避できているか = 6.0.7以上であることを確認
# 5.9.8だけではCVE-2025-71389・CVE-2026-23478が未修正のまま残る
# 5.9.9だけではCVE-2026-23478が未修正のまま残る
バージョン確認の結果を、影響範囲マトリクスと照合すると次のようになる。
| 自己ホストのバージョン | 該当するCVE | 対応の緊急度 |
|---|---|---|
| 5.9.7以下 | CVE-2025-66489・CVE-2025-71389・CVE-2026-23478の3件すべて | 最優先で6.0.7以上へ |
| 5.9.8（5.9.9未満） | CVE-2025-71389・CVE-2026-23478の2件 | 未認証RCEを含むため優先度高 |
| 5.9.9以上6.0.7未満 | CVE-2026-23478のみ | JWTなりすましリスクが残存 |
| 6.0.7以上 | 該当なし（3件とも修正済み） | 通常運用 |
対策は基本的にバージョンアップが中心になるが、旧バージョンを使い続けている環境ではライセンス面の確認も合わせて必要になる。
・5.9.7以下を使っている場合：3件すべてが未修正のため、6.0.7以上への更新を最優先で行う
・5.9.8〜5.9.9系を使っている場合：CVE-2025-71389（未認証RCE）を含むため、外部公開しているインスタンスは特に優先度を上げる
・6.0.7未満を使っている場合：CVE-2026-23478（JWTなりすまし）は特別な権限を要さず成立するため、ログイン機能を提供している以上は影響範囲になる
・旧AGPL-3.0版（calcom/cal.com時代）からフォークして自己ホストしている場合：cal.diy（MIT）へ更新するとライセンス条件も変わる。AGPL-3.0はネットワーク経由でのサービス提供時にもソース公開義務（コピーレフト）が及ぶが、MITにはその義務がない。更新自体は脆弱性対策として必要だが、自社で加えた改変コードの扱いは社内で別途確認する
・calcom/cal.comのURLをブックマークしている場合：301リダイレクトでcalcom/cal.diyへ転送されるため404にはならない。監視ツールやドキュメントのリンク先をcalcom/cal.diyに更新しておく
認証OSSの比較——next-auth・better-authとの位置づけ
Cal.comの3件目（CVE-2026-23478）はNextAuthのJWTコールバックが起点になっており、認証まわりのOSSで同時期に見つかった他の脆弱性と比較すると、原因のレイヤーの違いが見えてくる。
| 項目 | Cal.com/cal.diy（CVE-2026-23478） | next-auth本体（GHSA-8fpg-xm3f-6cx3） | better-auth（SCIM/OAuth系4件） |
|---|---|---|---|
| 原因のレイヤー | cal.diyのカスタムJWTコールバック実装 | next-auth（Auth.js）本体の認可チェック構造 | SCIMプロビジョニング／OAuth自動リンクの所有権検証漏れ |
| 発火条件 | 有効なセッションを持つ任意ユーザー | 認可設定にエラーが起きたとき | SCIM/OAuth機能を有効化している場合 |
| CVSS | 10.0（CVSS4.0表記） | 数値スコア未算出（severity: critical表記） | 最大9.9 |
Cal.comのケースは「NextAuthというフレームワーク自体」の欠陥ではなく、「NextAuthを組み込んだアプリ側」のJWTコールバック実装ミスという点が、next-auth 脆弱性｜認可チェックがfail-openするGHSA2件、v5ベータが対象で扱った本体側のfail-open構造と対照的だ。同じ認証まわりの重大脆弱性でも、フレームワーク自体の設計ミスなのか、それを使う側の実装ミスなのかで、対応すべき箇所（本体をアップデートするのか、自社のカスタム実装を見直すのか）が変わってくる。better-auth 脆弱性｜SCIM/OAuthでアカウント乗っ取り、CVSS9.9のGHSA4件も含め、2026年に入って「エラー処理」や「クライアント入力の検証漏れ」を起点にした認証系の重大脆弱性が複数のOSSで連続している点は、認証まわりを自前実装・カスタマイズする際に共通して注意すべき教訓といえる。
まとめ
Cal.com（現cal.diy）で2025年12月〜2026年1月の約40日間に、CVSS9.9〜10.0の重大脆弱性が3件連続で公開された。認証バイパス（CVE-2025-66489）、未認証RCE（CVE-2025-71389）、NextAuth JWTコールバックのなりすまし（CVE-2026-23478）はそれぞれ修正バージョンが異なるため、自己ホスト環境はpackage.jsonまたはDockerイメージタグを確認し、6.0.7以上であることを基準にする。この直後の2026年4月にCal.com, Inc.が「AI駆動の攻撃者対策」を理由にクローズドソース化を発表した時系列は、日本語ではまだ解説されていない。
Cal.com/cal.diyの重大CVEは3件。CVE-2025-66489（CVSS9.9・認証バイパス、修正5.9.8）、CVE-2025-71389（CVSS10.0・未認証RCE、修正5.9.9）、CVE-2026-23478（CVSS10.0・JWTなりすまし、修正6.0.7）が2025-12-03〜2026-01-13の約40日間に連続公開された。自己ホスト環境はpackage.jsonのversionまたはDockerイメージタグを確認し、3件すべての修正を含む6.0.7以上かを判定する。旧calcom/cal.comはリポジトリ改称によりcalcom/cal.diyへ301リダイレクトされ、ライセンスもAGPL-3.0からMITへ変更されている。
参照ソース
・calcom/cal.diy — Security Advisories — GHSA-9r3w-4j8q-pw98／GHSA-qjx2-5xqp-cpf4／GHSA-7hg4-x4pr-3hrgの一次情報
・GHSA-7hg4-x4pr-3hrg（CVE-2026-23478 認証バイパス詳細） — NextAuth JWTコールバックの脆弱な実装の技術詳細
・GHSA-9r3w-4j8q-pw98（CVE-2025-66489 TOTP+パスワード検証バイパス詳細） — authorize()関数のロジック不備の技術詳細
・Going Closed-Source: Technical Changes Behind Cal.diy（Cal.com公式ブログ） — クローズドソース化とcal.diy分離の公式説明・ライセンス変更（AGPL-3.0→MIT）の根拠
