@fastify/aws-lambda における Lambda イベントの検証不備の脆弱性（JVNDB-2026-032082）

JVN（Japan Vulnerability Notes）は、Fastify 向け AWS Lambda 連携モジュールである @fastify/aws-lambda において、Lambda イベントの検証が不十分であることに起因する脆弱性が存在すると公表した。AWS API Gateway からのプロキシ統合などで利用される入力イベントの取り扱いに問題があり、認証・認可ロジックを迂回する想定外の動作につながるおそれがある。

脆弱性の詳細

公表情報によると、@fastify/aws-lambda には「Lambda イベントの信頼性についての不十分な検証（不適切な入力の取り扱い）」に関する脆弱性が存在する。バージョン 6.4.0 の実装では、Fastify の各リクエストに request.awsLambda.event と request.awsLambda.context をデコレートする際、クライアントが任意に設定できる x-apigateway-event および x-apigateway-context HTTP ヘッダを優先的に参照し、信頼できる内部トークンに基づく本来のイベント情報より前に使用してしまう挙動が確認されている。

これらのヘッダは本来内部的に利用されるべき情報であり、通常のリクエストからは除去・保護されることが期待されるが、当該バージョンでは外部から渡された値がそのまま認証・認可に利用されるイベント情報として扱われてしまう。その結果、攻撃者がネットワーク越しに細工した HTTP ヘッダを 1 つ付与するだけで、Lambda プロキシイベントおよびオーソライザコンテキストを偽造し、正規のイベントを上書きできる可能性がある。

この挙動に依存して request.awsLambda.event やそのオーソライザコンテキストを信頼してアイデンティティやアクセス制御を行っているアプリケーションでは、認証・認可のバイパスや権限昇格につながりうる。クラウド上で API を公開し、API Gateway と Lambda を組み合わせている構成では、外部からのリクエストだけで認証済みユーザや管理者になりすます攻撃シナリオが成立しやすく、被害が顕在化しやすい。

注意: 本件に紐づく CVE 番号（例: CVE-2026-18248）および CVSS スコア（例: 深刻度 9 以上の高リスクとして扱われている）は、参照した公的情報（海外の脆弱性情報やプロジェクト側のアドバイザリ）から把握できるが、JVNDB-2026-032082 の公式掲載内容と完全に一致しているかどうかを本回答単独では検証しきれない。そのため、本記事では数値を断定して記載せず、「詳細は現時点で不明」とする。自社の脆弱性管理台帳を更新する際は、JVN（Japan Vulnerability Notes）の当該公表情報および @fastify/aws-lambda の公式セキュリティアドバイザリを確認し、CVE / CVSS を正確に転記したうえで優先度付けに用いることが重要である。

影響を受ける製品・バージョン

• @fastify/aws-lambda バージョン 6.4.0（Lambda イベントの偽造が可能とされている影響バージョン。詳しい影響範囲は JVN（Japan Vulnerability Notes）および公式アドバイザリの公表内容に従って確認）
• 上記モジュールを利用している Fastify ベースの API サーバや Lambda 関数（特に request.awsLambda.event / request.awsLambda.context を前提に認証・認可を行っているもの）

推奨される対策

• 修正版への更新: @fastify/aws-lambda の修正済みバージョン（例: 6.4.1 以降）へアップデートし、イベントデコレーションが内部トークンにのみ基づいて行われ、x-apigateway-event / x-apigateway-context などの予約ヘッダがリクエスト処理前に除去されるようにする。具体的な修正バージョンは JVN（Japan Vulnerability Notes）および公式リポジトリのリリースノートに従って確認する。
• 依存関係の棚卸し: package-lock.json / yarn.lock / pnpm-lock.yaml 等のロックファイルで、実運用環境に導入されている @fastify/aws-lambda の実バージョンを確認し、CI/CD で同一バージョンが展開されるよう固定する。依存ライブラリの自動更新機構を利用している場合は、影響バージョンが混入していないかも併せて確認する。
• 入力の検証強化: Lambda イベントや HTTP リクエスト由来のデータについて、型・必須項目・許容値をサーバ側で明示的に検証し、想定外のデータは拒否する。特に、認証・認可情報を含むフィールドやヘッダについては、信頼できる経路からのみ受け取るよう設計し、クライアントが任意に指定できるヘッダからは取り込まないようにする。
• 監視と記録: 失敗したリクエスト、検証エラー、例外発生のログを収集し、急増を検知できるアラートを設定する。Lambda 及び API Gateway のアクセスログとアプリケーションログを突き合わせることで、イベント偽造による不審な挙動を早期に検知できる可能性が高まる。

日本の中小企業が今すぐ取るべき行動

• 最優先: 自社の API やバッチ処理が @fastify/aws-lambda を利用しているかをソースコード・依存関係一覧・コンテナイメージなどから検索し、利用箇所と稼働環境（本番 / 検証 / 開発）を洗い出す。フレームワークや共通ライブラリ経由で間接的に利用しているケースにも注意する。
• 次に: 影響範囲のバージョン（6.4.0 など）に該当する場合、更新計画を立て、まず検証環境で修正版への更新と簡易回帰テストを実施し、問題がなければ本番環境へ反映する。Lambda 関数のデプロイ方式（コンテナイメージ / ZIP デプロイなど）ごとに、反映手順とロールバック手順を事前に確認しておく。
• 並行して: 外部公開しているエンドポイントの入力条件を点検し、不要なパラメータ受け入れや過度に大きい入力を拒否する設定を導入する。API Gateway 側でのヘッダ制限や WAF によるフィルタリングを併用し、x-apigateway-event 等の予約ヘッダをクライアントから指定できないようにすることも検討する。
• 運用面: ログの保全期間と参照手順を決め、異常時に「誰が・どのログを・どこで確認するか」を明文化する。特に、認証・認可に関連する例外や 5xx 応答の発生時に、Lambda イベントの中身や関連ヘッダを追跡できるよう、必要最小限の情報を安全な形で記録しておくことが望ましい。

CSRIからの現場アドバイス

実際のペネトレーションテストでは、API ゲートウェイや Lambda 連携において「入力がどこで検証されるか」が曖昧なまま実装され、フレームワーク側の前提に依存しているケースが多く見つかる。診断報告書でよく指摘されるのが、想定外の形式や巨大な入力、そしてクライアント任意のヘッダに対する例外処理やフィルタリング不足だ。

例えるなら、受付で本人確認をせずに「名札だけ見て会議室に通す」ようなものだ。つまり、外から渡された情報をうのみにすると、プログラムが誤った判断で動いてしまうということ。被害は一見地味でも、誤処理や停止が続くと業務影響が大きくなるほか、今回のように認証・認可そのものが迂回されると、情報漏えいや不正操作に直結しうる。

まず稼働中の @fastify/aws-lambda のバージョンをロックファイルと本番成果物（Lambda 関数のデプロイパッケージやコンテナイメージ）で確認し、影響範囲に入るかを整理する。次に担当者または保守ベンダーへ、修正版への更新と簡易回帰テストの実施を依頼する。最後に、入力検証エラーや認証・認可関連の異常がログとして適切に取得・保全されているかを今週中に確認したい。

参照: fastifyのfastify/aws-lambdaにおけるデータの信頼性についての不十分な検証に関する脆弱性