はじめに：LobeHubの深刻な脆弱性について

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、オープンソースのAIチャットボットUI「LobeHub」で報告された、極めて重大なセキュリティ脆弱性（GHSA-xmwj-c75x-6346 / CVE-2026-54157）について解説します。この脆弱性はServer-Side Request Forgery（SSRF）の一種であり、バックエンドの脆弱性ではありますが、最終的にはユーザーのセッション乗っ取りなど、フロントエンドを含むアプリケーション全体に深刻な影響を及ぼす可能性があります。その仕組み、影響、そしてフロントエンド開発者が知るべき教訓について深掘りしていきましょう。

脆弱性の概要と仕組み：なぜ認証がスキップされたのか

LobeHubの`app.lobehub.com`に存在する`/webapi/proxy`というAPIエンドポイントが、本来あるべき認証プロセスを経ずに利用可能な状態になっていました。このエンドポイントは、POSTリクエストのボディに含まれる任意のURLを受け取り、LobeHubのサーバー側からそのURLにアクセスし、得られたレスポンスをリクエスト元にそのまま返します。つまり、LobeHubのサーバーを匿名プロキシのように利用できてしまうということです。

この問題は、以前に報告され修正された類似の脆弱性（CVE-2024-32964）が`/api/proxy`に対して適用された際、`/webapi/proxy`エンドポイントがその修正対象から漏れてしまったことが原因です。さらに悪いことに、Next.jsのミドルウェア設定も`/webapi/`パスをスキップするように構成されていたため、結果としてこのエンドポイントでは認証が全く行われない状態になっていました。

攻撃とその深刻な影響：フロントエンドユーザーへの波及

この認証スキップの脆弱性が悪用されると、以下のような多岐にわたる、そして非常に深刻な影響が考えられます。

攻撃者はLobeHubのサーバーを介して任意の外部URLにリクエストを送れるため、LobeHubが稼働しているVercelインフラに関する内部情報（サーバーのIPアドレス、内部トレースIDなど）が漏洩する可能性があります。また、Vercelの管理プレーン（Edge ConfigやAPI）へのアクセスも試行可能となり、たとえ認証エラーが返されたとしても、SSRFによるブロックは行われません。

これはフロントエンドエンジニアが特に注意すべき点です。攻撃者が用意した悪意のあるウェブサイトにユーザーがアクセスする（CSRF攻撃と組み合わせる）と、LobeHubのプロキシを経由して、攻撃者が指定した不正なクッキー（例: セッションID）がユーザーのブラウザに設定されてしまう可能性があります。LobeHubがClerkなどの認証サービスをセッション管理に利用している場合、攻撃者が事前にセッションIDを固定し、ユーザーがその固定されたIDでログインすると、攻撃者がそのユーザーのセッションを乗っ取ることができる「セッション固定攻撃」が成立します。これは、ユーザーがログイン後に攻撃者にアカウントを不正利用されるリスクを意味します。

このプロキシエンドポイントにはリクエストの送信レート制限がないため、攻撃者はLobeHubのサーバーを匿名プロキシとして利用し、スキャン、フィッシング、あるいは他のサービスへのIPベースの信頼関係を悪用した不正アクセスなど、様々な悪意ある活動を行う可能性があります。これにより、LobeHubのIPアドレスがブラックリストに登録されるなどの風評被害も懸念されます。

フロントエンドエンジニアが知るべき対策と教訓

本脆弱性はバックエンドの修正で解決されるものですが、フロントエンド開発者もAPI設計やセキュリティレビューにおいて、以下の点を意識することが重要です。

1. 最も重要な対応策は、`/webapi/proxy`エンドポイントのルートハンドラに、他のAPIルートと同様に認証処理（`checkAuth()`関数など）を導入することです。APIルートは原則として全て認証を必須とするべきであり、例外を設ける場合は厳格なレビューが必要です。

2. もし、このプロキシ機能がクライアントサイドでのURLプレビューのためだけに本当に必要なものであれば、サーバーサイドのプロキシエンドポイントを完全に削除し、ブラウザ側でURLプレビュー処理を行うことも検討すべきです。ただし、この場合CORS（Cross-Origin Resource Sharing）などの制約を考慮する必要があります。

3. **Next.jsなどフレームワークのミドルウェア設定の注意点:** `/webapi/`のようなパスをスキップする設定は、意図しない認証バイパスにつながる可能性があります。パスのパターンマッチングには細心の注意を払い、セキュリティに関連するミドルウェアが期待通りに全ての関連パスに適用されているかを常に確認しましょう。

4. **セキュリティレビューの徹底:** 以前のセキュリティ修正（CVE-2024-32964）があったにも関わらず、類似の機能（`/webapi/proxy`）に適用漏れがあったことは、セキュリティ修正の網羅性チェックの重要性を示しています。類似の機能やパスが存在しないか、継続的に確認する体制を構築しましょう。

5. **セッション管理とクッキーのセキュリティ:** フロントエンドでクッキーやセッションIDを扱う際、`HttpOnly`、`Secure`、`SameSite`属性を適切に設定し、XSSやCSRF、セッション固定攻撃のリスクを最小限に抑えるよう常に心がけてください。

まとめ

LobeHubの脆弱性は、たとえバックエンドの脆弱性であっても、その影響が情報漏洩、セッションハイジャックといった形で最終的にユーザーやフロントエンドに波及する可能性を示しています。API設計、フレームワーク設定、そしてセキュリティ修正の適用範囲に至るまで、開発プロセスのあらゆる段階でセキュリティを意識することの重要性を改めて認識させられる事例と言えるでしょう。皆さんの開発するアプリケーションでも、同様の認証スキップやプロキシ機能の悪用がないか、ぜひこの機会に再点検してみてください。