GHSA-2464-fhr4-w9xw（CVE-2026-96889）：Next.js画像最適化における認証不要のRCE

要点

VercelはGHSA-2464-fhr4-w9xwをクリティカル（CVSS v4.0 9.5）と評価しています。glibcベースのLinux上でSVGを最適化するNext.jsサーバーでは、未認証の攻撃者がコードを実行できます。Next.js 16.4.1または15.5.28にアップグレードしてください。

• Next.js組み込みのImage Optimization API（/_next/image）は、攻撃者が指定した画像バイト列をsharpに渡します。そのビルド済みlibvipsバイナリには、標準SVGレンダラーのlibrsvgが組み込まれています。RUSTSEC-2026-0305によれば、影響を受けるlibrsvgビルドは修正版より前のすべてのリリースです。メインブランチでは2.63.2未満、安定版系列ではバックポートの2.62.4、2.61.5、2.60.3、2.57.5未満が該当します。これらのバージョンはlibxml2がまだ使用中のXMLエンティティを解放します。この解放済みメモリ使用はCVE-2026-96889として公開されています。
• glibcベースのLinuxシステムで稼働し、SVGファイルがオプティマイザーに到達できる場合、10.0.0～15.5.27および16.0.0～16.4.0のすべてのNext.jsリリースが影響を受けます。Vercelはlibrsvgのバグについて公開された概念実証が存在すると確認しています。
• 2026年10月23日時点で実環境での悪用は確認されておらず、この問題はCISAのKnown Exploited Vulnerabilitiesカタログにも登録されていません。
• Next.js 16.4.1、または15.x系列なら15.5.28にアップグレードしてください。Node.js 20.9.0以降では、新規インストールでsharp 0.35.5（librsvg 2.63.2）が解決されます。15.xではアップグレード後にnpm ls sharpを実行し、0.34.xビルドが残っていればsharp@0.35.5をインストールしてください。Vercelのアドバイザリが示す回避策は1つで、sharpが0.35.5以降に解決されるようにすることです。

影響を受けますか？

npmでは2026年10月16～22日の1週間にnextのダウンロードが44,586,009回記録されました。以下の2分間の確認を実行してください。

次の条件をすべて満たす場合、影響を受けます。

• Next.jsが影響対象の範囲のバージョンで稼働している。
• サーバーがglibcベースのLinuxシステムで稼働している。これはNodeデプロイメントで一般的です。
• sharpが、同梱librsvgにパッチが適用されていないビルドに解決される。各ビルドの対応は以下のsharpとlibrsvgの表で確認できます。
• SVGコンテンツがImage Optimization APIに到達できる。

Next.js 15.0.0以降、nextはoptionalDependenciesにsharpを指定しているため、デフォルトでインストールされます。Next.js 12.3.0、13.5.6、14.2.32にはsharp依存関係が宣言されていません。それらの系列では、プロジェクトがインストールした場合にのみオプティマイザーがsharpを読み込み、それ以外はSquooshにフォールバックします。

解決されたsharpのバージョンによって、サーバーに組み込まれるlibrsvgビルドが決まります。

インストールされているバージョンを確認します。

# Next.js and sharp versions
npm ls next sharp

# Direct read of the installed versions
node -e "console.log('next', require('next/package.json').version)"
node -e "console.log('sharp', require('sharp/package.json').version)"

# Lock file check (lockfileVersion 2 and 3)
grep -n '"node_modules/next"' package-lock.json | head
grep -n '"node_modules/sharp"' package-lock.json | head
# lockfileVersion 1 keys packages by bare name
grep -n '"next": {' package-lock.json | head
grep -n '"sharp": {' package-lock.json | head

# Container image check
docker run --rm <your-image> node -e "console.log(require('next/package.json').version, require('sharp/package.json').version)"

Sharp 0.35.xはengines.node: >=20.9.0を宣言しているため、Node 18はサポート対象のランタイム範囲外です。このフィールドによりnpmが古い互換性のあるsharpを選択するわけではありません。engine-strictが有効でなければ、npmはこれを参考情報として扱い、非互換のランタイムについて警告します。

• Next.js 15.0.0の依存範囲^0.33.5は、librsvg 2.58.93を同梱するsharp 0.33.5を許可します。
• Next.js 15.5.28の範囲^0.34.3 || ^0.35.5は、未修正の0.34.x系列と修正済みの0.35.5の両方を許可します。既存のロックファイルには0.34.xが残ることがあります。

sharp/librsvgの表にある0.33.xと0.34.xビルドには、修正済みのlibrsvgは含まれていません。

どう修復しますか？

Next.jsをアップグレードしてください。Node.js 20.9.0以降では、新たな依存関係解決によりsharp 0.35.5（librsvg 2.63.2）が取得されます。次の2つの例外を確認してください。

• 15.x系列の範囲は依然として^0.34.3を受け入れるため、既存のロックファイルに未修正の0.34.xビルドが残る場合があります。アップグレード後にnpm ls sharpを実行し、0.34.xのままならsharp@0.35.5を明示的にインストールしてください。
• 15.x系列のNode 18ホストは、修正が有効になる前にNode.js 20.9.0以降へ移行する必要があります。

# Next.js 16 line
npm install next@16.4.1
# or: pnpm add next@16.4.1   |   yarn add next@16.4.1

# Next.js 15 line
npm install next@15.5.28

まだNext.jsを移行できない場合は、sharpのみを強制的にアップグレードしてください。アドバイザリに明記された回避策は、Next.jsが使用するsharpのバージョンを0.35.5以上にすることです。修正済みlibrsvgを同梱するsharp系列は0.35.xだけなので、Node.js 20.9.0以降が必要です。

npm install sharp@0.35.5

このインストールでNext.jsが読み込むものが変わるのは、Next.js自身のsharp範囲が0.35.5を受け入れる場合だけです。Next.js 15.5.27は^0.34.3 || ^0.35.4を宣言しており、受け入れます。Next.js 15.0.0の宣言は^0.33.5で受け入れないため、入れ子の0.33.5がそのまま残ります。その場合はpackage.jsonで解決を強制し、再インストールします。

{
  "overrides": { "sharp": "0.35.5" }
}

pnpmではpnpm.overrides、Yarnではresolutionsを使用してください。

回避策の限界として、置き換えるのは同梱librsvgのみです。オプティマイザーのリクエスト処理方法は変わりません。

• 16.4.1の修正はsharp ^0.35.5を要求し、修正済みlibrsvg 2.63.2を導入します。
• 15.5.28の修正は、^0.34.3 || ^0.35.5の範囲に下限^0.34.3を残します。この下限には修正がありません。0.34.xビルドはlibrsvg 2.60.0～2.61.2を同梱しており、いずれもバックポートの2.60.3と2.61.5より前です。
• Node 18では15.xアップグレードは不完全です。Node.js 20.9.0以降へ移行し、サポート対象のランタイムでsharp 0.35.5を実行してから、解決されたsharpのバージョンを確認してください。

根本原因は何ですか？

解放済みメモリ使用は、コードがメモリを解放した後も、そのポインターを使い続けると発生します。SVGファイルのXMLをlibxml2で解析して描画するRustライブラリのlibrsvgでは、重複したエンティティ宣言を含む入れ子のXIncludeが、外側の解析処理がまだ保持しているxmlEntity構造体を解放します。XIncludeは、あるXML文書に別の文書のノードを取り込める仕組みです。Red HatのCVE-2026-96889レコードにこの順序が記されています。

RUSTSEC-2026-0305は障害を4つのステップで説明しています。

1. 内部エンティティの展開中、libxml2が同じエンティティ名を再宣言するXInclude文書を再帰的に解析します。
2. 2つの解析処理はlibrsvgのXmlStateエンティティマップを共有します。重複を追加すると、元のエントリが置き換わります。
3. 置き換えられたxmlEntityの破棄によってxmlFreeNode()が呼び出され、メモリが解放されます。
4. 外側のxmlCtxtParseEntity()は、その解放された144バイトの構造体へのアクセスを続けます。

1文で説明すると、エンティティマップはlibxml2がまだポインターを保持しているか確認せずにエントリを置換できたため、XIncludeの境界を越えてエンティティ名を再宣言する文書によって、パーサー内部のポインターがダングリングポインターになります。

欠落していたのはこのライフタイム確認で、上流の修正はこれを解消します。Librsvgのコミット8a1b0cd319e9af2d1e9cf878081dd77f227a0504は、libxml2がまだ使用しているxmlEntityポインターの解放を止めます。修正はlibrsvg 2.63.2で初めてリリースされ、2.62.4、2.61.5、2.60.3、2.57.5にバックポートされ、2026年9月23日に公開されました。

Next.jsは画像最適化を通じてこのコードに到達します。/_next/imageエンドポイントはurlパラメーターを受け取り、設定された許可リスト（古い系列ではimages.domains、新しい系列ではimages.localPatternsとimages.remotePatterns）と照合し、バイト列を取得してsharpに渡します。sharpはlibvipsを通じて画像を読み込みます。Next.js 16.4.0のオプティマイザーは、この処理のためにpackages/next/src/server/image-optimizer/transform.tsでlibvipsのSVGローダーを明示的に有効にします。

// packages/next/src/server/image-optimizer/transform.ts (v16.4.0)
export function getSharp(concurrency, operationCache) {
  ...
  _sharp.block({ operation: ['VipsForeignLoad'] })
  _sharp.unblock({
    operation: [
      'VipsForeignLoadHeif',   // avif
      'VipsForeignLoadJpeg',
      'VipsForeignLoadNsgif',
      'VipsForeignLoadPng',
      'VipsForeignLoadSvg',    // librsvg parses SVG bytes here
      ...
    ],
  })

libvipsが入力をSVGと識別すると、VipsForeignLoadSvgが文書をlibrsvgに渡し、リクエストのバイト列からエンティティマップのバグに到達できます。同じVipsForeignLoadSvgの有効化は15.5.xのオプティマイザーにも存在します。影響対象の古いリリースでは実装経路が異なります。たとえばNext.js 14.2.xは、マジックバイトで識別できないバッファーをすべて、形式検出のため直接sharpに渡します。場所はpackages/next/src/server/image-optimizer.ts（v14.2.32）です。

// Fallback to sharp if available
if (sharp) {
  const meta = await sharp(buffer)
    .metadata()
    .catch((_) => null)
  switch (meta?.format) {
    ...
    case 'svg':
      return SVG

そのバージョンの順序に注意してください。オプティマイザーのdangerouslyAllowSVG確認より先にsharp(buffer).metadata()がファイルを解析します。したがって、そのコード経路でSVGの制御は解析を防ぐ境界にはならず、画像を返すことだけを制御します。

どのように悪用されますか？

Next.jsに対する一連の攻撃を完結させる公開エクスプロイトはありません。librsvgのバグ自体には公開された再現手順があります。GNOME GitLabの該当トラッカー項目にはエクスプロイト資料を含むタグが付いており、CISAのCVE-2026-96889のvulnrichmentレコードは悪用状況を「poc」、技術的影響を「total」としています。ここではそれを転載せず、以下で公開された経路をエクスプロイトコードなしで説明します。

1. 攻撃者は第2の文書をXIncludeで取り込むSVGを作成します。第2の文書は、外側の文書ですでに宣言されたものと同じ名前のXMLエンティティを宣言します。
2. 攻撃者は、対象のオプティマイザーが取得できる場所、つまりアプリのimages許可リストを通過するローカルパスまたはリモートホストにSVGを配置します。
3. 攻撃者は画像最適化エンドポイント経由でその画像をリクエストします。幅にはアプリで設定されたdeviceSizesまたはimageSizesの値を、品質には許容範囲の値を指定します。例はGET /_next/image?url=https%3A%2F%2Fcdn.attacker.example%2Favatar.svg&w=640&q=75です。
4. オプティマイザーはバイト列を取得してsharpに渡します。Libvipsが文書をSVGと識別し、librsvgが解析します。
5. エンティティ展開中、入れ子のXIncludeがエンティティを再宣言します。マップは古いエントリを置換して解放しますが、外側の解析処理はそのポインターを保持したままです。
6. 外側のパーサーが解放された144バイトのxmlEntityを読み取り、解放済みメモリ使用が発生します。glibcのヒープでは、解放された内容と割り当て順序を制御できる攻撃者が、これをNode.jsサーバープロセス内の任意コード実行につなげられます。

アドバイザリがRCEの対象をglibcベースのLinuxに限定しているのは、Next.jsがインストールするビルド済みsharpバイナリがglibcビルドだからです。muslビルドは別パッケージです。

エクスプロイトはオプティマイザー内をどう進みますか？

欠落している確認は図のノードEにあります。解放前にエンティティが使用されなくなったことを確認する処理がありません。

攻撃者は何ができますか？

悪用に成功すると、Next.jsサーバープロセス、通常はアプリケーションを提供するNode.jsプロセスの権限で任意コードが実行されます。環境変数とデプロイメント認証情報、内部サービス、データベースなど、そのプロセスがアクセス可能なすべてのものにアクセスし、ユーザーに返されるレスポンスを変更できることを意味します。失敗した攻撃や部分的な悪用でもプロセスがクラッシュする場合があります。攻撃者がアロケーターの競合に勝つかどうかに関係なく、ダングリングポインターが参照されるためです。

攻撃者に必要な条件は次のとおりです。

• CVSS v4.0ベクトルAV:N/AC:L/AT:P/PR:N/UI:Nによれば、認証もユーザー操作も不要です（ネットワーク、低い複雑さ、権限不要、ユーザー操作不要、攻撃の前提条件あり）。
• サーバーがglibcベースのLinuxシステムで稼働している。
• sharpが、同梱librsvgにパッチが適用されていないビルドに解決される（0.35.4はlibrsvg 2.62.91、0.34.xは2.60.0、2.61.1または2.61.2、0.33.5は2.58.93を同梱）。
• SVGのバイト列がオプティマイザーに到達できる。攻撃者には、アプリのimagesパターン許可リストを通過するソースURLが必要です。Next.js 14.2.xではdangerouslyAllowSVGの確認より先にSVG解析が行われるため、このフラグが制御するのはレスポンスだけで、脆弱な解析は制御しません。
• アプリが受け入れる幅と品質の組み合わせ。

なぜ修正が有効なのですか？

Vercelはリクエスト処理を変更するのではなく、sharp依存関係を通じて同梱librsvgを更新しました。16.xの修正コミット（9571ec8）は、packages/next/package.jsonのsharp要件を引き上げます。

   "optionalDependencies": {
-    "sharp": "^0.35.4"
+    "sharp": "^0.35.5"
   }

15.xの修正コミット（5e3b687）も同じ変更を範囲に加えます。"sharp": "^0.34.3 || ^0.35.4"が"^0.34.3 || ^0.35.5"になります。Sharp 0.35.5はビルド済みlibvipsパッケージを@img/sharp-libvips-* 1.3.3から1.3.4に置換します。リリースノートによれば1.3.4はrsvg 2.63.2を同梱しています。これはRustSecが示すメインブランチの最初の修正版で、上流コミット8a1b0cd3を含みます。そのコミットはlibxml2がまだ使用中のxmlEntityポインターの解放を停止します。バグがなくなることで、入れ子のXInclude文書はダングリング参照を生成しなくなり、クラッシュとコード実行のいずれの経路もなくなります。

修正は完全でしょうか。同梱バイナリを使う経路では完全です。修正済みlibrsvgが根本原因を除去し、アドバイザリのバージョン範囲は依存関係の変更と一致します。ただし、注意点が2つ残ります。

• sharpのバージョン固定。 sharpを0.35.5未満に固定すると、0.34.xのどのリリースも含め、修正済みNext.jsでも脆弱なlibrsvgが残ります。このためアドバイザリはsharpのバージョンを指定して回避策を説明しています。
• RCEの「可能性」も危険にさらされている状態です。 解放済みメモリ使用の悪用はアロケーターの挙動に依存するため、アドバイザリは影響をRCEの「可能性」としています。可能性の高低で選別せず、影響対象のすべてのデプロイメントを危険にさらされているものとして扱ってください。

侵害されたかどうかを確認するには？

この問題の侵害指標は公開されていません。公開ガイダンスがない状況では、画像エンドポイント周辺で次の一般的な兆候を確認してください。

• 予期しないホストやパスを指すurlパラメーターを含む/_next/imageへのリクエスト。特に、実際にはSVGコンテンツを配信していたもの。
• オプティマイザーからのHTTP 400レスポンスの急増。dangerouslyAllowSVGが無効な場合はSVGコンテンツを拒否するため、探索トラフィックがこの痕跡を残すことがあります。
• 画像最適化と相関するNode.jsプロセスのクラッシュや再起動。同じ欠陥が、攻撃者に制御を渡す代わりにパーサーをクラッシュさせることがあるためです。
• 読み込みが途中で失敗したときにオプティマイザーが記録する「Input buffer contains unsupported image format」など、ログ中のSharpエラー。

不審な活動を見つけた場合は、サーバープロセスがアクセスできた認証情報をすべてローテーションしてください。そのプロセス内でのコード実行により、読み取られた可能性があります。

タイムライン

• 2026年9月23日：Rafael B. Diasがlibrsvgの解放済みメモリ使用をRed Hatに報告。同日、RUSTSEC-2026-0305およびCVE-2026-96889とともに公開されます。
• 2026年9月25日：CISAのCVE-2026-96889向けADP vulnrichmentが公開された概念実証を記録（「Exploitation: poc」、技術的影響「total」）。
• 2026年9月27日：librsvg 2.63.2を同梱したsharp-libvips 1.3.4が公開され、これを含むsharp 0.35.5がリリースされます。
• 2026年10月14日：VercelがGHSA-2464-fhr4-w9xwを公開し、sharpを更新したNext.js 15.5.28と16.4.1をリリースします。
• 2026年10月22日：GitHub Advisory Databaseでアドバイザリが公開・レビューされます。
• 2026年10月23日：本記事。実環境での悪用は確認されておらず、CISA KEVカタログにも未登録です。

よくある質問

Next.jsのデフォルト設定でもアプリは危険にさらされますか？ デフォルトのローダーでnext/imageを使うアプリでは、Image Optimization APIはデフォルトで有効です。SVGコンテンツがsharpに到達できるかどうかは、バージョンごとの検出経路とimages設定によって決まります。設定にかかわらずアップグレードしてください。

そもそもsharpはインストールされていますか？ 15.0.0以降、Next.jsはsharpを任意依存関係に指定しているため、サポート対象のプラットフォームで通常のnpm installを行うと含まれます。確認した15.0.0以前のリリース（12.3.0、13.5.6、14.2.32）にはその指定がないため、プロジェクトがインストールした場合だけsharpが存在します。npm ls sharpを実行してください。結果が0.35.5以降なら、修正済みlibrsvg 2.63.2を含みます。0.34.xなら含みません。それらは2.60.0、2.61.1、2.61.2を同梱しており、いずれもバックポートの2.60.3と2.61.5より古いためです。

Next.jsアドバイザリ自体にCVEはありますか？ 2026年10月23日時点でGitHubアドバイザリGHSA-2464-fhr4-w9xw自体にCVEはありません。基盤となるlibrsvgの欠陥はCVE-2026-96889であり、NVDとLinuxディストリビューションはこの番号で追跡しています。

アプリはPNGとJPEGしか提供しません。それでも懸念がありますか？ アドバイザリは欠陥の対象を画像最適化で使用されるSVGファイルに限定しています。許可リストの制約によりオプティマイザーにSVGを提供させられないアプリは、記載された経路の対象外です。それでも、安全な対応は1行のアップグレードです。

Alpine Linux（musl）なら安全ですか？ アドバイザリはRCEの対象をglibcベースのLinuxに限定しています。muslのビルド済みバイナリは別パッケージであり、アドバイザリはそれらについて言及していません。プラットフォームの違いを修正として扱わず、sharpとNext.jsをアップグレードしてください。

実際に悪用されていますか？ 2026年10月23日時点で実環境での悪用は確認されておらず、CISA KEVカタログにも登録されていません。librsvgのバグには公開された概念実証があるため、機会を狙う攻撃者が関心を持つと考え、それを踏まえてパッチを適用してください。

OstorlabのソースコードスキャンでNext.jsリポジトリをスキャンし、上記のバージョン確認を使って各デプロイメントにインストールされたNext.jsとsharpのビルドを確認してください。

参考資料

• VercelアドバイザリGHSA-2464-fhr4-w9xw：https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw （2026年10月23日確認。発見者randomguy6407とrafabd1への謝辞は2026年10月27日確認）
• GitHub Advisory Databaseエントリ：https://github.com/advisories/GHSA-2464-fhr4-w9xw （2026年10月23日確認）
• CVE-2026-96889レコード（Red Hat CNA）：https://cveawg.mitre.org/api/cve/CVE-2026-96889 （2026年10月23日確認）
• RustSecアドバイザリRUSTSEC-2026-0305（修正バージョン一覧は2026年10月24日再確認）：https://rustsec.org/advisories/RUSTSEC-2026-0305.html
• 修正コミット8a1b0cd319e9af2d1e9cf878081dd77f227a0504を参照するLibrsvgの課題トラッカー項目（作業項目#1241）：https://gitlab.gnome.org/GNOME/librsvg/-/work_items/1241 （2026年10月23日確認）
• Next.js 16.x修正コミット（sharp更新）：https://github.com/vercel/next.js/commit/9571ec899f063df6533351bec390ccb2cc0af6a3 （2026年10月23日確認）
• Next.js 15.x修正コミット（sharp更新）：https://github.com/vercel/next.js/commit/5e3b687b5edb868b064bdc058d768a7021e7f6ad （2026年10月23日確認）
• Next.js 16.4.1リリースノート：https://github.com/vercel/next.js/releases/tag/v16.4.1 （2026年10月23日確認）
• sharp 0.35.5リリースノート：https://github.com/lovell/sharp/releases/tag/v0.35.5 （2026年10月23日確認）
• sharp 0.35.5パッケージメタデータ（@img/sharp-libvips-*を1.3.4に固定、Nodeエンジン>=20.9.0）：https://raw.githubusercontent.com/lovell/sharp/v0.35.5/package.json （2026年10月27日確認）
• sharp 0.33.5パッケージメタデータ（@img/sharp-libvips-*を1.0.4に固定）：https://raw.githubusercontent.com/lovell/sharp/v0.33.5/package.json （2026年10月27日確認）
• @img/sharp-libvips-linux-x64 1.0.4公開パッケージのversions.json（rsvg 2.58.93）：https://registry.npmjs.org/@img/sharp-libvips-linux-x64/-/sharp-libvips-linux-x64-1.0.4.tgz （2026年10月27日確認）
• Next.jsパッケージメタデータ、タグv14.2.32（sharp依存関係なし）とv15.0.0（"sharp": "^0.33.5"）：https://github.com/vercel/next.js/blob/v14.2.32/packages/next/package.json および https://github.com/vercel/next.js/blob/v15.0.0/packages/next/package.json （2026年10月27日確認）
• sharp 0.34.3パッケージメタデータ（@img/sharp-libvips-*を1.2.0に固定、Nodeエンジン範囲）：https://raw.githubusercontent.com/lovell/sharp/v0.34.3/package.json （2026年10月24日確認）
• sharp-libvips 1.2.0ビルドバージョン（rsvg 2.60.0）：https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.0/versions.properties （2026年10月24日確認）
• sharp-libvips 1.2.3ビルドバージョン（rsvg 2.61.1）：https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.3/versions.properties （2026年10月24日確認）
• sharp-libvips 1.2.4ビルドバージョン（rsvg 2.61.2）：https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.4/versions.properties （2026年10月24日確認）
• sharp-libvips 1.3.4リリースノート（rsvg 2.63.2）：https://github.com/lovell/sharp-libvips/releases/tag/v1.3.4 （2026年10月23日確認）
• sharp-libvips 1.3.3リリースノート（rsvg 2.62.91）：https://github.com/lovell/sharp-libvips/releases/tag/v1.3.3 （2026年10月23日確認）
• Next.jsオプティマイザーのソース、タグv16.4.0：https://github.com/vercel/next.js/blob/v16.4.0/packages/next/src/server/image-optimizer/transform.ts （2026年10月23日確認）
• Next.jsオプティマイザーのソース、タグv14.2.32：https://github.com/vercel/next.js/blob/v14.2.32/packages/next/src/server/image-optimizer.ts （2026年10月23日確認）
• nextのnpmダウンロード数（2026年10月16～22日の1週間に44,586,009回）：https://api.npmjs.org/downloads/point/last-week/next （2026年10月24日確認）
• npmパッケージメタデータのドキュメント（engine-strictが設定されていなければenginesは参考情報）：https://docs.npmjs.com/cli/v11/configuring-npm/package-json/#engines （2026年10月28日確認）