@fastify/aws-lambda vulnerable to Lambda event spoofing via client-controlled x-apigateway-event header

CVE-2026-18248 affects @fastify/aws-lambda (the npm package aws-lambda-fastify prior to v3, now @fastify/aws-lambda), fixed in v6.4.1. The library bridges AWS Lambda events into Fastify's HTTP processing pipeline using inject(). When processing an incoming request, the library serializes the Lambda event object into an x-apigateway-event HTTP header. The flaw: it did not strip or overwrite a client-supplied x-apigateway-event header before populating request.awsLambda.event. An unauthenticated attacker can send a crafted header containing a forged Lambda event — including spoofed requestContext.authorizer claims, source IPs, API keys, and identity context — and the application will trust it. All versions before 6.4.1 with decorateRequest enabled (the default) are affected.

The vendor's CRITICAL 9.1 rating is technically accurate for the attack mechanics: unauthenticated, network-reachable, low complexity, high confidentiality and integrity impact. However, it overstates real-world risk for most enterprises. The package has ~10,000 weekly npm downloads — a popular serverless adapter, but a tiny fraction of the Node.js ecosystem. Exploitation requires the target application to *actually read* request.awsLambda.event (or the raw header) for authorization decisions, which further narrows the vulnerable population. The blast radius is per-application, not fleet-wide. A HIGH rating better reflects the operational reality: trivially exploitable where it applies, but the 'where it applies' is narrow.

Why this verdict

• Unauthenticated remote, zero-click: The attack requires only sending an HTTP header — no credentials, no user interaction, no race conditions. This is the primary factor preventing a downgrade below HIGH.
• Narrow installed base caps real-world exposure: ~10K weekly npm downloads and 17 dependents. Compare to Express (30M+/week) or even serverless-http (200K+/week). Most enterprises running Lambda will not have this package in their dependency tree at all.
• Conditional exploitability: The application must specifically read request.awsLambda.event for authorization decisions. Applications using independent JWT verification, Cognito middleware, or IAM-based auth are unaffected even if they run the vulnerable version.
• Role multiplier: @fastify/aws-lambda is application-tier software. It is not a hypervisor, IdP, domain controller, CI/CD system, or network edge appliance. The blast radius of a successful exploit is confined to the single Lambda-backed API — no lateral movement to other functions, AWS accounts, or infrastructure. This is a (b) typical-role component. No high-value-role floor applies.
• Analogous precedent: The Hono framework's CVE-2026-27700 (GHSA-xh87-mx6m-69f3) was a structurally identical Lambda adapter header-trust bug rated HIGH 8.2. This CVE has a similar profile but narrower install base.

Why not higher?

CRITICAL would require either active exploitation (no KEV, no campaigns), a fleet-scale blast radius (this is per-application only), or a canonical high-value-role deployment (Lambda adapters are application-tier, not identity/infra components). The installed base of ~10K/week is too narrow to justify CRITICAL even though the mechanics are trivially exploitable.

Why not lower?

MEDIUM would understate the risk for the applications that *are* affected. The attack is unauthenticated, trivially weaponizable with curl, requires no special positioning, and results in complete authorization bypass. Any enterprise with this dependency in a production API that gates access on Lambda event data faces a real and immediate threat. The zero-friction exploit path keeps this firmly at HIGH.

1. Deploy a WAF rule to strip or block the x-apigateway-event header from client requests — AWS WAF, Cloudflare, or any L7 WAF in front of API Gateway can drop requests containing the x-apigateway-event or x-apigateway-context headers. This neutralizes the spoofing vector without a code change. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
2. Audit application code for event-based authorization patterns — Search your codebase for request.awsLambda.event, request.headers['x-apigateway-event'], and any references to requestContext.authorizer. If the application does not use these for access control, the practical risk drops to negligible. Complete this audit within 30 days.
3. Migrate authorization to independent JWT validation — Instead of trusting the Lambda event's authorizer claims, validate JWTs directly using a library like jsonwebtoken or jose against your IdP's JWKS endpoint. This eliminates the entire class of event-spoofing attacks regardless of adapter version.
4. Upgrade to @fastify/aws-lambda >= 6.4.1 — The definitive fix. The patched version strips client-supplied event headers before populating the decorator. Apply within the 180-day noisgate remediation SLA for HIGH.

Run this on any machine with npm or node available. Point it at the directory containing your Lambda function's package.json. No special privileges required. Example: bash check_cve_2026_18248.sh /path/to/my-lambda-project

#!/usr/bin/env bash
# check_cve_2026_18248.sh — Detect CVE-2026-18248 in @fastify/aws-lambda
# Usage: bash check_cve_2026_18248.sh <project-directory>
# Exit codes: 0 = PATCHED/not present, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
RESULT="UNKNOWN"

if [ ! -d "$PROJECT_DIR" ]; then
  echo "ERROR: Directory $PROJECT_DIR does not exist"
  exit 2
fi

# Check for the package in node_modules
PKG_JSON="$PROJECT_DIR/node_modules/@fastify/aws-lambda/package.json"
LEGACY_PKG_JSON="$PROJECT_DIR/node_modules/aws-lambda-fastify/package.json"

check_version() {
  local pkg_file="$1"
  local pkg_name="$2"
  if [ ! -f "$pkg_file" ]; then
    return 1
  fi
  VERSION=$(node -e "console.log(require('$pkg_file').version)" 2>/dev/null || echo "")
  if [ -z "$VERSION" ]; then
    echo "UNKNOWN — could not read version from $pkg_name"
    exit 2
  fi
  echo "Found $pkg_name@$VERSION"
  # Compare: vulnerable if < 6.4.1
  MAJOR=$(echo "$VERSION" | cut -d. -f1)
  MINOR=$(echo "$VERSION" | cut -d. -f2)
  PATCH=$(echo "$VERSION" | cut -d. -f3 | cut -d- -f1)
  if [ "$MAJOR" -lt 6 ]; then
    RESULT="VULNERABLE"
  elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -lt 4 ]; then
    RESULT="VULNERABLE"
  elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 4 ] && [ "$PATCH" -lt 1 ]; then
    RESULT="VULNERABLE"
  else
    RESULT="PATCHED"
  fi
  return 0
}

if check_version "$PKG_JSON" "@fastify/aws-lambda"; then
  : # version checked
elif check_version "$LEGACY_PKG_JSON" "aws-lambda-fastify"; then
  echo "WARNING: Using deprecated aws-lambda-fastify package — all versions are VULNERABLE"
  RESULT="VULNERABLE"
else
  # Check package-lock.json or yarn.lock as fallback
  if grep -q '@fastify/aws-lambda\|aws-lambda-fastify' "$PROJECT_DIR/package.json" 2>/dev/null; then
    echo "UNKNOWN — package is listed as dependency but not installed. Run npm install first."
    exit 2
  else
    echo "PATCHED — @fastify/aws-lambda is not a dependency of this project"
    exit 0
  fi
fi

echo "$RESULT"
if [ "$RESULT" = "VULNERABLE" ]; then
  echo "ACTION: Upgrade to @fastify/aws-lambda >= 6.4.1"
  exit 1
elif [ "$RESULT" = "PATCHED" ]; then
  exit 0
else
  exit 2
fi

Sources

1. Fastify aws-lambda-fastify GitHub repository
2. @fastify/aws-lambda npm package
3. Hono CVE-2026-27700 — analogous Lambda adapter header spoofing (GHSA-xh87-mx6m-69f3)
4. aws-lambda-fastify releases and changelogs
5. Fastify aws-lambda-fastify architecture — DeepWiki
6. Socket.dev — @fastify/aws-lambda package overview
7. FIRST EPSS API