Security researcher Piyush Gupta discovered that adding a trailing slash to API paths on AWS HTTP API, the newer and cheaper variant of API Gateway, could bypass Lambda authorizer authentication entirely. GET /v1/accounts returned 401 Unauthorized. GET /v1/accounts/ returned 200 OK with full account data. The same bypass worked on POST /v1/transfers/, allowing Gupta to initiate a wire transfer without a valid JWT.
The root cause is a path normalization mismatch between two layers of HTTP API that make independent decisions. The route matching layer determines whether a path exists. The authorizer layer determines whether the request is allowed. Those two layers disagreed on what constitutes a "match."
Gupta explains:
HTTP API does greedy path matching by default. /v1/accounts/ matched /v1/accounts as a prefix. The authorizer ran and returned Allow. Then the integration executed, but the integration mapping was fuzzy. The path got rewritten, the auth context got dropped, and suddenly I was inside without a valid JWT.
The mechanics are worth understanding for any team using HTTP API with Lambda authorizers. The authorizer sets context.authorizer.userId on the authenticated request. The backend Lambda reads that field to scope data access. When the trailing-slash path hit the integration, userId arrived as undefined. The backend didn't validate the field independently, it trusted the authorizer to have set it. With userId undefined, the integration defaulted to a system account, returning all data.
Gupta confirmed the behavior by fuzzing paths with ffuf:
The fintech fixed the issue the next day by switching from HTTP API to REST API (which has stricter path matching) and adding userId validation in every Lambda function rather than relying solely on the authorizer. On Reddit, Gupta provided reproduction steps for any team to verify whether their own APIs are affected:
If you want to reproduce, create an HTTP API with a lambda authorizer, hit the route with and without trailing slash, and check event.requestContext.authorizer in the integration lambda. It'll be present without slash, missing with slash. That's the drop.
One Reddit commenter added context about HTTP API's development trajectory that teams should factor in:
It is the newer API but development was quietly put on hold 4-5 years ago. Something about the basic internal architecture having problems and they decided to stop investing in features.
If accurate, teams choosing HTTP API over REST API for cost savings should weigh whether the product is likely to receive fixes for this class of path-matching behavior.
This is not an isolated class of vulnerability. In March 2026, CVE-2026-33186 disclosed a nearly identical pattern in gRPC-Go, when the server accepted requests where the :path pseudo-header omitted the mandatory leading slash, and successfully routed them to the correct handler, authorization interceptors evaluated the raw non-canonical path and failed to match deny rules. The fix was to reject any request with a non-canonical path before it reaches the authorization layer, the same principle that applies here.
The trailing slash issue in AWS API Gateway is not new. An AWS re:Post thread from 2024 documents the path-stripping behavior, and the AWS Chalice framework patched its local development mode in 2018 to match API Gateway's trailing-slash handling. What's new is the demonstration that the mismatch between path matching and authorization can be exploited to bypass authentication entirely, not just cause routing confusion.
On Hacker News, the debate split predictably between those who saw a misconfiguration and those who saw a platform design problem. One commenter argued the responsibility lies with AWS:
I hate when people say this, as if there's any world in which I would want my AWS API gateway to do this, let alone accidentally. HTTP is littered with these footguns, differences between slashes and no slashes is a classic. A good piece of software would make it hard to do this by accident, and probably should default to having the same behaviour with or without trailing slash.
Another pointed out the pattern is far older than AWS:
My first job, decades ago. I couldn't update something on my laptop because client's gateway blocked http://foo.com/update.exe. Guess what, http://foo.com/update.exe? worked as a bypass.
For teams using AWS HTTP API with Lambda authorizers, the immediate actions are: audit whether trailing-slash variants of protected routes return different responses, ensure backend Lambda functions validate authorization context fields independently rather than trusting the authorizer as the sole gatekeeper, and consider whether REST API's stricter path matching is appropriate for security-sensitive endpoints despite the higher cost and lower performance.