@fastify/aws-lambda EUVD-2026-52329

Exploitation requires that the target application runs @fastify/aws-lambda 6.4.0 in its default configuration AND reads request.awsLambda.event (or request.awsLambda.context) - typically event.requestContext.authorizer claims - to make identity or authorization decisions; against such an app an unauthenticated remote attacker needs only to set the x-apigateway-event (and optionally x-apigateway-context) HTTP header to forge the entire proxy event and override the genuine one. Limiting factors: applications that never consult the awsLambda decoration for access control are not meaningfully exploitable; the flaw exists only in version 6.4.0, since 6.4.1 strips and ignores these headers; and success depends on the app trusting the header-derived event rather than an independently verified identity source.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1) is internally consistent with the description: network-reachable, low complexity, no privileges, no user interaction, with high confidentiality and integrity impact and no availability impact - a clean fit for a header-forgeable auth bypass. This is not a high-CVSS-but-low-real-risk case: the precondition (setting one HTTP header) is minimal and the payoff (impersonating any identity or authorizer context) is severe wherever the decoration is trusted. No EPSS score, KEV listing, or POC was provided, so exploitation probability cannot be quantified and active exploitation is not confirmed; the absence of these signals reflects missing data, not low risk. Because the flaw is CWE-345 with a network vector and no authentication, practical risk is gated almost entirely by whether the deployed application actually reads request.awsLambda.event for access-control decisions - critical for those apps, negligible for apps that ignore the decoration.

An attacker sends a normal HTTPS request to a Lambda-hosted Fastify app running 6.4.0 but adds an x-apigateway-event header containing a crafted proxy event whose requestContext.authorizer claims name an administrator. The adapter prefers this header over the genuine internal token, so request.awsLambda.event now reflects the forged identity and the application authorizes the request as admin. No public exploit was identified at time of analysis, but the technique needs only one header and no authentication.