はじめに：なぜフロントエンドエンジニアも知るべきか

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、ローコード/ノーコードプラットフォームであるBudibaseのOAuth2設定機能で発見された深刻な脆弱性、CVE-2026-48153（GHSA-4q6h-8p4v-67vq）について解説します。直接Budibaseを使っていない方も、クラウド環境でAPIやBaaSを利用する際に、サーバーサイドリクエストフォージェリ（SSRF）という攻撃手法と、それがもたらす脅威について理解しておくことは非常に重要です。この脆弱性は、内部システムやクラウド上の機密情報への不正アクセスにつながる可能性があり、システム全体のセキュリティリスクを高めます。

脆弱性の概要：SSRF（Server-Side Request Forgery）とは？

SSRFとは、「サーバーサイドリクエストフォージェリ」の略で、攻撃者が脆弱なWebアプリケーションのサーバーを悪用し、任意のURLへリクエストを強制する攻撃手法です。これにより、本来アクセスできないはずの内部ネットワーク上のシステムや、クラウド環境のインスタンスメタデータサービスなどへ、サーバー自身からリクエストを送らせ、その応答から情報を窃取したり、不正な操作を行ったりすることが可能になります。

今回のBudibaseのケースでは、OAuth2のトークン取得プロセスにおいて、このSSRFの脆弱性が発見されました。悪意のある「ビルダー」（アプリ開発者）が、不正なURLをOAuth2設定に指定することで、この攻撃を成功させる可能性があります。

Budibaseにおける脆弱性の技術的な詳細

この脆弱性は、BudibaseのOAuth2トークン取得を行う`fetchToken`関数に起因します。通常、外部からのURL指定に対しては、内部ネットワークへのアクセスをブロックするための`blacklist.isBlacklisted`というチェックが行われるべきなのですが、この関数が意図せずスキップされていました。加えて、OAuth2設定のURL入力に対するバリデーションが不十分であったため、ビルダーは任意のURL（例: `http://127.0.0.1` や `http://169.254.169.254`）を設定できてしまいます。

Budibaseサーバーは、指定された悪意のあるURLへ`node-fetch`を使ってリクエストを送信します。この際、リクエストに対する応答の一部が検証エラーメッセージとして返されてしまうため、攻撃者は内部サービスの存在確認や、応答から機密情報の一部を取得することが可能になります。さらに、`node-fetch`がリダイレクトに追従してしまうため、より広範な内部リソースへのアクセス経路が開かれてしまいます。

想定される深刻な影響とフロントエンドエンジニアへの関連性

この脆弱性が悪用された場合、以下のような極めて深刻なリスクが発生します。フロントエンドエンジニアとして、ご自身の開発するアプリケーションが連携するバックエンドやクラウド環境で同様のリスクがないか、ぜひ見直してください。

<ul><li><strong>Budibase Cloud環境でのテナント間データ漏洩:</strong> 攻撃者は同一サーバー上で稼働する他のテナントのデータベース（CouchDBなど）にアクセスし、ユーザー情報、アプリ定義、データソース設定（サードパーティの認証情報を含む）といった機密情報を読み取ることができます。これはBudibaseのテナント分離機能を迂回するため、通常のアクセス制御は適用されません。</li><li><strong>IAM認証情報（クレデンシャル）の窃取:</strong> AWSなどのクラウド環境では、インスタンスに割り当てられたIAMロールの一時認証情報が、メタデータサービス（例: `http://169.254.169.254/latest/meta-data/iam/security-credentials/`）から直接取得されてしまう可能性があります。これにより、そのIAMロールが持つクラウド上のリソースに対する権限が不正利用される恐れがあります。フロントエンドから利用するAPIのアクセスキーやシークレットが漏洩するリスクと直結します。</li><li><strong>セルフホスト環境での内部サービスへの不正アクセス:</strong> CouchDB、Redis、MinIOなど、サーバーが稼働しているホストまたはPodネットワーク内の他の内部サービスにもアクセスが可能になり、環境全体のリスクが高まります。</li></ul>

推奨される対策と開発者へのアドバイス

Budibaseの開発チームは、この問題に対して以下の対応を推奨しています。これは一般的なSSRF対策としても非常に参考になります。

<ul><li>OAuth2関連の`fetchToken`関数内でURLをフェッチする前に、`blacklist.isBlacklisted`によるブラックリストチェックを必ず実行する。</li><li>`fetch`の際には`redirect: "manual"`を設定し、リダイレクト先も個別に検証する実装にする。</li><li>最も簡単な解決策は、ブラックリストチェックとリダイレクト検証の両方を適切に処理する既存の`fetchWithBlacklist`関数に置き換えることです。</li></ul>

フロントエンドエンジニアの皆さんには、ご自身が関わるアプリケーションが利用するAPIやサービスにおいて、入力値の検証が厳格に行われているか、特にURLなど外部からの入力を受け付ける部分のセキュリティを意識することをお勧めします。クラウドサービスを利用している場合は、IAMロールの権限を最小限に留める「最小権限の原則」を徹底し、インスタンスメタデータへのアクセス制限を適切に行うなど、サーバーサイドやインフラのセキュリティプラクティスについても理解を深めることが、結果的にアプリケーション全体の安全性を高めます。

まとめ

今回のBudibaseのSSRF脆弱性は、攻撃者が開発者アカウントを利用してシステム内部の機密情報にアクセスできるという、非常に深刻な問題です。フロントエンド開発者が直接サーバーのコードを書く機会は少ないかもしれませんが、利用するツールやサービスのセキュリティ特性を理解し、サーバーサイドとの連携におけるリスクを把握することは、現代のフルスタック的な開発において不可欠です。

この脆弱性を機会に、ご自身のプロジェクトにおける入力値検証、認証・認可の仕組み、そしてクラウド環境のセキュリティ設定について改めて見直し、より安全なアプリケーション開発を心がけていきましょう。