何が起きたか・対象

NocoDBのテーブル作成で、creator権限の利用者が送るtable_nameが、関連するトリガーの一覧を得る補助SQLへ直接埋め込まれていました。名前の引用符や式がSQL構文として解釈され、指定テーブル名を比較するだけのはずが、基盤DBの別の値も調べられる問題です。識別子はCVE-2023-43794です。

トリガーは、テーブルの更新などを契機にDBが実行する処理です。NocoDBはその一覧を調べるため、SQLiteの定義情報sqlite_masterを、対象テーブルを示すtbl_nameで検索します。正常な名前がnotesなら条件はtbl_name='notes'です。入力が引用符でこの文字列を閉じてORなどの式を続けると、名前の一部が比較条件を変えるSQLになります。

研究と開発元資料は、条件の真偽で応答を遅らせるブラインド型の取得を説明しています。攻撃者が「秘密の先頭文字がAなら遅くする」という条件を名前へ含められ、アプリがDB処理の終了を待って応答する構成なら、HTTPの到着時間を比べて文字を推定できます。文字列が直接API応答に入らなくても取得経路になります。 名前に入れた式が「条件が真のときだけ重い計算を行う」という分岐を含むと、DBがその条件を評価してから処理時間が変わります。これは説明用の仮定で、研究の再現は大きな乱数データの生成・変換による遅延です。

ログインとcreator権限、NocoDBのDB接続が使える照会と読み取り権限が条件です。確認範囲を未認証での自由なDB取得やOSコード実行まで広げず、実悪用の観測は未確認として残します。

報告・修正・公開の時系列

0.109.2で検証され、2023-06-30に報告、10-17に開発元アドバイザリ、10-25に研究資料が公開されました。開発元は0.111.0を修正版に指定しています。

正常ならどう動くはずだったか

テーブル作成APIは、利用者が指定した名前でテーブルを作るほか、関連するトリガーの情報もDBから取得します。この補助検索でも、table_nameはSQLへ連結せず、sqlite_masterのtbl_nameと比較する値として渡す必要があります。管理操作の名前も、利用者が内容を決められる入力です。 sqlite_masterはテーブルやトリガーの定義情報、tbl_nameはその定義が属するテーブル名です。利用者のtable_nameを、その列と比較する値として扱います。

技術的な原因

creator権限の利用者が作成APIへ送るtable_nameはtriggerListへ渡り、tbl_nameを比較するSQL文字列へ直接埋め込まれていました。名前に含まれる引用符などがSQL構文として読まれ、指定した名前に一致するトリガーを探すはずの問い合わせを、別の条件や照会へ変えられる状態でした。

攻撃が成立する条件と流れ

攻撃者はcreator権限でログインし、テーブル作成のHTTPリクエストにSQLの意味を変える名前を含めます。サーバーが補助クエリを実行すると、その入力がSQLとして解釈されます。開発元は、条件の真偽によって応答を遅らせ、その時間差を比較してDB内の値を調べるブラインド型の取得を説明しています。

確認された事実と、想定される影響

攻撃者は、HTTPレスポンスの到着時間を比べ、基盤DBにあるデータを推定できます。仕組みを説明する例では、DB内の値の先頭文字がAかBかで遅延が変わる条件を指定し、応答の速さからその文字を推定します。同じ照会を別の位置でも繰り返せれば、文字列の取得につながるおそれがあります。実際に取得できる情報は接続しているDBとその権限、使用可能な問い合わせに依存します。ログインとcreator権限が必要で、未認証利用者の自由なDB取得や、OSコード実行が確認された問題ではありません。実悪用の観測は未確認です。

実際の修正・対応方針

開発元は0.111.0を修正版としています。具体的な変更差分はここでは直接確認していません。一般的には、この補助クエリもバインドなどで構文と値を分けますが、実際の修正方式と断定はしません。 例えば条件をtbl_name = ?として固定し、名前notesを別の値としてDBドライバへ渡す方式です。受信名をSQLの文章へ連結しないため、名前の引用符でSQLの文字列を閉じる経路を防げます。

利用者・運用者が確認すること

修正済みのサポート版へ更新し、creator権限を誰へ与えているか、接続先DBがどの情報を扱えるか確認します。管理用の補助クエリにも入力検証・バインドの方針を適用します。

開発者への教訓（教材としての考察）

SQLインジェクションは、検索画面以外でも起こります。テーブル名のような管理操作の値が、メタデータ用の検索SQLへ再利用される経路も確認します。

出典・確認範囲

  1. [1] SQL injection in NocodbGitHub Security Lab / 確認日 2026-10-29
  2. [2] SQL Injection in nocodbNocoDB / 確認日 2026-10-29
未確認事項・限界

修正コミットの直接確認と実悪用の観測は未確認です。