NocoDBの脆弱性2件、修正版2026.08.0が公開
NocoDBの2026.08.0より前の版に、セッションを乗っ取られかねない脆弱性が2件あります。自社で運用している場合は2026.08.0へ更新し、Creatorロールを持つ利用者も確認してください。
同じ発表の脆弱性 2 件
この記事でまとめた分です。発表元の告知には、ほかの脆弱性も載っていることがあります。
- CVE-2026-126274 高 9.3
- CVE-2026-126280 高 9.1
急ぎ度: 早めに
CVSS v4は2件とも9点台（9.3と9.1）、v3は8.7と7.4で、修正版2026.08.0が公開済みのため、早めに更新する段階です。
関係があるか
NocoDBを自社のサーバーなどで運用し、2026.08.0より前の版を使っている組織が対象です。外部のデータソースをつなぎ、複数の利用者にCreatorロールを渡している環境は、とくにXSSの影響を受けやすくなります。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| NocoDB（nocodb） | 2026.08.0より前のすべての版 | 2026.08.0 |
確かめ方
- 1NocoDBを自分たちで運用しているなら、稼働中の版が2026.08.0より前かどうかを確認します。
- 2Dockerで運用している場合は、イメージのタグを見ます。タグが版を示していないときは、ベンダーの案内にある版の確認方法を使います。
- 3外部のデータソースをつないでいるか、Creatorロール以上を持つ利用者が何人いるかも洗い出します。XSSの影響範囲を決める条件になるためです。
- 4NocoDBのクラウド版を使っている場合は、ベンダーの告知で対応状況を確認します。
何が起きたか
NocoDBの2026.08.0より前の版には、ログイン中のセッションを第三者に使われかねない脆弱性が2件あります。1件は画面のテーブル削除確認ダイアログ、もう1件はリフレッシュトークンの更新処理にあり、どちらも2026.08.0で修正されました。
- CVE-2026-126274: 列名やテーブル名に埋め込まれたマークアップが、削除確認ダイアログでスクリプトとして実行され、ブラウザーに保存されたセッショントークンを読まれる（CVSS v3は8.7、v4は9.3、CWE-79）
- CVE-2026-126280: リフレッシュトークンの更新で、更新された行数を確認していない。捕捉されたトークンを正規ユーザーと同時に使われると有効なセッションを得られ、再利用の記録も残らない（CVSS v3は7.4、v4は9.1、CWE-362）
XSSの原因は、削除確認の文面を組み立てるDelete.vueが、タイトルをエスケープせずにinnerHTMLの仕組みで描画していることです。旧来の削除確認の流れ（useTableNew.ts）も同じ文面を作っていました。サーバー側でも、列タイトルは前後の空白を除くだけで、テーブルの表示タイトルはサニタイズされていませんでした。
リフレッシュトークンの件は、UserRefreshToken.tsが更新の成否を確かめないことが原因です。GitHubのアドバイザリは2026年10月27日付で、CVEは2026年11月13日に公表されました。
攻撃の流れ
-
1
タイトルに細工
Creatorロールを持つ利用者が、列名やテーブル名にマークアップを保存します。
-
2
管理者が削除を確認
外部データソース上のテーブルの削除を確認すると、確認画面でスクリプトが実行されます。
-
3
トークンを読まれる
ブラウザーに保存されたセッショントークンが読み取られます。
-
4
被害者として操作
認証済みのAPIを通じて、被害者が見られるデータを持ち出されます。
-
5
別経路のトークン再利用
捕捉済みのリフレッシュトークンが同時に提示されると、攻撃者も有効なセッションを得ます。
どう悪用されるか
CVE-2026-126274は、ネットワーク経由で悪用されます。細工したタイトルを保存するには、列を作成できる権限、つまりbaseのCreatorロールが必要です。スクリプトが動くのは、被害者が外部データソース上のテーブルの削除を確認したときです。対象は、リンク列から参照されているテーブルです。この削除にはCreatorロール以上が求められるため、被害者になるのは通常、baseのオーナーや管理者です。利用者の操作が必要なので、権限の低い人が仕込み、権限の高い人のブラウザーで動く形になります。
成功すると、NocoDBのオリジンでスクリプトが動き、ブラウザーのlocalStorageに保存されたセッショントークンを読まれます。攻撃者はそのトークンで被害者になりすまし、APIを通じて被害者が到達できるデータを持ち出せます。
CVE-2026-126280は前提が違います。攻撃者がリフレッシュトークンをすでに捕捉していて、正規ユーザーと同時に提示することが条件です。成功すると有効な認証済みセッションを得られます。再利用の記録が残らないため、ログから気づくのは難しくなります。
今すぐやること
-
1
稼働中の版を確認する
更新の前に、自社のNocoDBが2026.08.0より前かどうかを確かめます。Dockerで運用しているなら、イメージのタグを見ます。
docker image ls nocodb/nocodb -
2
2026.08.0以降に更新する
2件とも同じ版で修正されるため、更新は1回で済みます。クラウド版を使っている場合は、ベンダーの告知で対応状況を確認します。
-
3
Creatorロール以上の利用者を点検する
必要のない人の権限を下げます。外部データソースのテーブルや列のタイトルに、山かっこなどマークアップらしき文字列が入っていないかも見ておくと、更新前に仕込まれた形跡に気づけます。
-
4
更新前のアクセスを振り返る
身に覚えのない時間帯や接続元からのAPI操作がないかを、アクセスログで確認します。リフレッシュトークンの再利用は記録に残らないため、不審な操作があればトークン漏えいを疑い、該当の利用者に再ログインとパスワード変更を案内します。
すぐ更新できないとき
更新できるまでの間は、外部データソース上のテーブルの削除を、Creatorロール以上の利用者に控えてもらいます。Creatorロールを持つ人を信頼できる少人数に絞ることも、XSSの仕込みを減らす助けになります。リフレッシュトークンの件は、ベンダーの告知で回避策の有無を確認し、なければ更新を優先します。
背景
NocoDBは、既存のデータベースにつないで、表計算ソフトのような画面で業務データを閲覧・編集できるオープンソースのツールです。部門で使う表や台帳をまとめて預かることが多く、1つのセッションが読める範囲は広くなりがちです。今回のXSSでは、テーブル名や列名のような、ただの名前と見られがちな項目が入口になりました。削除を確認する管理者のブラウザーで動くため、権限の低い人が仕込んだものが、権限の高い人の持つトークンに届くことになります。
リフレッシュトークンは、短命のアクセストークンを更新するための長命の鍵です。使うたびに新しいものへ入れ替え、古いものは使えなくするのが一般的な設計で、盗まれた鍵が使い回されたことに気づく手がかりにもなります。今回の件では、更新の成否を確認していないため、同時に届いた2つの要求がどちらも通りえます。入れ替えの仕組みがあっても、盗用を検知する役目が果たせなくなります。
よくある質問
Q.GitHubのアドバイザリにCVE番号が出ていませんが、同じ脆弱性ですか。
Q.Creatorロールを信頼できる少人数にしか渡していなければ、影響は小さいですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| nocodbnocodb |
2026.08.0 未満→ 2026.08.0 |
2026.08.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
NocoDB before 2026.08.0 contains a stored cross-site scripting vulnerability that allows authenticated Creator users to inject script by embedding markup in column or table titles. The Delete.vue confirmation dialog renders these titles through an unescaped innerHTML binding, executing script when a victim deletes an external-source table to steal session tokens from localStorage.
出典: CVE.org (CVE Program・cvelistV5) NVD