はじめに：なぜフロントエンドエンジニアもこの脆弱性を知るべきか？

現代のWebアプリケーション開発では、フロントエンドとバックエンドの境界はますます曖昧になっています。特に、外部サービスとの連携やWebhookの設定など、UIを介してバックエンドのネットワークリソースが操作されるケースは珍しくありません。今回ご紹介するBudibaseの脆弱性は、一見バックエンド特有の問題に見えますが、その根底にある攻撃手法は、フロントエンドがバックエンドと連携する際のセキュリティ設計に警鐘を鳴らすものです。自社でBudibaseを利用していなくとも、類似の機能を持つシステムを開発・運用している日本のフロントエンドエンジニアの皆さんにとって、この情報は決して無関係ではありません。

BudibaseのSSRF脆弱性の概要と深刻度

ID: GHSA-gfq7-5x4g-3xhf / CVE: CVE-2026-54353 として報告されているこの脆弱性は、ローコードプラットフォームであるBudibaseのバックエンドコアライブラリ（`@budibase/backend-core`）に存在します。深刻度は「high」と評価されており、認証済みでオートメーション権限を持つユーザーが悪用することで、Budibaseホストがアクセスできる内部システムへの不正なリクエストを送信できるSSRF（Server-Side Request Forgery）攻撃が可能になります。

SSRFとは、サーバーサイドのアプリケーションが意図しないリクエストを送信してしまう脆弱性です。通常、サーバーが外部から指定されたURLにアクセスする際に、そのURLが内部ネットワークのアドレスではないか、危険なサービスではないかといったチェックが行われます。しかし、このチェックが不十分だと、攻撃者はサーバーを踏み台にして、本来アクセスできない内部システムにアクセスできてしまいます。

脆弱性のメカニズム：二重のDNS解決とDNSリバインディング

この脆弱性の核心は、「二重のDNS解決」と「DNSリバインディング」という高度な攻撃手法にあります。

DNSリバインディングは、攻撃者が管理するDNSサーバーを利用して、あるドメイン名に対応するIPアドレスを時間差で変更する攻撃です。例えば、最初は安全な公開IPアドレスを返し、しばらく経ってから、内部ネットワークのプライベートIPアドレスを返すように設定することができます。

Budibaseの脆弱性は、外部へのデータ取得処理（フェッチ）において、DNSルックアップ（ドメイン名をIPアドレスに変換する処理）が二度行われることに起因します。

1. **ブラックリスト検証時:** まず、指定されたホスト名が安全かどうか（ブラックリストに載っていないか、プライベートIPではないか）を確認するためにDNSルックアップが行われます。この際、攻撃者は公開されている安全なIPアドレスを返すようにDNSを設定します。これにより、セキュリティチェックを通過します。

2. **実際の接続時:** 検証が通過した後、実際のデータ取得のためのソケット接続が行われる際に、**再度DNSルックアップ**が行われます。攻撃者は、この2回目のルックアップ時に、内部ネットワークのプライベートIPアドレス（例: 127.0.0.1、社内ネットワークのIP、クラウドのメタデータAPIのIPなど）を返すようにDNSを切り替えます。

最初のルックアップで得られたIPアドレスが実際の接続時に再利用されず破棄されるため、この時間差を利用してセキュリティチェックをすり抜け、内部システムへのアクセスが可能になります。これは「Time-of-Check to Time-of-Use (TOCTOU)」という、チェック時と使用時で条件が変わる競合状態の一種です。

攻撃による具体的な影響と情報漏洩のリスク

この脆弱性を悪用されると、攻撃者はBudibaseホストからアクセス可能なあらゆる内部システムに不正にアクセスし、機密情報を窃取できる可能性があります。特に危険なのは、以下のような情報です。

攻撃者は内部サービスからの応答内容をオートメーションの出力に直接表示できるため、「非盲目的SSRF」となり、盗み出した情報を直接確認できてしまいます。

・**ループバックサービス**: Budibaseホスト自身で動作するサービス（`127.0.0.1` や `localhost` など）にアクセスされ、ローカルの機密情報が窃取される。

・**社内ネットワークサービス**: RFC1918で定義されるプライベートIPアドレスを持つ社内ネットワーク内のサーバーやデータベースにアクセスされ、企業の機密情報が漏洩する。

・**クラウドインフラ**: KubernetesクラスターやVPC（Virtual Private Cloud）内の内部サービスにアクセスされ、クラウド環境の構成情報やデータが窃取される。

・**クラウドメタデータエンドポイント**: AWSの `169.254.169.254` のような、クラウド環境自体の情報（一時的な認証情報など）を提供するAPIにアクセスされる危険性があります。特に、IMDSv2が強制されていないクラウド環境では、これによりIAM認証情報が漏洩し、攻撃者がクラウド環境全体を乗っ取る足がかりとなる可能性があります。これは非常に深刻なリスクです。

また、マルチテナントのホスティング環境では、他のテナントの内部インフラにアクセスされる可能性も考えられます。

影響を受けるBudibaseの機能と、フロントエンド開発者が注意すべき点

この脆弱性は、Budibaseの以下のオートメーション機能を利用する際に影響を受けます。

・Outgoing Webhook（外部へのウェブフック送信）<br>・Slack、Discord、Make、Zapier、n8nなどの外部連携機能<br>・AI extract、object-store fetches など

もし皆さんのプロジェクトでBudibaseを利用していて、これらの機能を使っている場合は、即座にバージョンを確認し、対応が必要です。また、Budibaseを直接使っていなくとも、同様にユーザーが入力したURLやドメイン名をバックエンドがフェッチするような機能（例：プレビュー画像生成、OEmbed情報の取得、外部APIとの連携設定、Webhook URLの登録など）を持つ自社サービスを開発している場合は、バックエンドのSSRF対策が十分に施されているか、バックエンドエンジニアと連携して確認することが重要です。

推奨される対応策とセキュリティベストプラクティス

この脆弱性への対応は、以下の点を中心に進めるべきです。

1. **Budibaseのアップデート**: 開発元から提供される公式パッチや最新バージョンへの速やかなアップデートが最も重要です。これが根本的な解決策となります。

2. **DNS解決の改善**: ベンダーは、DNSルックアップの結果を保存し、検証時と実際の接続時で同じIPアドレスを使用するように実装を修正する必要があります。これにより、DNSリバインディング攻撃を防ぐことができます。

3. **最小権限の原則 (PoLP)**: オートメーション権限を持つユーザーに対して、必要最小限の権限のみを付与し、万が一の際の被害を最小限に抑えます。

4. **ネットワークレベルでの防御**: 可能であれば、WAF（Web Application Firewall）などを導入し、内部IPアドレスへのアクセスをブロックするなどの追加の防御策を検討することも有効です。（根本的な解決ではありませんが、被害範囲を限定する可能性があります。）

・**外部URLの入力値検証**: ユーザーが外部URLを入力できるUIを実装する際は、その入力値が安全であるかどうかのチェックをバックエンドに任せきりにせず、フロントエンド側でもできる限りの検証（URLスキーム、ドメイン形式など）を行う意識を持つことが望ましいです。もちろん、フロントエンドの検証は簡単に回避されるため、バックエンドでの厳格な検証は必須です。

・**バックエンドとの連携強化**: 外部連携機能や、ファイル・URLフェッチなどの機能要件定義・設計段階から、SSRFや他のサーバーサイドの脆弱性リスクについてバックエンドエンジニアと密にコミュニケーションを取り、セキュリティを考慮した設計を心がけましょう。

・**セキュリティ意識の向上**: 最新の脆弱性情報に常に目を光らせ、自身の担当領域だけでなく、システム全体のセキュリティに対する理解を深めることが、より安全なWebアプリケーション開発につながります。

まとめ

BudibaseのSSRF脆弱性は、DNSリバインディングという巧妙な攻撃手法を利用した深刻な問題であり、内部ネットワークやクラウドインフラへの大規模な情報漏洩に繋がる可能性があります。もしBudibaseを使用している場合は、速やかに最新バージョンへのアップデートを行ってください。

また、直接Budibaseを使用していない日本のフロントエンドエンジニアの皆さんも、この事例から「ユーザー入力に基づいてバックエンドが外部リソースにアクセスする機能」の危険性を再認識し、よりセキュアな設計と実装を心がけるきっかけとしていただければ幸いです。フロントエンドとバックエンドが連携し、一体となってセキュリティを強化していくことが、現代のWebアプリケーション開発には不可欠です。