Better Authなど11件にCVE番号、修正は昨年から公開済み CVE-2025-71399

2026年8月2日の夜、5つのソフトに合計11個のCVE番号（脆弱性に付けられる世界共通の管理番号）が一斉に登録されました。対象は、ログイン機能を担うBetter Auth、自分のサーバーで動かすタスク管理Vikunja、データベースのArcadeDB、リモート操作の土台FreeRDP、そして家庭用ルーターで使われるOpenWrtの管理画面です。

ここで大事なのは、11件のどれも新たに見つかった穴ではないということです。開発元の警告はすべて公開済みで、修正版もすでに配布されています。最も古いものは2025年11月に、最も新しいものでも2026年7月中旬には直っていました。今回起きたのは「公開済みの警告に、あとから番号が付いた」ことだけです。

それでも取り上げる理由は2つあります。ひとつは、番号が付いた瞬間に検査ツールや通知が一斉に反応するため、「うちは大丈夫か」と調べる人が今日から増えるからです。もうひとつは、11件のうち1件だけ、まだ手を打っていない人が多いと考えられるものが混ざっているからです。

同じ日に登録された11件、その中身

11件すべてに番号を発行したのは、米国の脆弱性情報企業VulnCheckです。CVE番号は誰でも勝手に発行できるものではなく、権限を持った組織（CNAと呼ばれます）だけが割り当てられます。VulnCheckはその一社で、主に「開発元が警告は出したが番号は取らなかった」案件を拾って番号を付ける役割を担っています。

今回の11件を、警告が出た日と修正版が出た日で並べ直すと、実態がはっきりします。

つまり11件中10件は、最新版を使っていれば何もする必要がありません。残る1件がFreeRDPです。こちらは7月14日に出た3.29.0では直りきっておらず、2日後の3.30.0まで上げる必要があります。7月の更新を「3.29.0で済ませた」人は、まだ穴が残っています。詳しくはFreeRDPの脆弱性をまとめた記事に整理しました。

番号が付いた日は、危なくなった日ではない

今回の11件は、どれも開発元がGitHubの警告ページで公開済みでした。そして公開時点ではどれも「CVE番号なし」と表示されていました。実際、Better Authの3件の警告ページには、8か月にわたって番号欄が空のまま置かれていたことになります。

これは珍しいことではありません。オープンソースの開発チームの多くは、番号を取得する手続きを踏まずに、修正版を出して警告ページを公開するだけで済ませます。作業としてはそれで十分だからです。しかし世の中の検査ツール・脆弱性データベース・社内の資産管理台帳の多くは、CVE番号を鍵にして情報を突き合わせています。番号がなければ、それらの目には映りません。

この構造から、2つの実務的な結論が出ます。

ひとつ目。今日の通知に驚く必要はほとんどありません。番号は今日付きましたが、危険は昨年11月や今年7月から存在していて、修正版もその時点で出ていました。手元のバージョンが最新なら、すでに終わった話です。「新しい脆弱性が出た」と受け取って緊急対応を始めるのは、労力の使いどころを間違えています。

ふたつ目は、こちらのほうが重要です。番号が付いていない警告は、いつまでも通知に乗ってきません。今回、FreeRDPは番号が付いた2件よりも、番号が付いていない2件のほうが深刻でした。7月26日に公開された警告のうち1件は、FreeRDPを遠隔操作の受け側として動かしている場合にパスワードなしで認証を通過されてしまうという内容です。これには8月2日時点でもCVE番号がありません。番号を待って動く運用をしていると、こうした案件は永久に検知されません。

部品として組み込んだソフトの脆弱性が、番号の有無にかかわらず下流へ連鎖していく問題については、オープンソース部品の連鎖リスクをまとめた記事でも扱っています。

誰が狙い、何をされるのか

今回の11件のうち9件までが、外部から誰でも攻撃できるものではありません。危ういのはそのサービスにすでに登録している一般利用者や、共有リンクを渡された取引先など、「一応は中に入れる人」です。無料登録できるサービスなら、攻撃者は自分でアカウントを作るだけでこの立場になれます。

その人たちが今回の穴で何をするかというと、本来は自分に許されていない範囲へ、身分を偽らずに手を伸ばすことです。ログイン自体は正規に済ませたうえで、その先の「あなたはここまで」という線引きが機能していない場所を突きます。他人のアクセス用の鍵を勝手に発行する、他人の予定表を覗く、自分を管理者に昇格させる、といった動きになります。侵入の痕跡が「正規のログイン記録」として残るため、後から気づきにくいのが厄介です。

被害を受けるのは、まずそのサービスを使っている人です。非公開のはずのタスクや顧客情報が第三者に渡り、身に覚えのないアクセス用の鍵が自分の名前で発行されます。運営する側にとっては、社外の協力者に渡した共有リンク1本が社内データ全体への入口になり得るという話で、アクセス権の設計そのものを見直す必要が出てきます。以下、製品ごとに何が起きるのかを見ていきます。

ログイン機能を任せる部品「Better Auth」に3件

Better Authは、Webサービスにログイン機能を組み込むための部品です。メールとパスワードでの認証、Googleなどとの連携、パスキー、二要素認証といった機能を、開発者が一から作らずに済ませられます。配布サイトの実測値では週に約659万回ダウンロードされており、GitHubのスターは2万9千を超えます。これを利用しているとGitHubが把握しているソフトだけで1万5千件以上あります。

この1年で立て続けに2つの大きな出来事がありました。2025年9月、Next.js界隈で長く定番だった認証部品Auth.js（旧NextAuth.js）がBetter Authに合流し、Auth.js側の公式サイトが「Better Authの利用を強く推奨する」と表明しました。そして2026年7月7日、VercelがBetter Authを買収しています。つまり今回の3件は、いま最も勢いのある認証部品に付いた番号です。

CVE-2025-71399：スラッシュを1本足すだけで回数制限が外れる

3件の中で最も重いCVE-2025-71399（10点満点で8.6）は、URLの書き方ひとつで防御が無効になるというものです。

Webサービスは通常、ログイン画面への連続入力に回数制限をかけます。Better Authも初期設定で、ログイン用のアドレス /sign-in/email に「10秒間に3回まで」という厳しい制限を用意しています。ところが同じ場所を //sign-in/email と、スラッシュを1本増やして呼ぶと話が変わります。

Better Authが厳しい制限をかける相手を選ぶとき、住所が「/sign-in」で始まるかどうかを文字として見比べています。スラッシュが1本増えた住所はこの条件に当てはまらないため、厳しい制限をすり抜けて、全体の初期値である「60秒間に100回まで」に緩みます。さらに回数を数えるときの覚え書きも住所ごとに分かれているため、数え直しが起きます。ところが実際にどの処理へつなぐかを決める部品は、スラッシュの重なりを無視して同じログイン処理へ案内してしまいます。入口の警備員は別人だと判断し、案内係は同じ人だと判断する。この食い違いが穴の正体です。

同じ理屈で、開発者が「この機能は使わせない」と閉じた入口（disabledPathsという設定です）も回避できます。開発元の警告は影響を「閉じたはずの入口の迂回」と「回数制限の迂回」の2点としており、パスワードの総当たりに関する具体的な被害報告までは触れていません。なお、VercelにNext.jsで載せている場合や、Cloudflareで住所の正規化を有効にしている場合は、手前でスラッシュが整理されるため影響を受けないと明記されています。

半年前に直っていた修正が、届かなかった理由

この件で興味深いのは、原因が Better Auth 自身のコードではなく、その内側で使われている rou3 という小さな部品にあったことです。rou3は住所を「/」で区切って分解する際、空になった区切りをすべて捨てていました。//sign-in/email を分解すると空の区切りが混ざりますが、それを捨ててしまうと /sign-in/email と完全に同じ結果になります。

この挙動は2025年6月16日に、すでに修正されていました。修正の提案には「途中の空の区切りは残すべき」とだけ書かれており、提出から4分でそのまま取り込まれています。セキュリティ問題としては扱われず、ごく普通のバグ修正でした。

問題は届き方です。Better Authはbetter-callという中間の部品を経由してrou3を使っており、そのbetter-callがrou3のバージョン指定を「0.5系のうち最新」と書いていました。この書き方だと、修正が入った0.7系には自動では上がりません。結果として、6月に直っていたはずの修正が下流のBetter Authに届いたのは、半年後の2025年12月2日でした。その間、rou3は週に約2,900万回ダウンロードされ続けています。

部品の中の部品にバージョンの上限が書かれていると、上流で直っても下流には届きません。自分が直接使っているソフトを最新にしていても、その内側で古い部品が固定されている可能性がある、という話です。

CVE-2025-71400：他人のパスキーを消せる

CVE-2025-71400（7.1）は、パスワードを使わないログイン手段「パスキー」を扱う追加機能の話です。パスキーを削除する処理が、送られてきた削除対象の番号だけを見て、それが依頼者本人のものかを確かめていませんでした。ログイン済みでありさえすれば、他人のパスキーを番号指定で消せます。

設定によっては番号が1、2、3……と順番に振られるため、開発元の警告は「番号を順に指定してすべてのパスキーを消すことが容易になる」と書いています。データを盗まれるわけではありませんが、利用者が突然ログインできなくなります。修正は4行、「依頼者本人のものか」という条件を1行足しただけでした。

この件には注意点があります。パスキーの機能が独立した追加部品として切り出されたのはバージョン1.4からで、それ以前は本体に組み込まれていました。今回の警告が対象として挙げているのは切り出し後の追加部品だけです。本記事で1.3系の本体のコードを確認したところ、削除処理には同じく本人確認の条件がありませんでした。1.3系以前を使い続けている場合、公表されている対象範囲には自分が現れないことになります。

CVE-2025-71401：起動直後の最初の1回でサイトを止められる

CVE-2025-71401（5.9）は、サービスのアドレスを設定ファイルに書いていない場合に、サーバー起動後の一番最初のアクセスが、そのアドレスを決めてしまうというものです。攻撃者が最初の1回を取れると、以後すべてのログイン関連の入口が「見つかりません」を返し続け、誰もログインできなくなります。

発動条件は厳しく、アドレスを明示していること、あるいは一般的なホスティングサービスを使っていることで防げます。開発元自身もこの件の深刻度を「Low（低）」と評価しました。ところが今回付いたスコアは、後述するとおり評価方式によって大きく食い違っています。

結局どのバージョンにすればよいか

最新版は1.6.25です。ここまで上げていれば3件とも関係ありません。1.4系を使い続けている場合は、その系列の最新である1.4.22があります。

ひとつ訂正しておくべき点があります。CVE-2025-71399の修正版として登録されている「1.4.4」は、正しくは1.4.5です。開発元の警告ページは対象を「1.4.5未満」、修正版を「1.4.5」と明記しています。実際に依存関係をたどると、1.4.4が使っているのは修正前のrou3で、修正後のrou3に切り替わるのは1.4.5からでした。CVE側の記録は、見出しでは1.4.4と書きながら本文では1.4.5と書いており、記述が食い違っています。1.4.4で止めると直りません。

むしろ1.4系に留まっている場合に気にすべきなのは、今回の3件ではありません。8月1日に登録されたCVE-2026-67336（8.7）は、外部サービスとの認証連携で「署名なしのトークンを受け入れる」設定が初期値になっていたというもので、修正は1.6.11です。1.4系はこの対象に入ります。番号が古い順に片づけるのではなく、いま使っているバージョンに残っている穴を見るべきです。

なお、Better Authは日本語での実装解説が豊富で、Zennの関連タグだけで69本の記事があります。一方で、今回の3件を扱った日本語の記事・注意喚起は、JVN iPedia・JPCERT/CC・国内メディアを含めて確認できませんでした。作り方の情報は日本語で手に入るのに、危険の情報は英語でしか流れてこない、という状態になっています。ログイン基盤の脆弱性という点では、authentikの事例やCasdoorの事例も併せて参考にしてください。

自分で立てるタスク管理「Vikunja」に2件

Vikunjaは、TodoistやAsanaのようなタスク管理を自分のサーバーで動かせるようにしたソフトです。「自分で所有するタスク管理」を掲げており、利用者数やプロジェクト数の制限なく無料で使えます。配布用イメージのダウンロード数は約925万回、GitHubのスターは約5千です。自分でサーバーを立てる層にはよく知られた選択肢です。

CVE-2026-68581：共有リンクを4回作るだけで、他人になりすます

CVE-2026-68581（8.1）は、今回の11件で最も筋の悪い部類です。

Vikunjaには「共有リンク」という機能があります。プロジェクトのURLを発行して、Vikunjaのアカウントを持たない人にも中身を見せられる仕組みで、初期設定で有効です。問題は、この共有リンクにも、利用者アカウントにも、それぞれ1番、2番、3番と別々に通し番号が振られていることでした。

アクセス用の鍵（APIトークン）を管理する処理は、「操作しているのは誰か」を認証情報から取り出すとき、種別を確かめずに番号だけを取り出していました。共有リンクの7番でアクセスすると、システムはそれを「利用者の7番」だと受け取ります。2本の別々の通し番号を、同じ番号として扱ってしまったわけです。

攻撃の手順は驚くほど単純です。まず狙う相手の番号を調べ、次に自分のプロジェクトで共有リンクを作ります。発行された番号が相手より小さければ、また作ります。番号は作るたびに1つずつ増えるので、いずれ相手の番号にぴったり重なります。開発元の検証では4回作っただけで目的の番号に到達しています。使うのは細工した通信ではなく、サーバーが正規に発行した本物の共有リンクです。

重なった時点で、相手のアクセス用の鍵を一覧表示し、攻撃者が選んだ権限で新しい鍵を発行し、既存の鍵を削除できます。発行された鍵は相手の権限で動くため、そのまま非公開プロジェクトの中身に手が届きます。修正では、番号を取り出す前に「そもそも相手は本物の利用者アカウントか」を確かめる処理に置き換えられました。

CVE-2026-68582：共有リンクから他人のボードが見える

CVE-2026-68582（6.5）は、タスク一覧を取得する処理で権限の確認が抜けており、共有リンクを持っている人が、本来関係のない他の利用者のカンバンボードの構造や利用者情報まで読めてしまうというものです。対象は0.24.0以降で、こちらも2.4.0で修正されています。

押さえておきたいのは、2.4.0が10件のセキュリティ修正をまとめたリリースだという点です。今回番号が付いた2件はその一部にすぎません。同じリリースには、他人のタスクを勝手に完了させられる件、他人のプロジェクトを別の場所へ移動できる件、外部ログイン連携のメールアドレスを介したアカウント乗っ取り、パスワード再設定リンクが平文で保存されていた件などが含まれます。開発元自身が「カンバンボードとプロジェクト階層まわりの権限確認が、他の部分ほど厳密でなかった」と説明しています。2.4.0未満を使っているなら、CVE番号の有無に関係なく更新すべきです。

AIにデータベースを触らせる窓口が、権限を素通りさせていた

ArcadeDBは、表形式・グラフ・文書といった複数の形式を1つで扱えるデータベースです。OrientDBというデータベースの創業者が、その後継として立ち上げたものにあたります。GitHubのスターは約1,058、配布用イメージのダウンロードは約24.6万回で、前の2つに比べると規模の小さいプロジェクトです。ただし今回の3件のうち2件は、製品を問わず起きうる問題を示しています。

CVE-2026-68578：認証はしたが、その結果を誰にも渡していなかった

ArcadeDBは2026年3月4日公開の26.3.1で、MCPという仕組みに対応しました。MCPは、AIアシスタントに外部のソフトを操作させるための共通の接続規格です。この対応によって、AIから直接データベースに問い合わせたり、データを書き換えたりできるようになりました。

CVE-2026-68578（7.5）は、その窓口の欠陥です。誤解されやすいのですが、認証そのものは行われていました。トークンによる本人確認は機能していたのです。抜けていたのはその次で、開発元の説明によれば、確認できた利用者の情報をデータベース本体の処理へ引き渡していませんでした。

ArcadeDBの権限確認は、「利用者が設定されていないときは何もしない」という作りになっています。設計上そうなっているのですが、今回は利用者が設定されないまま処理が進むため、すべての権限確認が素通りしました。受付で身分証を確認したのに、その情報を館内の各部屋の警備員に一切伝えず、警備員は「誰も来ていない」と判断して素通りさせる、という状態です。結果として、MCP経由で入ってきた権限の低い利用者が、書き込み・設計変更・権限設定の変更を自由に行える状態になっていました。条件が揃えばデータベースの内部で任意のプログラムも動かせます。

この窓口は初期設定では無効で、管理者が明示的に有効化する必要があります。それでも押さえておくべきなのは、AI連携の窓口を新設したときに、既存の権限確認との接続が抜け落ちるという失敗が、繰り返し起きていることです。当サイトでもこれまで、Terraformの連携ツール、監視ツールGrafanaの連携ツール、mcp-pinotと、同種の事例を扱ってきました。背景には、MCPの仕様書自身が「認可の実装は任意」と定めているという事情もあります。

CVE-2026-67356：設計変更の権限だけで、管理者アカウントを作れる

3件で最も点数が高いCVE-2026-67356（8.8）は、データベースの動作に合わせて自動実行される小さなプログラム（トリガー）に関するものです。このトリガーの中から、データベース本体の操作用オブジェクトへ制限なく手が届く状態になっていました。

その結果、「表の設計を変更してよい」という権限しか持たない担当者が、トリガーを1つ作るだけで、サーバー全体の管理者アカウントを新規に作成できます。データの整理を任せた担当者が、いつの間にか鍵束ごと持っていける状態だったということです。修正では、プログラムを書くタイプのトリガーを作るには、権限設定を変更できる権限が別途必要になりました。

CVE-2026-67357：伏せ字の判定が「password」という文字だけだった

CVE-2026-67357（7.5）は、設定内容を表示する機能で、伏せ字にすべき項目の判定が甘かったというものです。判定は「項目名にpasswordという文字が含まれているか」だけで行われていました。そのためサーバー間の連携に使う合言葉が、名前にpasswordを含まないという理由で、そのまま表示されていました。

この合言葉は、特定の指定を添えると最上位の管理者として振る舞えてしまう性質のものです。読み取り権限しかない利用者がこれを入手すれば、サーバーを完全に掌握できます。ただし、管理者がこの合言葉を実際に設定していなければ、空の値が見えるだけで実害はありません。3件とも修正版は26.7.3です。

残る3件はリモート操作ソフトと家庭用ルーター

FreeRDPの2件、CVE-2026-68579（9.6）とCVE-2026-68580（7.5）は、今回の11件で点数が最も高く、かつ唯一「まだ対応が終わっていない人が多い」と考えられる案件です。7月の更新を3.29.0で済ませた場合、前者が未修正のまま残ります。9.6のほうは接続先のファイルを手元に貼り付けたときに、7.5のほうはマイク転送を有効にしているときに問題になります。対処の詳細と、番号が付いていないより深刻な2件については、FreeRDPのまとめ記事に整理しました。

11件目のCVE-2026-68583（5.4）は、家庭用ルーターで使われるOpenWrtの管理画面に、あとから追加する広告ブロック機能に関するものです。ブロック対象一覧の名前欄に細工したプログラムを書き込んでおくと、管理者がその状態表示ページを開いた瞬間に、管理者の画面上でそれが動きます。権限の低い利用者から管理者を狙う手口で、修正版は1.2.4-4です。ルーター本体の話ではなく、追加機能を導入していて、かつ管理画面に複数の利用者を作っている場合に限られます。

同じ穴に2つの点数が付く。どちらを見るべきか

脆弱性の深刻さは、CVSSという方式で10点満点の数値に換算されます。現在は古いバージョン3.1と新しいバージョン4.0が並行して使われており、今回の11件にはその両方が付いています。そして一部で、両者が大きく食い違っています。

上の2件は、開発元が「低」と評価した、あるいは情報が見えるだけの問題に対して、新方式では9.3という緊急扱いの数字が付いています。しかも2件の内訳を見ると、まったく異なる2つの穴に対して一字一句同じ評価内容が入力されています。その内容は「権限不要で、機密性・完全性・可用性のすべてに重大な影響」というものですが、CVE-2025-71401は説明文でも旧方式の評価でも「サービスが止まるだけ」とされており、情報が漏れるとも書き換えられるとも書かれていません。CVE-2026-68582も同様に、旧方式では「権限が必要・情報が見えるだけ」です。

8月2日22時時点で取得した内容では、11件すべてが米国立標準技術研究所のデータベース上で「受領済み・未解析」の状態にあります。今回のスコアはすべてVulnCheck自身が付けたもので、第三者による検証はまだ行われていません。この先の解析で数値が変わる可能性は十分にあります。

実務的な結論は単純です。点数だけを見て優先順位を決めないことです。今回でいえば、9.3という数字が付いた2件よりも、6.5のVikunjaや7.5のArcadeDBのほうが、条件を読む限り実際の危険は大きくなります。見るべきは「攻撃に何が必要か」「その結果何ができるか」という条件のほうで、開発元の警告ページには必ずそれが書かれています。米政府CISAが公開する実際に攻撃されている脆弱性の一覧（最新版は7月29日版・1,656件）を確認しましたが、今回の11件はいずれも掲載されておらず、悪用の報告も確認できていません。

まとめ

8月2日に登録された11件のCVE番号は、すべて公開済みの警告への後付けでした。修正版は2025年11月から2026年7月にかけて出揃っています。最新版を使っているなら、10件については何もする必要がありません。

やるべきことを整理すると、Better Authは1.6.11以上へ（今回の3件だけでなく、8月1日登録の別件も含めて）。Vikunjaは2.4.0へ。ArcadeDBは26.7.3へ。そしてFreeRDPは3.29.0では足りず、3.30.0まで上げてください。この最後の1つだけが、今回まだ手が打たれていない可能性の高い案件です。

今回いちばん覚えておく価値があるのは、CVE番号は危険の発生を知らせる合図ではないということです。番号は、危険が公表され修正されたずっと後から付くことがあります。逆に、番号が付かないまま放置される警告もあります。FreeRDPで最も深刻だった認証すり抜けの件は、いまだに番号がありません。番号を待つ運用は、早く動けないうえに、番号の付かない案件を丸ごと取りこぼします。使っているソフトの警告ページを直接見に行くほうが、確実で早いという話です。

参照元

• ▸ GHSA-x732-6j76-qmhm - Double-Slash Path Normalization in rou3 Can Bypass Better Auth disabledPaths config and Rate Limits（2025年12月16日）
• ▸ GHSA-4vcf-q4xf-f48m - Passkey deletion IDOR（2025年11月25日）
• ▸ GHSA-569q-mpph-wgww - External request basePath modification DoS（2025年11月27日）
• ▸ h3js/rou3 - fix: preserve empty segments（#160）（2025年6月16日）
• ▸ Vercel - Vercel acquires Better Auth（2026年7月7日）
• ▸ GHSA-vvcv-vpph-h844 - Link-share principal ID collision allows cross-account API token issuance and management（2026年7月19日）
• ▸ GHSA-rj9j-8772-4h6c - Broken object level authorization in the task-collection endpoint
• ▸ Vikunja - 2.4.0: Ten security fixes, Vikunja Pro, and a new v2 API（2026年7月19日）
• ▸ ArcadeDB - Release 26.7.3（2026年7月17日）
• ▸ GHSA-6x73-v3rc-f57c - MCP transport does not bind the authenticated principal（2026年7月17日）
• ▸ GHSA-38pf-6hp2-pxww - Privilege escalation via JavaScript trigger（2026年7月17日）
• ▸ GHSA-p9wc-4fhr-78wm - clusterToken disclosed in cleartext via get_server_settings（2026年7月17日）
• ▸ GHSA-q335-4c83-c88h - luci-app-adblock-fast stored XSS
• ▸ GHSA-m37j-jcr2-8gcc - Windows clipboard CliprdrStream_Read heap overflow（2026年7月20日）
• ▸ NVD - CVE-2025-71399
• ▸ NVD - CVE-2026-68581
• ▸ VulnCheck - Advisories