Sentryの脆弱性CVE-2026-114139とは：@sentry/nextjsの対象版・確認コマンド・修正手順

エラー監視サービスSentryのNext.js用SDK「@sentry/nextjs」に、ミドルウェアでの認可を素通りされる脆弱性CVE-2026-114139が見つかりました。GitHub Advisory Databaseは2026年10月22日に深刻度Critical（CVSS v4.0で9.1）として掲載しています。影響を受けるのは、tunnelRouteを設定し、webpackでビルドし、認可をミドルウェアだけで行っているアプリです。本記事では、対象になる4条件と修正版、自社のアプリが当てはまるかを確かめるコマンド、更新できない間の回避策を実装者の目線で整理します。あわせて確認するのは、セルフホスト版のSentry本体で2026年に続いたSAML SSOの脆弱性です。記載内容は2026年10月27日時点の公開情報にもとづきます。

まとめ：@sentry/nextjsは修正版へ上げ、認可はミドルウェア以外にも置く

修正版は9系が9.47.2、10系が10.75.2、11系が11.0.0-rc.1です。設定の変更は不要で、版を上げればミドルウェアを飛ばす範囲がトンネル本来のリクエストだけに狭まります。2026年10月27日時点のnpmの最新は11.9.0、10系の最新は10.77.1でした。

対象の4条件は全部そろったときだけ成立します。とはいえ、条件の1つ「ルートの直下に[locale]のような動的セグメントがある」構成は多言語サイトで珍しくありません。ここに当てはまると、トンネルのパスを変えても衝突は避けられないため、更新を先に済ませてください。

根本の対策は、認可をミドルウェアに頼り切らないことです。Next.jsのミドルウェアの迂回は2025年のCVE-2025-29927に続く2件目で、ページやデータ取得の層でもセッションを確かめていれば、どちらの脆弱性でも被害は出ませんでした。Sentryのクラウド版や組織内のデータは影響を受けないとSentry社は説明しています。

2026年に公表されたSentryの脆弱性をSDK側と本体側に分けた全体像

「Sentryの脆弱性」には、アプリに組み込むSDKの脆弱性と、Sentryのサーバー本体（セルフホスト版）の脆弱性の2系統があります。対応する担当も手順も異なるため、最初にどちらの話かを切り分けます。

CVE-2026-114139でtunnelRoute配下のミドルウェアが動かない4条件

tunnelRouteは、ブラウザからSentryへ送るイベントを自社のNext.jsサーバーのパス（例：/monitoring）経由で送り、広告ブロッカーに止められないようにするオプションです。届いたリクエストはNext.jsのリライトでSentryへ転送されます。SDKは、この転送用のリクエストが利用者側のミドルウェアで弾かれないよう、ミドルウェアを飛ばす処理を入れていました。

問題は、飛ばす範囲がリライトの範囲より広かったことです。Sentry社のアドバイザリによると、リライトが受けるのはトンネルのパスそのものにoとpのパラメータが付いたリクエストだけでした。一方でミドルウェアの省略はトンネルのパス配下すべてに効いており、その差分のリクエストはSentryではなくアプリ側のルートへ届き、ミドルウェアを通らずに処理されます。影響を受けるのは、次の4条件がすべてそろう場合です。

1. tunnelRouteを文字列のパスかtrueで設定している
2. webpackでビルドしている（Turbopackでのビルドは対象外）
3. アプリのルートがトンネルのパス配下に解決される（/monitoring/fooのような直接の衝突、またはルート直下のapp/[locale]/のような動的セグメント）
4. そのルートの認可をミドルウェアだけで行っている

ミドルウェアを飛ばしても権限が与えられるわけではなく、サーバー側でセッションを確かめているルートは守られたままです。GitHubの評価はCVSS v4.0で9.1（攻撃条件の前提あり・権限不要・機密性と完全性に高い影響）ですが、Sentry社のリポジトリ側の深刻度はmediumです。実際の重さは4条件がそろうかどうかで大きく変わるため、条件とあわせて評価を読み取ります。悪用の報告はアドバイザリに記載がありません。

SDKの過去の脆弱性CVE-2023-46729とCVE-2025-65944の対象版

tunnelRouteが絡む脆弱性は今回が初めてではありません。2023年のCVE-2023-46729は、トンネルの入力が検証されず任意のURLへリクエストを送れるSSRFで、@sentry/nextjsの7.26.0以上7.77.0未満が対象でした。

2025年11月のCVE-2025-65944は性質が違います。Node.js系SDKの10.11.0〜10.26.0でsendDefaultPii: trueを設定していると、AuthorizationやCookieのヘッダがトレースの属性としてSentryへ送られていました。修正は10.27.0です。該当期間にこの設定で運用していたなら、SentryのExplore → Tracesでhttp.request.header.authorizationを探し、送られた値の有無を確かめるよう同アドバイザリは案内しています。認証情報が外部に渡っていた場合の社内報告の要否は、個人情報保護委員会への報告義務の整理とあわせて判断してください。

セルフホスト版Sentry本体のSAML SSOと移転機能の修正版

Sentry本体（getsentry/sentry）では、2026年にSAML SSOの認証の不備が繰り返し公表されました。直近のGHSA-88p9-44cg-fr2q（2026年10月19日公表・CVSS v3.1で8.1）は、ドットの無いi（ı）を使った似せたドメインのメールで、他人のアカウントを乗っ取れるものです。クラウド版は10月14日に修正済みで、セルフホスト版は26.10.0以上への更新が推奨されています。

SAML系の多くは、SENTRY_SINGLE_ORGANIZATIONをTrueにした単一組織の運用なら条件を満たしません。CVE-2026-83803も移転機能が既定で無効のため、初期設定のままなら対象外です。一方、CVE-2026-52794は公開されたDSNに細工したイベントを送るだけで取り込みが遅くなるため、DSNがブラウザに出ている構成では設定による逃げ道がありません。セルフホストは26.10.0へ上げるのが確実です。

Ivanti Sentryとエラー監視のSentryを取り違えない見分け方

「Sentry 脆弱性」の検索結果には、モバイル端末の通信を中継するゲートウェイ製品Ivanti Sentry（旧MobileIron Sentry）の情報が多く混ざります。別会社の別製品で、本記事で扱うエラー監視のSentryとは関係がありません。

見分けは、パッケージ名か配布元で行います。@sentry/で始まるnpmパッケージ、sentry-sdk（Python）、getsentry/のGitHubリポジトリ、sentry.ioのDSNが出てくれば、エラー監視のSentryです。社内の資産台帳に「Sentry」とだけ書かれている場合は、ゲートウェイ機器なのかSaaSの契約なのかを先に確かめてください。Sentryそのものの機能や料金はSentryとは？エラー監視ツールの意味・料金プランと無料枠・導入手順で解説しています。

自社のNext.jsアプリが対象かをnpmとnext.configで確かめる手順

4条件のうち、版・tunnelRoute・ビルドツール・ルートの衝突は、本番サーバーに入らなくてもリポジトリだけで判定できます。上から順に確かめ、1つでも外れた時点で「対象外」と記録して構いません。

npm lsとpnpm whyで@sentry/nextjsの実際の版を読み取る手順

package.jsonの"^10.20.0"のような指定は範囲であり、実際に入っている版ではありません。ロックファイルが解決した版をコマンドで読み取ります。

# 実際に入っている版（モノレポでは全ワークスペースを表示）
npm ls @sentry/nextjs --all

# pnpm の場合
pnpm why @sentry/nextjs

# 公開中の版の系列ごとの最新を確かめる
npm view @sentry/nextjs dist-tags

判定の基準はGitHub Advisory Databaseの範囲で、9.36.0以上9.47.2未満、10.0.0-alpha.0以上10.75.2未満、11.0.0-alpha.0以上11.0.0-rc.1未満が対象です。9.36.0より前の9系と8系以前は、この脆弱性の範囲に含まれていません。GitHub Advisory Databaseへの掲載は10月22日なので、DependabotやRenovateを使っている場合は、それ以降にアラートや更新のプルリクエストが出ていないかもあわせて確認してください。

tunnelRoute設定とwebpackビルドの具体的な判定方法

次に、1つ目と2つ目の条件を設定ファイルで確かめます。next.configのtunnelRoute設定と、next buildがwebpackを使うかどうかを分けて確認する手順です。

# tunnelRoute の有無と値、webpack を明示しているかを探す
grep -nE "tunnelRoute|--webpack|--turbopack|--turbo" \
  next.config.* package.json

# Next.js の版（16 以上なら next build の既定は Turbopack）
npm ls next

tunnelRouteが出てこなければ対象外です。出てきた場合は、ビルドツールを判定します。Next.js 16の告知のとおり、16以上ではnext buildの既定がTurbopackで、next build --webpackと書いたときだけwebpackになります。15以前は既定がwebpackで、--turbopackを付けたときだけTurbopackです。Next.js自体の版の追い方はNext.js 16の最新バージョンとセキュリティ修正版にまとめています。CIのビルドコマンドとローカルのコマンドが違うことがあるため、判定は本番を作るCIの定義で行ってください。

トンネルのパス配下と[locale]動的セグメントのルートを洗い出す

3つ目の条件は、トンネルのパス配下にアプリのルートがあるかです。tunnelRoute: trueの場合は、ビルドごとに予測できないパスが生成されるため、直接の衝突はほぼ起きません。ただし、ルート直下の動的セグメントはどんな先頭パスにも一致するので、trueでも条件を満たします。

# tunnelRoute が "/monitoring" の場合：同名のディレクトリがあるか
find app src/app -maxdepth 1 -name "monitoring" 2>/dev/null

# ルート直下の動的セグメント（[locale] や [slug] など）があるか
find app src/app -maxdepth 1 -type d -name "[[]*" 2>/dev/null

2つ目のコマンドで[locale]や[[...slug]]が出たら、条件3は成立しています。ルートグループ(marketing)のような括弧のディレクトリはURLに現れないので、その中も1階層だけ見てください。App Routerのファイル規約と動的セグメントの解決順はApp Routerとは？ファイル規約・動的ルーティングで確認できます。最後に、該当したルートの認可がミドルウェア（middleware.tsまたはproxy.ts）にしか書かれていないかを見れば、判定は終わりです。

修正版9.47.2・10.75.2への更新と更新できない間の回避策の実装

対象と判定したら、更新を第一の手段にします。更新までに日数がかかる場合だけ、回避策で穴をふさぎます。

系列ごとの修正版と11系の最新11.9.0へ移るかの実務上の判断

同じメジャー系列の中で上げるのが、最も影響の小さい更新です。10系なら10.75.2以上、9系なら9.47.2以上を入れます。

# 10 系のまま上げる（10.75.2 以上の最新を入れる）
npm install @sentry/nextjs@^10.75.2

# 9 系のまま上げる
npm install @sentry/nextjs@^9.47.2

# 入った版を確かめる
npm ls @sentry/nextjs

10.75.2のリリースは2026年9月22日、9.47.2は9月29日にnpmへ公開されました。修正の中身は10系の修正プルリクエストのとおり、ミドルウェアを飛ばす判定をリライトの判定とそろえたものです。11系への移行は、メジャー更新の破壊的変更を読む工程が増えるため、脆弱性対応とは分けて計画するのが安全です。

tunnelRouteを衝突しないパスへ移すかHandlerモードへ切り替える

すぐに更新できない場合の回避策は、tunnelRouteをアプリのどのルートとも重ならないパスへ移すか、オプションを外すかです。

// next.config.mjs
import { withSentryConfig } from "@sentry/nextjs";

const nextConfig = {};

export default withSentryConfig(nextConfig, {
  org: "example-org",
  project: "example-project",
  // アプリのどのディレクトリとも重ならない固定パスにする
  tunnelRoute: "/sentry-tunnel-7f3a",
});

この回避策は、ルート直下に[locale]などの動的セグメントがあるアプリでは効きません。どのパスを選んでも動的セグメントに一致するためです。その場合は、tunnelRouteを外すか、ビルドをTurbopackへ切り替えるかを選びます。tunnelRouteを外すと広告ブロッカーを入れた利用者のエラーが届かなくなるので、更新までの一時措置と割り切ってください。

SentryのBuild Options for Next.jsによると、10.77.1と11.9.0以降はアプリ内のルートハンドラがイベントを転送する「Handlerモード」も選べます。この方式ではSDKがミドルウェアを飛ばさないため、ミドルウェアのmatcherでトンネルのパスを除外する設定が必要です。Handlerモードを選べる版はすでに修正を含んでいるので、更新とあわせて検討する選択肢になります。

ミドルウェアだけの認可をデータアクセス層でも確かめるコード例

4つ目の条件を崩す対策は、版やビルドツールに左右されません。Next.jsの認証ガイドは、ミドルウェア（Next.js 16ではProxy）での確認をCookieだけを見る楽観的なチェックと位置づけ、主な確認はデータに近い層で行うよう求めています。次は、そのガイドの形に沿ってセッションを確かめる関数を置く例です。

// app/lib/dal.ts
import "server-only";
import { cache } from "react";
import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { decrypt } from "@/app/lib/session";

export const verifySession = cache(async () => {
  const cookie = (await cookies()).get("session")?.value;
  const session = await decrypt(cookie);
  if (!session?.userId) {
    redirect("/login");
  }
  return { userId: session.userId };
});

// app/[locale]/dashboard/page.tsx
// ミドルウェアを通らなくても、ここで必ずセッションを確かめる
// const { userId } = await verifySession();

保護したいページ、Server Action、Route Handlerの先頭でverifySession()を呼べば、ミドルウェアが飛ばされても未ログインの要求はログイン画面へ戻されます。レイアウトでの確認は画面遷移で再実行されないため、この役目には使えません。APIの認可やトークン失効の設計全般はAPI不正アクセス対策の実装手順で詳しく扱っています。

ミドルウェアに認可を集める既存設計を残すか作り直すかの判断基準

今回の脆弱性は、SDKの不具合であると同時に、ミドルウェアへ認可を寄せる設計の弱さを示しています。更新で終わらせてよい構成と、認可の置き場所まで直すべき構成を分けて判断します。

CVE-2025-29927に続く2件目のミドルウェア迂回が示す設計の弱点

2025年3月のCVE-2025-29927（Next.jsミドルウェア認可バイパス）は、細工したヘッダ1つでミドルウェアを飛ばせる不具合でした。今回は原因がSDK側と異なるものの、「ミドルウェアが実行されない経路がある」という結果は同じです。

ミドルウェアは、フレームワーク本体・ライブラリ・ホスティングの設定のどれかが変わるだけで、実行されない経路が生まれます。matcherの正規表現の書き損じでも同じことが起きます。1年半で2件という頻度を見ると、ミドルウェアは「通れば早く弾ける入口」であって、唯一の守りにはしない、と決めておくのが実務的です。

更新だけで済ませてよい構成と認可の作り直しが必要な構成の判断基準

更新だけで済ませてよいのは、ページとデータ取得の層ですでにセッションを確かめていて、ミドルウェアはリダイレクトの振り分けにしか使っていない構成です。この場合、今回の脆弱性で読める情報も変えられる情報もありません。版を上げ、判定の記録を残せば対応は完了です。

作り直しまで進めるべきなのは、管理画面や会員ページの保護をミドルウェアのmatcherだけで行っている構成です。今回の4条件に当てはまらなくても、次の迂回の不具合でそのまま露出します。認可の確認をverifySession()のような共通関数へ集め、ページ・Server Action・Route Handlerの全入口で呼ぶ形へ移してください。入口の数が多く、どこで認可しているかを社内で把握できていない場合は、外部の診断で抜けを洗い出すほうが早く終わります。一創の脆弱性診断・セキュリティ診断では、Next.jsアプリの認可の置き場所を含めて点検しています。

Sentryを入れる際は、エラー報告そのものも攻撃の入口になります。偽のエラーでAIコーディングエージェントを操る手口はAgentjackingとはで解説しています。

Sentryの脆弱性CVE-2026-114139対応でよく受ける質問と回答

CVE-2026-114139とSentry本体の脆弱性について、対応の現場で出やすい疑問をまとめました。

Sentryのクラウド版（sentry.io）の利用者も対応が必要ですか？

CVE-2026-114139はアプリに組み込むSDKの問題なので、クラウド版を使っていてもSDKの更新は必要です。Sentry社はSentry側のサービスと組織内のデータは影響を受けないと説明しています。一方、Sentry本体のSAML SSOの脆弱性は、クラウド版ではSentry社が修正を適用済みで、利用者の作業は不要です。セルフホスト版を運用している場合だけ、本体の更新が必要になります。

@sentry/reactや@sentry/nodeだけを使う構成は対象ですか？

CVE-2026-114139の対象パッケージは@sentry/nextjsだけです。tunnelRouteはNext.js向けSDKの機能で、ReactやNode.jsのSDK単体には存在しません。ただし、Node.js系SDKの10.11.0〜10.26.0には、sendDefaultPii: trueでAuthorizationやCookieのヘッダが送られていたCVE-2025-65944があります。この範囲の版を使っていた場合は、10.27.0以上へ上げたうえで送信済みの値を確認してください。

Vercelでデプロイしていれば対象外になりますか？

ホスティング先では決まりません。判定に効くのはビルドツールで、Vercel上でもnext build --webpackでビルドしていれば条件2を満たします。Next.js 15以前は既定がwebpackなので、特別な設定をしていなくても該当しやすい点に注意してください。判定はプレビュー環境と本番環境で別々に行い、本番を作るビルドの設定を正とします。

悪用は確認されていますか？更新はどのくらい急ぐべきですか？

2026年10月27日時点で、Sentry社とGitHubのアドバイザリに悪用の記載はありません。急ぐかどうかは4条件で決まります。4条件がすべてそろうアプリは、認証なしで保護ページに届く状態なので、当日中の更新か回避策を勧めます。tunnelRouteを使っていない、またはページ側でもセッションを確かめているアプリは、通常の依存更新の周期で上げれば十分です。

修正後にトンネルのパス配下のルートはどう動きますか？

修正版では、ミドルウェアを飛ばす対象が、リライトが実際に受けるリクエスト（トンネルのパスそのものにoとpのパラメータが付いたもの）だけに狭まりました。それ以外のパス配下のリクエストは通常どおりミドルウェアを通ります。設定の変更は不要で、Sentryへのイベント送信もそのまま続きます。更新後は、保護対象のページへ未ログインでアクセスし、ログイン画面へ戻されることを確かめてください。

関連記事

• Sentryとは？エラー監視ツールの意味・料金プランと無料枠・導入手順【2026年10月】：Sentryの機能・料金・導入の基本を確認できます。
• Sentry OpenTelemetry連携の3経路｜OTLP直送とSDK併用の判断：SDKの構成を見直す際に、計装の選択肢を比べられます。
• CVE-2025-29927とは？Next.jsミドルウェア認可バイパスの影響範囲・修正版・検知方法：同じくミドルウェアを迂回された先行例です。
• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：CVSSの読み方と修正までの流れの基礎です。
• CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方：GHSAとCVEの番号の対応を確かめるときに役立ちます。