はじめに：なぜフロントエンドエンジニアがバックエンドの認証脆弱性を知るべきか

今回解説する脆弱性は、ノーコード/ローコードプラットフォームであるBudibaseのバックエンドで発生した、非常に深刻度の高い認証バイパスの脆弱性です。直接的にフロントエンドのコードに起因するものではありませんが、APIを介してバックエンドと連携する現代のウェブアプリケーション開発において、フロントエンドエンジニアもAPIセキュリティのメカニズムと潜在的な脅威を理解することは非常に重要です。

意図しないAPIアクセスは、データ漏洩や不正操作に直結します。本記事では、この脆弱性の詳細を技術的に深掘りし、皆さんの日々の開発におけるセキュリティ意識向上の一助となれば幸いです。

脆弱性の概要と基本情報

この脆弱性は、GHSA-8783-3wgf-jggfおよびCVE-2026-41428として識別されており、深刻度は「Critical」に分類されています。

Budibaseのバックエンドにおける認証ロジックの不備により、攻撃者は本来認証が必要なAPIエンドポイントに対し、認証なしでアクセスできる状態となっていました。

脆弱性の詳細：なぜ認証がバイパスされたのか？

この脆弱性は、主に以下の2つの条件が重なることで発生しました。

Budibaseのバックエンドでは、リクエストされたURLが認証を必要としない「公開エンドポイント」であるかを判断するために、URLと事前に定義されたパターンを正規表現で照合していました。しかし、この正規表現がURLの先頭（`^`）や末尾（`$`）を固定する「アンカー」を持っていませんでした。

アンカーがない正規表現は、URLの任意の位置にパターンがマッチすれば「一致」と判断してしまいます。

Koaフレームワークを使用している場合、照合対象となる`ctx.request.url`には、URLパス（例: `/api/global/users/search`）だけでなく、その後のクエリパラメータ（例: `?x=/api/system/status`）も含まれます。一方、クエリパラメータを含まない純粋なURLパスは`ctx.request.path`で取得できます。

上記2つの条件が重なることで、攻撃者は以下のような手法で認証を回避できました。

例えば、本来認証が必要なエンドポイントが `POST /api/global/users/search` だとします。ここに、公開エンドポイントのパスを模したクエリパラメータ（例: `?x=/api/system/status`）を付与してリクエストすると、URLは `POST /api/global/users/search?x=/api/system/status` となります。

正規表現は、このURLの`ctx.request.url`全体に対してマッチングを行います。アンカーがないため、クエリパラメータ内の `/api/system/status` 部分に正規表現がマッチしてしまい、システムはこれを「公開エンドポイントへのリクエスト」と誤認します。結果として、本来行われるべき認証チェックがスキップされ、認証なしで機密性の高いエンドポイントにアクセスできてしまうのです。

もたらされる具体的なリスクと影響エンドポイント

この脆弱性の影響を受けるのは、グローバルな認証チェックのみに依存し、かつ個別のルートレベルで追加の認証ミドルウェアが設定されていないエンドポイント（具体的には`loggedInRoutes`に属するエンドポイント）です。認証されていない第三者が、以下の深刻な攻撃を行う可能性があります。

一方で、`builderOrAdminRoutes`や`adminRoutes`のように、個別のルートで厳格な認証チェック（例: `isAdmin(ctx.user)`）が行われるエンドポイントは、`ctx.user`が未定義のため403エラーとなり、この脆弱性の影響を受けません。

フロントエンドエンジニアへの教訓とAPI設計の考慮点

この脆弱性はバックエンドの認証ロジックの問題ですが、フロントエンドエンジニアも無関係ではありません。API連携を行う上で、以下のような点を常に意識することが重要です。

「もしバックエンドの認証が破られたら？」という視点を持つことで、より堅牢なアプリケーション設計に貢献できます。

推奨される対応策

この脆弱性を修正するためには、以下の2つの方法（両方を適用することが強く推奨されます）があります。

正規表現をコンパイルする際に、URLのパスの開始（`^`）と終了（`$`、またはクエリパラメータの開始`?`）にマッチするアンカーを追加します。これにより、正規表現がURL全体、またはパスの部分にのみ正確にマッチするようになります。

例：`new RegExp('^' + route + '(\?|$)')` のように修正します。

正規表現でマッチングを行う際、クエリパラメータを含む`ctx.request.url`ではなく、クエリパラメータを含まない純粋なURLパスである`ctx.request.path`を使用するように変更します。

例：`regex.test(ctx.request.path)` のように修正します。

これらを組み合わせることで、意図しないクエリパラメータによる認証バイパスを確実に防ぐことができます。

まとめ

Budibaseの認証バイパス脆弱性 (CVE-2026-41428) は、正規表現の不適切な使用とURLの解釈の誤りが重なることで発生した、非常に技術的かつ深刻な問題でした。この事例から、認証ロジックの設計における正規表現の厳密な利用や、HTTPリクエストの各要素（パス、クエリ、ヘッダなど）の正確な扱いがいかに重要であるかを再認識させられます。

フロントエンドエンジニアの皆さんにとって、直接バックエンドのコードを修正する機会は少ないかもしれませんが、APIとの連携を日々行う中で、このようなバックエンド側のセキュリティ脆弱性について理解を深めることは、より安全なウェブアプリケーションを開発するための重要なステップとなります。常日頃からセキュリティ意識を持ち、バックエンドチームとの密な連携を心がけましょう。