はじめに：Logto `logto-tunnel` とは？

Logtoは、認証基盤を提供するサービスで、開発者が簡単にシングルサインオン (SSO) や多要素認証 (MFA) などの認証機能をアプリケーションに組み込めるように設計されています。多くのフロントエンドアプリケーションが認証機能を必要とすることから、Logtoを利用しているエンジニアの方もいらっしゃるかもしれません。

今回注目する`@logto/tunnel`は、Logto CLIの一部として提供されるツールで、開発中のカスタムサインインUI（ログイン画面など）をローカルでプレビューしたり、Logtoのサービスと連携させたりするために使われます。これは、ローカルの静的ファイルをHTTPサーバーとして提供し、開発者が変更を即座に確認できるようにする便利な機能です。

脆弱性の概要 (GHSA-rxjr-6c9q-h67x / CVE-2026-63188)

今回報告された脆弱性 (ID: GHSA-rxjr-6c9q-h67x, CVE: CVE-2026-63188) は、`@logto/tunnel` におけるパス・トラバーサル（Path Traversal）攻撃に起因するものです。深刻度は「High」とされており、非常に注意が必要です。

この脆弱性を悪用されると、`--experience-path` オプションで指定されたカスタムUIのルートディレクトリ外にあるローカルファイルが、認証されていない第三者によって読み取られてしまう可能性があります。例えば、開発環境で使用しているAPIキー、データベースの認証情報、設定ファイルといった機密情報が外部に漏洩する危険性があるのです。

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

`logto-tunnel` は、`--experience-path` オプションで指定されたローカルフォルダ内のファイルを静的ファイルとして提供します。内部的には、リクエストされたURLパスを基に、`path.join(staticPath, request.url)` のようにしてファイルシステム上のパスを構築しています。

問題は、このパス構築の過程で、リクエストURLに含まれる `../` (親ディレクトリへの移動) のようなパスセグメントが適切に処理（正規化）されず、そのままファイルシステムパスの構築に使われてしまう点にあります。また、生成されたファイルシステムパスが、本来公開すべき `staticPath` (すなわち `--experience-path` で指定されたディレクトリ) の範囲内に収まっているかをチェックする「パス閉じ込め (containment check)」が不足していました。

このため、攻撃者は `http://<host>:<port>/../secret.txt` のようなURLをリクエストすることで、`staticPath` の親ディレクトリにある `secret.txt` といったファイルを直接指定し、その内容を読み取ることができてしまいます。

実際の攻撃シナリオと影響

この脆弱性のPoC (Proof of Concept) は非常にシンプルです。仮に、カスタムUIのルートディレクトリが `/tmp/logto-ui/static` で、その一つ上のディレクトリ `/tmp/logto-ui/` に `secret.txt` という機密ファイルが存在するとします。

1. 開発者が `logto-tunnel --endpoint https://<tenant-id>.logto.app --port 9000 --experience-path /tmp/logto-ui/static` のように起動します。

2. 攻撃者が、この `logto-tunnel` がリッスンしているポート (例: 9000) に到達可能な環境から、`http://<host>:9000/../secret.txt` のようなリクエストを送信します。

3. `logto-tunnel` は `secret.txt` の内容をHTTPレスポンスとして返してしまいます。

この結果、開発者のローカルマシン上にある、プロジェクトに関連する機密ファイルが外部に漏洩する可能性があります。特に、開発環境でLogto CLIが稼働するPCのポートが外部に公開されている場合、そのリスクは非常に高まります。例えば、共有ネットワーク内で他の開発者に見られてしまう、あるいは誤ってインターネットに公開してしまった場合には、認証されていない不特定多数のユーザーがファイルにアクセスできるようになります。

フロントエンドエンジニアが取るべき対策

1. **Logto `logto-tunnel` のアップデート**: もしLogtoを利用している場合、Logto公式からのアップデート情報を確認し、速やかに脆弱性が修正されたバージョンに更新してください。これにより、直接的なリスクを排除できます。

2. **開発環境におけるポートの管理**: `logto-tunnel` のような開発サーバーやCLIツールがリッスンするポートは、必要がなければ外部に公開しないでください。特に、`0.0.0.0` のように全てのインターフェースでリッスンする設定には注意が必要です。SSHトンネルやVPNを利用して、必要な時だけ安全にアクセスできるようにすることを検討しましょう。

3. **機密ファイルの配置に注意**: APIキー、認証情報、設定ファイルなど、機密性の高いファイルは、開発サーバーが静的ファイルとして提供する可能性のあるディレクトリの範囲外に配置し、また、アクセス権限を適切に設定してください。今回のケースのように、親ディレクトリに置いたファイルが狙われる可能性を考慮しましょう。

4. **一般的なパス・トラバーサル対策の理解**: 今回の脆弱性は、Webアプリケーションにおける基本的な脆弱性の一つであるパス・トラバーサルです。自身が開発するNode.jsアプリケーションや、他の開発ツールを使用する際にも、入力されたパスの正規化、指定されたディレクトリ範囲内への制限（`chroot`やサンドボックス化）が適切に行われているかを確認する習慣をつけましょう。`path.resolve()`や`path.normalize()`のようなメソッドは、URLパスをファイルシステムパスに変換する際に有効ですが、それでも完全に安全とは限らないため、最終的なパスが意図したディレクトリ内に収まっているかどうかのチェック（例: `resolvedPath.startsWith(basePath)`）が重要です。

5. **セキュリティ情報の継続的な収集**: 使用しているライブラリやフレームワーク、開発ツールに関するセキュリティ脆弱性情報は、GitHub Security AdvisoriesやNIST NVDなどのデータベース、または公式アナウンスを通じて常にチェックするようにしましょう。

まとめ

今回のLogto `@logto/tunnel` の脆弱性は、開発ツールであってもセキュリティ上のリスクとなり得ることを改めて示しました。フロントエンドエンジニアは、アプリケーションコードだけでなく、開発環境や使用するツールチェーン全体のセキュリティにも意識を向ける必要があります。

特にパス・トラバーサルのような基本的な脆弱性は、様々なコンテキストで発生し得るため、そのメカニズムと対策を理解しておくことは非常に重要です。常に最新の情報を入手し、安全な開発プラクティスを心がけましょう。