Fastifyのセッション署名検証を修正｜鍵交換後も残る旧Cookieと失効条件

FastifyでCookie署名鍵の交換を「既存セッションの失効」として使っている場合は、暗号化に使う鍵も確認してください。2026年11月2日、@fastify/secure-sessionの署名検証を回避できるCVE-2026-117549が公表されました。影響版は7.5.0以上8.4.2未満で、修正版は8.4.2です。署名を有効にしていても、古いCookieの署名を除いた値が受け入れられる場合があります。

重要なのは、この問題がセッション内容を自由に偽造する脆弱性ではないことです。攻撃者は有効期限内の暗号化済みセッションCookieを既に持っている必要があります。提供元は、期限の延長や暗号鍵交換後の継続利用はできないと説明しています。何を交換し、どの旧Cookieを拒否したいかを整理することが対応の出発点です。

本稿は11月3日に確認した公式勧告とREADMEに基づくニュース兼対応解説です。検証手順や運用上の判断は本サイトの提案であり、本サイトが攻撃の再現や実環境の被害調査を行ったものではありません。

署名が無効でも復号へ進んでいた

Fastify公式の脆弱性勧告によると、対象版はcookie.signed: trueを設定した際、fastify.unsignCookie()による検査が無効を返しても、元のCookie値をデコーダーへ渡していました。その結果、外側の署名が検証できなくても、暗号化されたセッションが復号される場合があります。

実務上の影響が現れるのは、@fastify/cookieの署名用secretとセッションの暗号鍵を独立して用意し、暗号鍵は有効なまま、署名用secretだけを交換して既存セッションを終了させようとする構成です。旧Cookieを持つ者は、古くなった署名を取り除いてセッションを使い続けられるとされています。

この条件を「誰でも管理者としてログインできる」と言い換えることはできません。Cookieの取得手段をこの脆弱性が提供するわけではなく、攻撃者がどちらかの秘密鍵を知る必要もありません。既存のCookieと鍵の運用が組み合わさって、意図した失効が成立しない問題です。

提供元の評価はCVSS v3.1で4.2、Moderateです。ネットワークから利用できる一方、攻撃の複雑さは高く、低い権限が必要というベクトルです。数値だけで後回しにせず、署名鍵交換を緊急失効の手順に組み込んでいるかを確認してください。今回読んだ勧告には、実環境での悪用確認は記載されていません。

修正版への更新と旧セッションの終了を分ける

8.4.2以降では、署名を有効にしている状態で署名検査が失敗した場合、セッションのデコードへ進まなくなります。これが今回のコード上の修正です。依存パッケージの更新と、既に発行されたセッションを終了させる運用は、別の確認項目として管理します。

公式勧告は、署名用secretだけの交換に頼らず、セッション暗号鍵を交換する回避策を示しています。ただし、鍵を配列で設定する環境では、先頭へ新鍵を加えるだけで全旧セッションが失効すると判断してはいけません。READMEの通常の鍵移行は、旧Cookieを継続利用できるようにする仕組みです。

secure-sessionの公式READMEは、新鍵を先頭、旧鍵を後ろへ置く配列を例示しています。この状態では旧鍵で作られたセッションも復号でき、次に読み取った際、新しい鍵でCookieが再発行されます。利用者を一斉にログアウトさせずに鍵を切り替えるための移行と、旧鍵のセッションを拒否する処理は目的が異なります。

READMEは、暗号化に使われた鍵が配列に残る間、既存セッションは有効で、旧鍵を配列から外すことでその鍵のセッションを終了させると明記しています。緊急失効が必要なら、受け入れる鍵の集合を確認します。新鍵を追加した事実だけを完了証跡にせず、拒否対象の旧鍵が残っていないことを照合してください。

二つの秘密と配備先を棚卸しする

まずpackage.json、ロックファイル、実際のビルド結果で@fastify/secure-sessionの利用版を調べます。別名の@fastify/sessionやFastify本体、@fastify/http-proxyは別のパッケージです。似た名称の更新記録だけで今回の対応を完了扱いにしないでください。

npm ls @fastify/secure-session @fastify/cookie
npm explain @fastify/secure-session

上記はnpm管理のプロジェクトで依存関係を確認する例です。間接依存なら呼び出し元のパッケージまで追い、本番と同じロックファイルから解決された結果を確かめます。開発端末の表示が新しくても、コンテナや別サービスに古いコピーが残る可能性は別途確認が必要です。

次に、cookie.signedの設定、Cookie署名用secret、secure-sessionのkeyまたは鍵の配列、expiryの設定を対応付けます。記録するのは秘密の値そのものではなく、用途、保管先の識別名、管理責任者、配備先、交換履歴です。鍵をチケットや共有ログへ貼り付けて調査しないでください。

複数のセッションを登録している場合も、一つの設定だけで全体を代表させないようにします。公式READMEは複数セッションの設定を提供しており、セッション名やCookie名、利用する鍵が異なる構成を取れます。どの保護APIがどのCookieを使うかを確認し、対象外の経路まで同じ期待値で試験しないことが重要です。

鍵交換を利用者影響と同時に計画する

暗号鍵を受け入れ対象から外す操作は、その鍵で発行した正規の利用者のセッションにも影響します。本サイトは、緊急失効の必要性、再ログインの案内、処理途中の画面やジョブへの影響、サポート窓口の対応を同じ変更計画に入れることを勧めます。通常の定期移行と混同しないためです。

複数台で同じサービスを動かす場合、鍵設定の反映が一部にとどまると、接続先によって旧セッションの受け入れ結果が変わり得ます。どのノードへ何を配備したかを記録し、ロードバランサーの後ろを含めて確認します。新しいCookieを発行するノードと受け取るノードの設定も合わせて検討してください。

一時的に問題が出たからといって、失効させた旧鍵を無条件に戻すと、終了させたいセッションを再び受け入れる可能性があります。ロールバック計画には、アプリケーション版だけでなく鍵の受け入れ方針も含めます。障害時に誰が復帰を判断するかを決め、セキュリティ上の目的を消さない復旧手順にします。

署名用secretの交換と暗号鍵の交換を同じ「キー更新」という作業名で扱うと、どのセッションが残るかが見えなくなります。変更票では署名検査の修正、暗号鍵の受け入れ集合、利用者の再認証を別々に記載すると、作業後に何を保証できるかを説明しやすくなります。

有効期限とCookie属性を失効の代わりにしない

READMEは、セッションが有効と見なされる時間をexpiryで制御し、Cookie側のオプションとは別であると説明しています。ブラウザーのCookie期限を変更したことと、サーバーが以前の値を拒否することを同じ確認にしないでください。今回の問題も、有効期限内のCookieが前提です。

SecureやHttpOnly、SameSiteはCookieの扱いに関わる重要な設定ですが、古い暗号鍵を受け入れ続ける問題を解決する設定ではありません。属性を追加したことだけで、今回の署名検証の修正や鍵の失効確認が不要になるわけではありません。保護する層と、失効の判定条件を分けます。

また、ログアウト後にブラウザーからCookieが消えたことだけでは、別に保存された同じ値の受け入れ可否は分かりません。ステートレスCookieを用いる構成では、発行済みの値をどこで拒否するかが重要です。画面の切り替えだけを成功条件にせず、保護APIでの認証結果を確認します。

検証環境で三種類のCookieを比べる

以下は許可された隔離環境での検証計画です。テスト用アカウントを使い、更新前に発行した期限内のCookie、更新後に正規発行したCookie、期限が切れたCookieを区別して用意します。秘密やCookie本体を試験報告書へ残さず、ケース番号と期待値を記録してください。

署名を有効にした対象構成では、正規の署名付きCookieが想定した利用者として扱われることを確認します。次に勧告が扱う署名欠落・署名不正のケースについて、更新後に認証済みとして扱われないことを確認します。単なるHTTPエラーではなく、保護された処理やデータ返却が先に行われていないかも照合します。

旧鍵を残した通常移行では旧セッションの継続を、旧鍵を除外した緊急失効では旧セッションの拒否を、それぞれ期待値にします。同じ鍵交換の試験でも結果が違うのは、設計目的が違うためです。全ノードで結果が一致するかを確認し、片方だけの成功で終わらせないでください。

期限切れのCookieが拒否されること、新規ログイン後の通常操作ができること、意図しないアカウント切り替えが起きないことも確認します。今回の勧告は期限延長やデータ偽造を示していないため、それらの成功を再現したかのような試験報告は作りません。期待値は公式が示す影響範囲に合わせます。

更新完了は旧値の拒否まで記録する

過去に署名鍵だけを交換して全セッションを終了させたと報告していた場合は、その時点の暗号鍵設定と受け入れ期間を確認してください。旧Cookieの利用があったかは、保存されている認証・アクセス記録の範囲で調べます。記録がない期間を「悪用なし」と扱わず、確認できた範囲を残します。

最終的な完了記録には、稼働中のパッケージ版、署名設定、旧暗号鍵を受け入れるかどうか、旧Cookieと新Cookieの認証結果、利用者への案内を含めます。8.4.2への更新を確認したうえで、自社が約束する失効範囲も検証することが、今回の問題を運用へ反映する具体的な対応になります。

関連記事

ログアウト後も使えるセッションを残さないための失効設計では、製品を横断した失効条件の設計を説明しています。