はじめに：Budibaseの重大な脆弱性とは

フロントエンドエンジニアの皆さん、こんにちは。今回は、ローコード/ノーコードプラットフォームであるBudibaseにおいて発見された、極めて危険度の高い脆弱性「GHSA-8qv3-p479-cj62（CVE-2026-54350）」について解説します。この脆弱性は、認証されていない第三者が、公開されたアプリの背後にあるデータベースの全データを閲覧・改ざんできてしまうという、非常に深刻なものです。たとえBudibaseを直接使っていなくても、API連携を行うアプリケーション開発者として、同様の原理が他のAPI設計にも潜んでいる可能性があるため、ぜひご一読ください。

脆弱性の概要と「NoSQLオペレーターインジェクション」の仕組み

この脆弱性は「NoSQLオペレーターインジェクション」と分類され、深刻度はCriticalです。Budibaseのサーバーサイド処理において、ユーザーからの入力値が適切にエスケープされないまま、JSONボディの内部に直接埋め込まれてデータベースへのクエリが構築されることが原因で発生します。

具体的には、フロントエンドから送信されるデータ（例えばJSON形式）に含まれる、特定のフィールドの値に攻撃者が意図的にJSONの特殊文字（例: `"` や `\`）を含ませることで、本来のJSON構造やデータベースクエリのテンプレートを破壊し、独自のクエリオペレーターを挿入することが可能になります。これにより、サーバーがデータベースに対して意図しない操作を実行してしまうのです。

具体的な影響とフロントエンドから見た攻撃経路

この脆弱性の最も恐ろしい点は、「認証なし」で攻撃が実行され得るという点です。もしBudibaseアプリ開発者が、データソースへのクエリのロールを「PUBLIC」（一般公開）に設定していた場合、Budibaseのサーバーサイド認証ミドルウェアやCSRF保護が機能しません。

攻撃者は、公開されているBudibaseアプリのURLからアプリIDを取得するだけで、特別な認証情報なしに、単一のHTTPリクエストで脆弱性を悪用できます。例えば、本来は特定の条件でフィルタリングされたデータを取得するはずの`find`クエリに対して、攻撃者がインジェクションを実行することで、データベース内の**全てのドキュメントを読み出す**ことが可能になります。これにはパスワードハッシュ、APIトークン、秘密鍵といった機密情報も含まれ、情報漏洩に直結します。

さらに、もし「PUBLIC」ロールでデータ更新（例: `updateMany`）が許可されている場合、攻撃者はコレクション内の**全ドキュメントを一括で更新・削除**するといった、データ破壊行為まで実行できてしまいます。フロントエンドから見ると、単なるAPIリクエストに見えても、その背後でデータベースが丸裸にされる可能性があるわけです。

影響を受けるシステムと条件

この脆弱性の影響を受けるのは、`Budibase/budibase`サーバー、または`@budibase/server`パッケージのバージョン`3.39.0`以前のシステムです。

特に重要なのは、Budibaseのワークスペースビルダーで、以下の条件をすべて満たすデプロイメントが対象となります。

<ul><li>データソースとして、MongoDB、CouchDB、Elasticsearch、DynamoDB-PartiQL、またはJSONボディを使用するRESTなど、**非SQLデータソース**を利用している。</li><li>その非SQLデータソースに対するクエリのロールが**「PUBLIC」（公開）**に設定されている。</li><li>そのアプリが**公開されている**。</li></ul>

補足として、PostgresやMySQLなどのSQLデータソースは、パラメータの処理方法が異なるため、この脆弱性の影響は受けません。しかし、NoSQLデータベースを利用している場合は最大限の注意が必要です。

フロントエンドエンジニアが取るべき対策と注意点

フロントエンドエンジニアとして、直接Budibaseのバックエンドを管理していなくても、この脆弱性から学べる教訓や、間接的な対応策があります。

<strong>1. Budibase利用者の場合：直ちにアップデート</strong><br>もし自社やプロジェクトでBudibaseサーバーを利用している場合は、**直ちにバージョン`3.39.0`よりも新しいバージョンへのアップデート**を強く推奨します。これが最も確実で迅速な対策です。

<strong>2. 緊急対策としてのロールの見直し</strong><br>即座のアップデートが難しい場合、公開されているBudibaseアプリ内で「PUBLIC」ロールを持つ非SQLデータソースに対するクエリがないか確認してください。もし存在する場合は、一時的にロールを「AUTHENTICATED」（認証済みユーザーのみ）に制限するか、アプリの公開を停止するなどの緊急対策を検討してください。

<strong>3. 一般的なAPI設計における教訓</strong><br>Budibaseを直接使っていなくても、この脆弱性からは多くの教訓が得られます。特に、フロントエンドからバックエンドへ送信するデータについては、以下の点を常に意識することが重要です。

<ul><li>**入力値の検証とサニタイズ:** サーバーサイドで、ユーザーからの入力値を厳格に検証し、データベースクエリやAPI呼び出しに渡す前に不審な文字や構造をサニタイズ（無害化）することが必須です。JSONの特殊文字だけでなく、SQLインジェクション対策と同様に、あらゆるデータソースに対して適切なエスケープ処理を行うべきです。</li><li>**認証・認可の徹底:** ユーザーが実行できる操作は、そのユーザーが持つ権限に基づいて厳密に制限されるべきです。「PUBLIC」のような匿名アクセスを許可する場合でも、実行可能な操作は極めて限定的であるべきです。</li><li>**最小権限の原則:** データベースアクセスやAPIの権限設定においては、必要最小限の権限のみを付与する「最小権限の原則」を徹底してください。</li></ul>

まとめ

今回解説したBudibaseの脆弱性は、フロントエンドからバックエンドへのデータ連携におけるセキュリティの重要性を改めて浮き彫りにします。認証なしでデータベースの全データが危険に晒されるという、極めて重大なリスクが存在するため、関係者の皆様は速やかに対応を進めてください。そして、この事例を教訓として、日々の開発においてセキュリティを最優先事項として捉え、安全なシステム設計と実装を心がけましょう。