Fastify向けプラグイン「middie」に認証をすり抜けられる脆弱性 CVE-2026-14198、細工したURLで保護機能を回避、9.3.3へ更新を

Node.js（サーバー側でJavaScriptを動かす仕組み）向けの高速Webフレームワーク「Fastify」でよく使われるプラグイン「@fastify/middie」に、細工したURLを送るだけで認証などの保護機能をすり抜けられる脆弱性が見つかりました。管理番号はCVE-2026-14198、危険度は10点満点中9.1点（重要度「緊急」）です。

攻撃にはログインが一切不要で、URLの一部に「スラッシュを記号化した文字（%2F）」を紛れ込ませるだけで、本来は認証やアクセス制限を通らないと見られないはずのページに到達できてしまいます。middieは週に約47万回ダウンロードされている人気プラグインで、開発元は2026年6月30日に修正版「9.3.3」を公開しました。9.1.0から9.3.2を使っているアプリは、今すぐ更新が必要です。

誰が、何のために狙うのか

狙うのはFastify製のWebサービスやAPIに外部から接続できる不特定多数の攻撃者です。ログイン情報も特別な権限も要らず、インターネットからアクセスできれば誰でも試せてしまう点が、この脆弱性のやっかいなところです。

攻撃者ができるのは、URLにスラッシュの記号（%2F）を1文字仕込むだけで、認証・権限チェック・アクセス回数制限といった「門番」の役割をすり抜け、本来は保護されているはずの機能に直接触れることです。ログイン画面や権限の壁を突破された状態と同じになります。

被害の中身は、そのアプリが門番の裏で何を守っていたかによって変わります。管理者向けの操作画面、他人の個人情報を扱うAPI、課金や設定変更の処理などが門番だけで守られていた場合、それらに認証なしで到達される恐れがあります。サービスを使う一般利用者にとっては個人情報の流出につながり、運営する企業にとってはデータの改ざんや不正操作の起点になり得ます。だからこそ、後述する更新を最優先で進める必要があります。

Fastifyとmiddieとは何か

Fastifyは、Node.jsでWebサーバーやAPIを作るためのフレームワーク（土台となる部品群）です。処理が速く負荷が軽いことで知られ、多くの企業のサービスで採用されています。

今回の主役である「middie」は、そのFastifyに「ミドルウェア」という仕組みを追加するプラグインです。ミドルウェアとは、リクエスト（利用者からの要求）が実際の処理に届く前に通す「中間の関所」のようなもので、認証、権限の確認、アクセス回数の制限、記録（監査ログ）などをまとめて担わせる使い方が一般的です。Fastifyはバージョン3以降、この仕組みを標準では持たず、middieのような外部プラグインで補う設計になっています。middieは週に約47万回ダウンロードされ、Fastify公式が提供する定番プラグインの一つです。

つまりmiddieは、多くのFastify製アプリで「誰を通し、誰を止めるか」を判断する門番の役割を担っています。その門番が素通りしてしまうのが、今回の脆弱性です。

何が起きるのか、脆弱性の中身

原因は、URLの中の文字の読み方が、middieとFastify本体で食い違っていた点にあります。開発元の脆弱性情報（GitHub Security Advisory）によると、middieは門番の判定をするとき、URLに含まれる「%2F」という記号を先にスラッシュ（/）に読み替えてから経路を照合します。一方、Fastify本体のルーター（リクエストを実際の処理へ振り分ける部分）は、%2Fを記号のまま保持して照合します。この読み方のズレが穴になりました。

具体例を挙げます。次のように「特定の利用者のコメント」を扱う経路に、認証ミドルウェアを設定していたとします。

app.use('/user/:id/comments', authMiddleware)

ここに攻撃者が /user/a%2Fb/comments というURLでアクセスします。すると、middie側は%2Fをスラッシュに読み替えるため「これは登録済みの経路とは違う」と判断し、認証ミドルウェアを動かしません。ところがFastify本体のルーターは%2Fをそのまま扱うため、この要求を正しく /user/:id/comments の処理へ振り分けてしまいます。結果として、門番を通らないまま、保護されているはずの処理だけが実行される——これが認可バイパス（本来必要な許可を経ずにアクセスできてしまう欠陥）の正体です。

危険なのは、この穴が認証だけでなく、middieに任せていた保護のすべてに効いてしまう点です。開発元は影響範囲として、認証・権限確認・アクセス回数制限・監査ログの4つを挙げています。門番役をmiddieにまとめていたアプリほど、影響は広がります。

どれくらい危険なのか、前提条件を正しく読む

危険度はCVSS 9.1で「緊急」に分類されます。ログイン不要（無認証）で外部から悪用できるため、数字が高いのは妥当です。ただし、すべてのFastifyアプリが一律に危ないわけではなく、条件を正確に押さえておく必要があります。

この脆弱性が刺さるのは、「/user/:id/comments」のようにパラメータ（可変部分）を含む経路に、middieで認証などのセキュリティ判断を行うミドルウェアを設定している構成です。逆に、セキュリティの判断をmiddieのパス指定に頼らず、後述するFastifyの仕組みやハンドラ（実際の処理）側で行っているアプリは、この経路では影響を受けにくくなります。「middieを入れている＝即アウト」ではなく、「middieに門番を任せる設計かどうか」で切迫度が変わる、と読むのが正確です。

とはいえ、パス指定のミドルウェアで認証をかける書き方はExpress（もう一つの定番フレームワーク）から続く広く使われている作法で、middieはそのExpress風の書き方を再現するためのプラグインです。つまりこの構成を採っているアプリは決して珍しくありません。自分のアプリがどちらかを、更新と合わせて必ず確認してください。

自分のアプリは危ないか、バージョン別の早見表

まず npm ls @fastify/middie などでバージョンを確認してください。以下の早見表で状況を判断できます。

9.1.0より前は今回のCVE-2026-14198の対象外ですが、後述するとおりmiddieには別系統の門番すり抜け欠陥が過去に複数あります。古い版を使い続けているなら、いずれにせよ最新版への更新が安全です。

技術者の視点、middieは「パス解釈のズレ」で門番すり抜けを繰り返している

ここが今回いちばん伝えたい点です。CVE-2026-14198は単発の事故ではありません。middieは「ミドルウェア層とルーター層でパスの読み方が食い違う」という同じ根っこの欠陥から、門番すり抜けを繰り返し修正し続けています。時系列で並べると、その反復ぶりがはっきり見えます。

きっかけはそれぞれ違いますが、行き着く結果はどれも「門番であるミドルウェアが動かないのに、処理だけが実行される」で共通しています。なぜ繰り返すのか。エンジニアの目で見ると、これは個々のバグというよりアーキテクチャの構造的な弱さです。middieは「どのURLで門番を動かすか」を自前でパスを解釈して判定しますが、実際の振り分けはFastify本体のルーターが別の解釈で行います。同じURLを二つの部品が別々に解釈する限り、そのわずかな差（末尾スラッシュ、重複スラッシュ、記号化文字など）を突く新手のすり抜けは、これからも形を変えて出てくる可能性があります。

実務的な教訓は明確です。認証や権限のようなセキュリティ判断を、パス指定のミドルウェアに委ねる設計そのものを見直すのが根本策になります。開発元も回避策として、認証はハンドラ（実際の処理）側、またはFastify標準の preHandler フックで行うことを推奨しています。フックはFastifyのルーターと同じ解釈でリクエストを扱うため、今回のような層をまたぐズレが生まれません。今回の修正はMatteo Collina氏（Fastifyの共同開発者）が担当し、Jvr2022氏の報告を受けたものです。npmの依存関係を狙う攻撃全般の傾向は、OSSサプライチェーンの脅威まとめでも整理しています。ライブラリの認証・認可の落とし穴は、多言語化ライブラリi18nextの脆弱性や通信ライブラリaxiosの脆弱性でも繰り返し問題になってきました。

悪用は確認されているのか

現時点で、この脆弱性が実際の攻撃に使われたという報告は確認されていません。米政府のサイバーセキュリティ機関CISAが公開する「実際に攻撃されている脆弱性リスト（KEV）」にも、CVE-2026-14198は登録されていません。

ただし、攻撃手法は「URLに%2Fを1文字入れる」だけと極めて単純で、修正内容も公開されています。修正版が出た直後は、その差分を分析した攻撃が始まりやすい時期でもあります。「まだ攻撃されていない」ことは「更新しなくてよい」理由にはなりません。

いま何をすべきか

最優先は、@fastify/middieを修正版9.3.3以降へ更新することです。npm install @fastify/middie@latest などで更新し、依存関係の固定ファイル（package-lock.json等）も合わせて反映してください。

すぐに更新できない場合や、より堅牢にしたい場合は、開発元が示す回避策が有効です。認証や権限の判断を、パス指定のミドルウェアではなく、各処理（ハンドラ）の中か、Fastify標準の preHandler フックで行うように設計を変えてください。フックはFastifyのルーターと同じ解釈でURLを扱うため、今回のような食い違いが起きません。あわせて、セキュリティの判断にパラメータ付きのミドルウェアパスを使っている箇所がないか、コード全体を点検しておくと安全です。

まとめ

CVE-2026-14198は、Fastify向けの定番プラグインmiddieで、URLに記号化したスラッシュ（%2F）を1文字仕込むだけで、認証などの保護機能をログイン不要ですり抜けられる脆弱性です。危険度はCVSS 9.1と高く、パラメータ付きの経路にmiddieで門番を置いているアプリが対象になります。

見逃せないのは、middieが「ミドルウェア層とルーター層のパス解釈のズレ」という同じ根っこの欠陥で、門番すり抜けを繰り返してきた点です。今回の更新で終わりにするのではなく、セキュリティ判断はハンドラやpreHandlerフックに寄せる設計へ切り替えることを強くおすすめします。まずは自分のアプリのmiddieが9.3.3以降になっているか、今すぐ確認してください。

参照元

• ▸NVD - CVE-2026-14198 Detail（米国立標準技術研究所）
• ▸GitHub Security Advisory - GHSA-2v46-jxjm-7q3v（開発元の一次情報）
• ▸@fastify/middie - npm（ダウンロード数・バージョン）
• ▸fastify/middie - Releases（9.3.3 修正版）
• ▸SentinelOne - CVE-2026-2880（middie 過去の門番すり抜け）
• ▸Fastify 公式ドキュメント - Middleware