Astroのbase設定でログイン保護が外れる件 — Node・Netlifyの修正も

社内向けの予約管理や会員ページをAstroのオンデマンドレンダリング（SSR）で作り、/app のようなサブパスに置いて、ミドルウェアで「/app/admin で始まるURLはログイン必須」と判定している。自然な書き方ですが、Astro 7.2.3以前では、/appX/admin のようにbaseの直後に1文字足したURLでこの判定をすり抜け、保護したはずの管理ページが表示されることがありました。同じ時期に、Nodeアダプターでは不正なHostヘッダーでサーバーが落ちる問題、Netlifyアダプターでは画像の許可リストが効かない問題も修正されています。

どの修正が自分のサイトに関係するのかを、勧告と修正コミットで確かめ、編集部の検証環境で修正前後の応答を比べました。対象かどうかの確かめ方と、更新するときに引っかかりやすい点を整理します。

2026年9月に公開されたAstro関連の勧告

GitHubのレビュー済みの勧告に、Astroのパッケージを対象とするものが2026年9月に4件登録されています。このうちAVIF画像の最適化に関する件（GHSA-26w7-cxv4-gfx2、astro 7.2.8で修正）はsharpのAVIF脆弱性を確かめる記事で扱ったため、ここでは残りの3件を扱います。

勧告の公開日は、baseの件が9月8日、残りの2件が9月30日（いずれもUTC）です。修正版は勧告より前に出ており、npmへの公開はastro 7.2.4が8月19日、@astrojs/node 11.1.3が8月18日、@astrojs/netlify 8.2.4が8月24日（UTC）です。2026年10月1日時点の最新版は、astro 7.3.5、@astrojs/node 11.1.6、@astrojs/netlify 8.2.6です。

ビルドしたHTMLを静的ホスティングで配信しているだけのサイト（SSG）は、リクエストのたびにAstroのルーティングやミドルウェアが動く処理を持たないため、この3件の対象になる処理がありません（勧告の影響条件からの編集部の整理）。公式ドキュメントも、事前レンダリングするページのミドルウェアはビルド時に動くと説明しています。なお、AVIFの件は画像の最適化処理が対象で条件が異なるため、SSGのサイトでも上の記事で確認してください。

baseの前方一致で、ルーティングとミドルウェアが別のパスを見ていた

勧告で問題になったのは、次のような判定です。

// src/middleware.js（7.2.3以前で迂回された書き方の例）
export function onRequest(context, next) {
  if (context.url.pathname.startsWith('/app/admin') && !context.cookies.has('session')) {
    return new Response('login required', { status: 401 });
  }
  return next();
}

勧告によると、Astroは設定した base をリクエストのパスから取り除くとき、文字列の前方一致だけを見て、パスの区切り（/）の位置で終わっているかを確かめていませんでした。base: '/app' のとき、/appX/admin も「baseの下にある」とみなされ、内部では /admin のページに振り分けられます。一方、ミドルウェアが見る context.url.pathname は公開されたURLのまま /appX/admin なので、/app/admin で始まるかという判定に当たりません。ルーティングとミドルウェアが、それぞれ別のパスを見ていたわけです。

修正コミット（05763a0）は、baseを取り除く処理を stripRequestBase という関数にまとめ、パスがbaseと一致するか、baseの直後が / のときだけ取り除くように変えています。勧告は修正後について、ルーティングと context.url.pathname が同じパスに解決されると書いています。

公式の認証ガイドには、2026年8月21日の更新で注意書きが加わりました。ミドルウェアが見る公開パスと、Astroが内部で照合するルートは同じになる保証がなく、base、URLエンコード、重複したスラッシュで食い違うことがある。そのため context.url.pathname を文字列で照合して認可せず、ルートを照合するルーターの側でアクセスを制限するように、という内容です。7.2.4で今回の食い違いは直りましたが、この注意書きは修正後のドキュメントにも残っています。

編集部の検証環境で修正前後を比べた

2026年10月1日に、編集部の検証環境（Linux、Node.js v22.22.0、npm 10.9.4）で最小構成のプロジェクトを作って確かめました。output: 'server'、@astrojs/node のstandaloneモード、base: '/app'、上のミドルウェア、src/pages/admin.astro だけの構成です。ビルドしたサーバーをローカルで起動し、Cookieを付けないリクエストの応答コードを記録しました。

• astro 7.2.3（@astrojs/node 11.1.3）。 /app/admin は401でした。/appX/admin、/app2/admin、/app-/admin は200で、管理ページの本文が返りました
• astro 7.2.4（@astrojs/node 11.1.4）と7.3.5（@astrojs/node 11.1.6）。 /app/admin は401のままで、上の3つは404になりました

Nodeアダプターの件も、同じ環境で勧告の例と同じ形の、ポート番号が範囲外のHostヘッダーを付けたリクエストを送って確かめました。

• astro 7.2.2 + @astrojs/node 11.1.2。 オンデマンドのページでは500を返し、サーバーは動き続けました。staticHeaders: true にしてCSPを有効にした事前レンダリングのページへ送ると、プロセスが TypeError: Invalid URL で終了し、その後の通常のリクエストにも応答しなくなりました
• astro 7.2.3 + @astrojs/node 11.1.3、astro 7.3.5 + @astrojs/node 11.1.6。 どの構成でも200を返し、サーバーは動き続けました

いずれも各条件1回ずつの、手元の隔離した環境での結果です。baseの件の修正はastro本体の処理に入っていますが、Netlify・Vercel・Cloudflareなど他のアダプターでの動作は確かめていません。

自分のサイトが該当するかを確かめる

1. 入っている版を見る。 プロジェクトで npm ls astro @astrojs/node @astrojs/netlify を実行します。astro 7.2.4以上、@astrojs/node 11.1.3以上、@astrojs/netlify 8.2.4以上なら、3件とも修正済みです。AVIFの件まで含めるなら、astroは7.2.8以上にします。
2. baseの件の条件を見る。 astro.config.mjs の base が / 以外か、オンデマンドレンダリングのページがあるか、ミドルウェアで context.url.pathname を startsWith や === で比べて認可していないかを確かめます。3つがそろう構成は、勧告の対象です。
3. Nodeアダプターの件の条件を見る。 アダプターの設定に staticHeaders: true があるか、Node.jsのサーバーの前段でHostヘッダーを検査するリバースプロキシやCDNがあるかを確かめます。勧告は、不正なHostヘッダーをリバースプロキシやCDNで止めている構成には、この経路が届かないと書いています。
4. Netlifyの件は、生成された設定を見る。 ビルド後の .netlify/v1/config.json の images.remote_images に、許可する画像URLの正規表現が書き出されます。編集部の検証では、8.2.3は https?://images\.example\.com/.* のように先頭の ^ がなく、8.2.4は ^https?://images\.example\.com/.*$ と両端が固定されていました。すぐ上げられない場合の回避策として、勧告は imageCDN: false にするか、リモート画像の許可リストを外すことを挙げています。

更新するときの落とし穴

astroと@astrojs/nodeは一緒に上げる。 Hostヘッダーの修正コミット（2066f39）は、変更履歴ではastro 7.2.3の項目に載っており、勧告は修正版を@astrojs/node 11.1.3としています。2つの版は同じ日に公開されました。編集部の検証では、片方だけを上げた組み合わせ（astro 7.2.3 + @astrojs/node 11.1.2、astro 7.2.2 + @astrojs/node 11.1.3）は、どちらもサーバーの起動時に TypeError で終了しました。@astrojs/node 11.1.2はastroの版を ^7.0.0 としか指定していないため、npmはこの組み合わせを止めません。

npm auditの表示だけで判断しない。 2026年10月1日（UTC 0時台）に、修正前の版を入れたプロジェクトで npm audit を実行したところ、astroの2件（baseとAVIF）は表示されましたが、9月30日に公開された@astrojs/nodeと@astrojs/netlifyの件は表示されませんでした。公開直後の勧告は、手順1のように版を直接確かめるほうが確実です。

ミドルウェアの書き方も見直す。 版を上げれば今回の食い違いは解消しますが、公式ガイドはパスの文字列照合による認可そのものを避けるよう求めています。ここからは編集部の提案です。

• 公式ガイドが例示するように、src/fetch.ts でルーター（ガイドの例はHono）を使い、保護するルートをルーターの側で指定する。baseを設定した構成での書き方は、編集部では検証していません
• 保護したいページ自身の先頭でもセッションを確かめる。ミドルウェアの判定がどのURLで外れても、ページの側で止まるようにする二重の確認です

引き継いだAstroのサイトは、Astro 7.0へ上げるか作り直すかの判断で整理した版の上げ方とあわせて、ミドルウェアやアダプターを使う構成かを先に把握しておくと、勧告が出たときにすぐ判断できます。7系のマイナー版の中でURLの扱いが直った例としては、i18nのfallback URLが壊れる不具合も7.3.0で修正されています。

2026年10月1日に、GitHubのアドバイザリデータベース（github/advisory-database）に収録された3件の勧告本文、withastro/astroの変更履歴（astro・@astrojs/node・@astrojs/netlify）と修正コミット3件、withastro/docsの認証ガイドとミドルウェアのガイド、npmレジストリの公開日時を直接開いて照合しました。github.comの勧告ページそのものは環境から開けなかったため、同じ本文を収録したデータベースのファイルを根拠にしています。実機の確認は編集部の検証環境（Linux、Node.js v22.22.0）でのローカルのビルドと起動に限られ、本番環境、Netlify上での画像変換、Node以外のアダプター、astro dev での挙動は確かめていません。

Astroで作ったサイトの保守や、ログイン付きのページを含むWebサイトの改修は、グリームハブへご相談ください。

Sources

• GHSA-376h-93r7-7g6f: Authorization bypass from missing path-segment boundary check when stripping the configured base — withastro/astro
• GHSA-qh8j-hqjv-7m4x: Malformed port in the Host header can crash the Node adapter — withastro/astro
• GHSA-4233-jc72-56c5: Netlify Image CDN allowlist bypass enables SSRF — withastro/astro
• Respect path-segment boundaries when stripping the configured base (#17701) — 修正コミット 05763a0
• Fix crash on malformed port in Host header (#17572) — 修正コミット 2066f39
• Fix generated Netlify image config URLs (#17752) — 修正コミット e362d4c
• astro CHANGELOG (7.2.3, 7.2.4)
• @astrojs/node CHANGELOG
• @astrojs/netlify CHANGELOG
• Authentication — Astro Docs
• Middleware — Astro Docs