はじめに：なぜフロントエンドエンジニアもバックエンドの脆弱性に関心を持つべきか

皆さん、こんにちは。日本のフロントエンドエンジニアの皆さんにとって、バックエンドのシステム脆弱性は一見遠い話題に思えるかもしれません。しかし、私たちが開発するWebアプリケーションは、バックエンドのAPIやサービスと密接に連携しており、その基盤となるシステムのセキュリティは、アプリケーション全体の信頼性やユーザーの安全に直結します。

特に、Budibaseのようなローコード/ノーコードプラットフォームを利用している場合、バックエンドの仕組みを直接コードで書かないからこそ、プラットフォーム自体のセキュリティには高い関心を持つ必要があります。今回は、そのBudibaseで発見された、極めて深刻な権限昇格の脆弱性について詳しく解説します。あなたの担当するプロジェクトや、将来利用する可能性のあるサービスにも関連する話かもしれませんので、ぜひ最後までご確認ください。

脆弱性の概要：Budibaseでのグローバル管理者権限の不正取得

今回報告された脆弱性 (GHSA-6xp4-cf37-ppjh / CVE-2026-48150) は、Budibaseというローコードプラットフォームにおける権限昇格に関するものです。具体的には、特定のアプリの管理者権限（「ワークスペーススコープのビルダー」）を持つユーザーが、システム全体の最高管理者権限（「グローバル管理者」）を不正に取得できてしまうという深刻な問題です。

この脆弱性は、Budibaseの`/api/public/v1/roles/assign`という、ユーザーにロール（権限）を割り当てるためのAPIエンドポイントに存在します。通常、このような重要なエンドポイントは厳格な権限チェックが行われるべきですが、ここではそのチェックが不十分でした。

詳細なメカニズムは以下の通りです：

1. **不十分なミドルウェアチェック:** `/api/public/v1/roles/assign`エンドポイントへのリクエストは、`builderOrAdmin`というミドルウェアで権限チェックされます。このミドルウェアは、リクエストの`x-budibase-app-id`ヘッダーで指定されたアプリの「ワークスペーススコープのビルダー」であれば通過させてしまいます。

2. **無条件なロール割り当て:** ミドルウェアを通過すると、コントローラはリクエストボディの内容をそのままSDKに渡します。SDKは、呼び出し元が指定した`userId`に対し、リクエストボディで指定されたロール（例: `global builder`や`global admin`）を無条件に付与してしまいます。この時点で、本来限定的な権限しか持たないはずの「ワークスペーススコープのビルダー」が、自身や他のユーザーを組織全体の最高管理者へと昇格させることが可能になります。

どのような環境で影響を受けるのか？

この脆弱性が影響するのは、以下の条件を満たすBudibase環境です。

1. **Enterpriseライセンスの利用:** BudibaseのEnterpriseライセンスを使用している環境です。

2. **`EXPANDED_PUBLIC_API`機能の有効化:** Enterpriseライセンス環境で、`EXPANDED_PUBLIC_API`機能が有効になっている場合です。

3. **「ワークスペーススコープのビルダー」の存在:** 当該テナント内に、特定のアプリの管理者権限（ワークスペーススコープのビルダー）を持つユーザーが存在する場合、そのユーザーが悪用する可能性があります。

フロントエンドエンジニアとして知っておくべきリスクと影響

この脆弱性が悪用された場合、もたらされる被害は極めて甚大です。フロントエンドエンジニアの視点からも、その影響は他人事ではありません。

### 1. 機密情報の漏洩とシステム改ざん

「グローバル管理者」は、テナント内の全アプリ、全ユーザー、データソース認証情報、オートメーション、SCIM/OIDC/監査ログ設定など、システム全体への無制限なアクセス権を持ちます。これにより、データベース接続情報やAPIキー、顧客データなどの機密情報が漏洩したり、システム設定が不正に改ざんされたりする可能性があります。

### 2. アプリケーションの機能停止や信頼性損失

悪意ある攻撃者は、管理権限を利用してアプリのデプロイを停止させたり、データの破壊、不正なコードの埋め込みなどを行う可能性があります。これにより、フロントエンドで提供しているサービスが利用不能になったり、ユーザーからの信頼を失ったりする事態に発展します。

### 3. 法的・経済的損害

データ漏洩やシステム侵害は、GDPRや日本の個人情報保護法などの規制に違反し、企業に多大な罰金や訴訟リスクをもたらします。また、サービス停止による機会損失や、復旧にかかるコストも莫大なものになります。

既存のグローバルビルダーをアプリスコープビルダーに降格させようとしても、この脆弱性により再度グローバル権限が付与されてしまう可能性があるため、修正が適用されるまでは非常に危険な状態が続きます。

推奨される対応策：今すぐ行うべきこと

この脆弱性への対応は、Budibaseのシステム側で修正パッチを適用することが最も重要です。以下のいずれか、または複数の対応が求められます。

ロール付与を行うSDKの関数内で、呼び出し元が実際にそのグローバルな権限（例: グローバルビルダーやグローバル管理者）を付与できるだけの権限を持っているかを確認するチェックを追加します。これは、権限付与のコアロジックにおける根本的な修正です。

`builderOrAdmin`ミドルウェアを改良し、グローバルスコープのプロパティ（`global builder`や`global admin`など）を設定可能なエンドポイントは、グローバルな権限を持つユーザー（グローバルビルダーまたはグローバル管理者）のみが利用できるように厳格化します。フロントエンドからのリクエストが到達する前に、適切にフィルタリングされるべきです。

コントローラの段階で、リクエストボディから`builder`や`admin`といったグローバル権限に関連するキーを、呼び出し元がグローバル管理者でない限り削除する仕組みを導入します。これは、将来的なSDKの回帰バグなどに対する「多層防御 (Defense-in-depth)」としても有効です。

あなたが直接これらのバックエンドのコードを修正することはありませんが、以下の点に留意してください。

1. **ベンダーからの情報収集:** Budibaseを利用している場合は、公式アナウンスやセキュリティ情報を常にチェックし、修正パッチがリリースされ次第、速やかに適用するようにチームに働きかけましょう。

2. **最小権限の原則:** 開発環境や本番環境でユーザーに付与する権限は、必要最低限に留める「最小権限の原則」を徹底しましょう。特に、Budibaseのようなプラットフォームでは、不要な管理者アカウントや権限を放置しないことが重要です。

3. **APIセキュリティへの意識:** フロントエンドから呼び出すAPIエンドポイントが、どのような認証・認可ロジックを持っているか、常に意識するようにしましょう。不審なAPIリクエストや、過度な権限を要求するような挙動がないか、開発者ツール等で確認する習慣も有効です。

まとめ

今回のBudibaseの脆弱性は、ローコードプラットフォームのセキュリティがどれほど重要であるかを再認識させるものです。たとえフロントエンドの開発に集中していても、その基盤となるバックエンドや利用サービスのセキュリティ動向には常にアンテナを張り、チーム全体で連携して対応していくことが、安全なWebアプリケーションを提供する上で不可欠です。

あなたのプロジェクトがBudibaseを利用している場合、この情報をもとに早急なセキュリティ監査とアップデートの計画を立ててください。利用していない場合でも、自身の担当するサービスや、依存しているSaaS製品のセキュリティ情報には常に注意を払いましょう。セキュリティは、開発者全員で守るべきものです。