This is a trust-boundary misconfiguration, not a code defect. @fastify/aws-lambda 6.4.0 shipped with the secure implementation already in place—an internal per-invocation token that should have been the exclusive source for request.awsLambda.event. The vulnerability exists because the getter used a layered resolution strategy: client headers first, trusted token as fallback. An attacker needs only to set the x-apigateway-event header with forged claims to bypass authentication entirely, impersonate any user or role, and inject fraudulent authorization context into downstream services.
The fix in 6.4.1 doesn't introduce new secure logic—it enforces the existing secure path as the only path by stripping reserved headers before the request is processed. This confirms the secure implementation existed all along; the bug was architectural, a deliberate inversion of trust that prioritized ergonomics over defense-in-depth.
Prioritize upgrading to 6.4.1 immediately. Audit any code that directly accesses request.awsLambda.event for authorization decisions—this decoration was documented for that purpose, and any middleware consuming it transitively inherits the same risk. Verify that third-party middleware layers don't bypass the fix by accessing headers before stripping completes. The EPSS score of 0.00218 against a CVSS 9.1 is an anomalous gap that likely reflects low deployment awareness or attacker unfamiliarity with serverless attack surfaces, not low exploitability. Assume active targeting is possible in any environment where untrusted clients can reach the Lambda adapter layer.