はじめに

Astroをお使いの日本のフロントエンドエンジニアの皆さん、こんにちは！今回は、Astroのミドルウェアにおいて発見された深刻な認証バイパス脆弱性(GHSA-vj59-8hwv-xxmv / CVE-2026-59731)について深掘りしていきます。特に、URLのデコード処理とパスの正規化の不一致がどのようにしてこの問題を引き起こすのか、技術的な詳細と具体的な再現パターンを解説し、皆さんのプロジェクトでの対策に役立てていただければ幸いです。

脆弱性の概要と深刻度

この脆弱性は、Astro 6.4.7で「再導入」されたミドルウェア認証バイパスのパターンです。攻撃者が巧妙に多重エンコードされたURLパスを使用することで、ミドルウェアによる認証チェックをすり抜け、保護されたルートにアクセスできてしまう可能性があります。深刻度は「High」と評価されており、迅速な対応が求められます。

問題の核心は、AstroがURLパス名をデコードする際のイテレーション制限と、その後のルーティング処理におけるパス名の正規化の不一致にあります。具体的には、ミドルウェアが認証判断を行う際に参照するパス名と、実際にリクエストをルーティングする際に参照するパス名が異なることで、本来ブロックされるべきアクセスが許可されてしまうのです。これは、CWE-647 (Use of Non-Canonical URL Paths for Authorization Decisions) に分類される典型的な問題です。

具体的に何が問題なのか？パス名の認識のずれ

脆弱な状況下では、ミドルウェアとルーティング処理で以下のようなパス名の認識のずれが発生します。

**ミドルウェアが認証判断で認識するパス:** `/` + `%61dmin` (部分的にデコードされたパス)

**その後のルーティング処理が認識するパス:** `/admin` (完全にデコードされた正規のパス)

このずれにより、ミドルウェアは「`/%61dmin`は保護された`/admin`ではない」と判断してリクエストを通過させますが、その後のルーティング処理は「これは保護された`/admin`だ」と判断し、コンテンツを表示してしまうのです。

根本原因：URLデコードのイテレーション制限とルーティングの挙動

Astroでは、URLデコードの繰り返し処理が導入されています（PR #16967）。これは、`/admin`が`/%61dmin`としてエンコードされていても、`/%2561dmin`として二重にエンコードされていても、ミドルウェアが常に「`/admin`」という完全にデコードされたパス名を受け取ることを意図していました。

しかし、このデコード処理には最大10回のイテレーション制限が設けられています。この制限に達すると、たとえまだ完全にデコードされていなくても、その時点での部分的にデコードされたパス名が返されてしまいます。

Astro内部のデコードロジックの概念的なスニペットは以下のようになります。

```js let iterations = 0; let decoded = initialPathname; while (decoded !== pathname && iterations < 10) { pathname = decoded; try { decoded = decodeURI(pathname); } catch { break; } iterations++; } return decoded; // 制限に達すると部分デコード値が返される可能性がある ```

ミドルウェアで処理された後、Astroのルーティング処理では、パス名をマッチングする際にさらに独立した`decodeURI()`操作が行われます。

例えば、多重エンコードによってミドルウェアが`/%61dmin`というパス名を受け取ったとします。このパス名は、まだ完全に正規化されていません。しかし、ルーティング処理では再度`decodeURI()`が実行され、`/%61dmin`が最終的に`/admin`へとデコードされます。

この「ミドルウェアが参照するパス」と「ルーターが参照するパス」の間の乖離が、認証バイパスの根本原因です。

脆弱なパターンの再現とPoC

この脆弱性が悪用されるのは、ミドルウェアがパス名に基づいて認証判断を行い、その後、`next(context.url)`のようにリクエストをAstroのルーティング機構に渡す場合です。

以下は、`/admin`または`/admin/`で始まるパスをブロックする単純なミドルウェアの例です。

```js import { defineMiddleware } from 'astro:middleware'; export const onRequest = defineMiddleware(async (context, next) => { const pathname = context.url.pathname; if (pathname === '/admin' || pathname.startsWith('/admin/')) { return new Response( '403 Forbidden: middleware blocked canonical /admin', { status: 403, headers: { 'content-type': 'text/plain;charset=UTF-8', 'x-middleware-pathname': pathname, }, } ); } if (pathname !== '/') { const response = await next(context.url); response.headers.set('x-middleware-pathname', pathname); response.headers.set( 'x-vuln-pattern', 'next(context.url) rewrite after pathname check' ); return response; } return next(); }); ```

このミドルウェアは、`context.url.pathname`をチェックして認証判断を行い、その後`next(context.url)`を呼び出しています。

攻撃者は、意図的にURLを多重エンコードします。例えば、`/admin`を11回エンコードしたパスは以下のようになります。

`%252525252525252525252561dmin`

**通常のアクセス（ブロックされる例）:**

```bash curl -i http://127.0.0.1:8989/admin ```

レスポンス: `HTTP/1.1 403 Forbidden` (ミドルウェアによってブロックされます)

**バイパスアクセス（脆弱性を悪用した例）:**

```bash curl -i http://127.0.0.1:8989/%252525252525252525252561dmin ```

レスポンス: `HTTP/1.1 200 OK` (保護されたコンテンツが表示されます)

このとき、ミドルウェアは`x-middleware-pathname: /%61dmin`を見ていますが、最終的にルーティングされたパスは`/admin`となり、保護されたコンテンツが表示されてしまいます。

エンコード深度の分析

この脆弱性は、URLエンコードの深度が11に達したときに発生します。Astroのデコーダのイテレーション制限は10回なので、それ以上のエンコード深度を持つパスが渡されると、部分的にしかデコードされません。

デコード処理のトレース（簡略化）:

- `depth 0: /%61dmin` -> `/admin` (完全にデコード)

- `...`

- `depth 10: /%2525252525252525252561dmin` -> `/admin` (完全にデコード、ミドルウェアでブロック)

- `depth 11: /%252525252525252525252561dmin` -> `/%61dmin` (部分的にデコードされる。イテレーション制限到達)

深度11のパスがミドルウェアに渡されると、イテレーション制限のため`/%61dmin`として認識されます。このパスは、ミドルウェアの`if (pathname === '/admin' || pathname.startsWith('/admin/'))`の条件に一致しないため、通過を許されます。その後、ルーティング処理で再度`decodeURI()`が実行され、`/%61dmin`が`/admin`へと完全にデコードされ、保護されたルートに到達してしまうのです。

脆弱性悪用の前提条件と影響

この脆弱性が悪用されるには、以下の2つの条件が満たされている必要があります。

**1. パスベースの認証:** ミドルウェアが`context.url.pathname`を使用して、特定のパス（例: `/admin`）へのアクセスを制限している場合。

**2. リライトベースのルーティング:** ミドルウェアが認証判断を行った後、`next(context.url)`のような形式でリクエストをAstroのルーティング機構に渡し、その後にルーティング処理が行われる場合。

これらの条件が満たされている場合、未認証の攻撃者は、ミドルウェアによって保護されている `/admin`、`/api/admin`、`/internal`、`/dashboard` などの重要な管理ページやAPIエンドポイントにアクセスできる可能性があります。これにより、機密情報の漏洩、不正な操作、システムの乗っ取りなど、深刻な被害につながる恐れがあります。

推奨される対策

この脆弱性に対処するためには、以下の対策が推奨されます。

URLデコード処理がイテレーション制限に達しても完全に正規化されなかった場合、部分的にデコードされたパスを返すのではなく、そのリクエスト自体を拒否するべきです。これにより、意図的に多重エンコードされた悪意のあるリクエストを遮断できます。

**提案される修正の概念（Astro内部のデコーダロジック）:**

```js let iterations = 0; while (decoded !== pathname) { if (iterations >= 10) { // デコードが安定する前に制限を超えた場合はエラーとして処理 throw new Error('URL encoding depth exceeded'); } pathname = decoded; try { decoded = decodeURI(pathname); } catch { break; } iterations++; } return decoded; ```

Astroフレームワーク全体として、パス名の正規化処理を一元化し、認証ロジックとルーティングロジックが常に**全く同じ、完全に正規化されたパス名表現**を使用するように徹底する必要があります。`context.url.pathname`がミドルウェアに渡される時点で、すでに最終的な正規化済みパスであるべきです。

フレームワークレベルでの修正が適用されるまでの間は、開発者はミドルウェアで`decodeURI()`を複数回適用するなどして、可能な限りパス名を正規化してから認証判断を行うことで、暫定的にリスクを軽減できる可能性があります（ただし、根本的な解決はフレームワーク側の修正が必要です）。

**注意:** 開発者自身がミドルウェア内で過度に複雑なパス名正規化ロジックを実装することは、新たな脆弱性の温床になる可能性もあるため、基本的にはフレームワークの公式な修正を待つのが最善です。

まとめ

今回のAstroの認証バイパス脆弱性(GHSA-vj59-8hwv-xxmv / CVE-2026-59731)は、URLデコードのイテレーション制限と、ミドルウェア・ルーティング間でのパス名正規化の不一致によって引き起こされるものです。これにより、特定の条件下で保護されたルートへの不正アクセスが可能となり、アプリケーションのセキュリティが脅かされます。

Astroを利用しているフロントエンドエンジニアの皆さんは、ご自身のアプリケーションが影響を受ける可能性があるかを確認し、速やかにフレームワークの更新を適用するか、上記の推奨事項を参考に暫定的な対策を検討してください。最新のセキュリティ情報を常にチェックし、安全な開発を心がけましょう。