CVE-2026-35219とは何か？ BudibaseにおけるSSRFの危険性

CVE-2026-35219は、Low-code/No-codeプラットフォームであるBudibaseに存在する、サーバーサイドリクエストフォージェリ（SSRF）の脆弱性です。SSRFは、攻撃者がサーバーに対して意図しないリクエストを発行させ、そのサーバーがアクセスできる内部ネットワークや外部サービスへのアクセスを許してしまう危険な脆弱性です。今回のBudibaseのケースでは、特にオートメーション機能において、ユーザーが提供したURLへのHTTPリクエストが、本来適用されるべきIPブラックリストによる保護を完全にバイパスしてしまう点が問題となっています。

脆弱性の詳細とメカニズム

この脆弱性は主に以下の2つの側面から発生します。

1. <strong>オートメーションステップにおけるブラックリストの不適用:</strong> BudibaseのWebhook、Zapier、n8n、Slack、Discordなどのオートメーションステップは、ユーザーが指定したURLに対してサーバーサイドで直接<code>node-fetch</code>を使用してHTTPリクエストを送信します。この際、本来REST API統合で適用されるべきIPブラックリストのチェックが全く行われません。結果として、攻撃者はオートメーションを通じて、通常アクセスできないはずの内部IPアドレス（例: <code>http://10.0.0.1/</code>, <code>http://192.168.1.100/admin</code>など）やクラウドメタデータサービス（例: <code>http://169.254.169.254/latest/meta-data/</code>）へリクエストを送信し、情報を窃取したり、内部サービスを操作したりすることが可能になります。

2. <strong>REST API統合におけるデフォルトのブラックリストの不備:</strong> REST API統合にはIPブラックリスト機能が存在しますが、環境変数 <code>BLACKLIST_IPS</code> が設定されていない場合、デフォルトでブラックリストが空の状態となります。この場合、ブラックリストは実質的に機能せず、保護が提供されません。

脆弱性のあるコードは、<code>fetch()</code>が直接呼び出されている箇所であり、これらの呼び出しの前にURLの検証が行われていないことが確認されています。

どんな影響があるのか？ フロントエンドエンジニアが認識すべきこと

このSSRF脆弱性が悪用された場合、以下のような深刻な影響が発生する可能性があります。

<ul><li><strong>内部ネットワークへのアクセス:</strong> データベース、社内システム、管理パネル、Kubernetes APIなど、外部からアクセスが制限されているはずの内部サービスへの不正アクセス。</li><li><strong>クラウドメタデータの窃取:</strong> AWS EC2のメタデータサービスなどから、一時的な認証情報やその他の機密情報を窃取されるリスク。</li><li><strong>情報漏洩:</strong> 内部ネットワークから機密情報や認証情報を引き出される可能性。</li><li><strong>サービス妨害 (DoS):</strong> 内部サービスに対して過剰なリクエストを送信し、サービスを停止させる可能性。</li></ul>

フロントエンドエンジニアの皆さんは、直接サーバーサイドのコードを書くことは少ないかもしれませんが、ユーザーインターフェースを通じてURLやAPIエンドポイントなどの入力値を受け取る機会は多々あります。SSRFはバックエンドの脆弱性ですが、ユーザーからの「信頼できない入力」がトリガーとなることがほとんどです。そのため、フロントエンド側で不正な入力を防ぐためのバリデーションや、セキュリティリスクの高い入力値（例: ローカルIPアドレス、特定のスキーム）の制限など、可能な限り安全な入力を促すUI/UXの設計が重要になります。

フロントエンドエンジニアが考えるべき対策とベストプラクティス

この種のSSRF脆弱性に対する根本的な対策は主にサーバーサイドで行われるべきですが、フロントエンドエンジニアも自身の開発プロセスやチームでの連携において、セキュリティ意識を高めることが重要です。

<strong>サーバーサイドでの対策 (開発チーム全体で推進):</strong>

<ul><li><strong>すべてのアウトバウンドHTTPリクエストに一元的な検証を適用:</strong> <code>fetch()</code>などのHTTPクライアントを直接呼び出すのではなく、SSRF保護を組み込んだ共通のHTTPクライアントラッパーを使用する。</li><li><strong>強力なデフォルトのブラックリスト/ホワイトリスト:</strong> プライベートIPアドレス範囲（<code>127.0.0.0/8</code>, <code>10.0.0.0/8</code>, <code>172.16.0.0/12</code>, <code>192.168.0.0/16</code>, <code>169.254.0.0/16</code>など）をデフォルトでブロックする仕組みを導入する。</li><li><strong>SSRF保護をデフォルトで有効にする:</strong> 環境変数でオプトインするのではなく、デフォルトでSSRF対策が適用される設計にする。</li></ul>

<strong>フロントエンドからのアプローチ:</strong>

<ul><li><strong>入力値の厳格な検証:</strong> ユーザーがURLなどを入力するフォームでは、入力された値が有効なURL形式であるか、予期せぬスキームやドメインを含んでいないかなど、クライアントサイドで可能な限り厳しくバリデーションを行う。</li><li><strong>セキュリティ意識の向上:</strong> チーム内でSSRFのようなサーバーサイドのセキュリティリスクについて共有し、UI設計やバックエンドとのAPI連携において、常に「信頼できない入力」に対する意識を持つ。</li><li><strong>フィードバックループ:</strong> バックエンド開発者と密に連携し、どのようなURLが許可され、どのようなURLがブロックされるべきかについて共通理解を持つ。フロントエンドで収集されたデータがバックエンドでどのように処理されるかを把握する。</li></ul>

まとめ

BudibaseにおけるSSRF脆弱性（CVE-2026-35219）は、サーバーサイドのリクエスト処理の不備が内部ネットワークへの深刻な脅威となり得ることを示しています。フロントエンドエンジニアとしては、直接この脆弱性を修正する立場にはないかもしれませんが、ユーザーの入力がバックエンドのセキュリティに与える影響を理解し、安全なUI/UX設計を心がけることが極めて重要ですす。この機会に、ご自身のプロジェクトにおける入力値の取り扱い、特に外部URLやAPIエンドポイントに関する処理について再確認し、チーム全体のセキュリティ意識向上に貢献しましょう。