How a hardcoded Lambda URL in a JS bundle led to admin token generation with no credentials required — and a full chain to AWS credential exposure

Background

While hunting on a telecom provider's bug bounty program, I came across what turned out to be a fairly critical authentication flaw — an internal Lambda endpoint that would happily issue a signed JWT for any user, including admin accounts, given nothing more than an email address. No password. No OTP. No rate limiting.

This writeup documents the discovery path, the exploitation chain, and why the triage outcome was disappointing even when the impact was real and demonstrated.

Discovery path

The entry point was the program's main web application, which is explicitly in scope. Like most modern SPAs, the app loads a React bundle on the client side — and that bundle contains all the API endpoints the app talks to.

1-Loaded the target's SPA in the browser and opened DevTools → Sources. Located the main JS chunk (main.xxxxxxxx.js).

2-Searched the bundle for lambda-url — a string that commonly appears when developers hardcode AWS Lambda function URLs directly into frontend code.

3-Found a full Lambda URL hardcoded in the bundle pointing to an internal API backend.

4-Visited /docs on the Lambda URL — FastAPI auto-generates Swagger docs if not disabled. The full internal API surface was exposed publicly with zero auth

Lesson: Always grep JS bundles for lambda-url, execute-api, internal, and amazonaws.com. Frontend code often leaks backend infrastructure that was never meant to be public

The vulnerability

The Lambda API exposed a /auth/getToken endpoint. The endpoint accepted a POST request with a JSON body containing just an email address, and returned a fully signed JWT with no authentication whatsoever.

POST /auth/getToken
Content-Type: application/json

{"email": "admin@[REDACTED].com"}

--- Response (200 OK) ---

{
  "jwt_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  .eyJleHAiOjE3NzI4NDIxNjYsInN1YiI6ImFkbWluQC4uLn0
  .nPHsk..."
}
Respone
{
  "exp": 1772842166,
  "sub": "admin@[REDACTED].com"
}
This token was then tested against authenticated endpoints on the in-scope web appli
cation — and it worked. The application accepted and trusted the token as if it had been issued through the normal login flow.

The full impact chain

/cron/getEngageSummary — No auth required. Returns real internal employee emails. Used to enumerate valid email targets.

/auth/getToken + employee email — Pass any email, receive a valid signed JWT. No credentials needed.

JWT → authenticated endpoints — Token accepted by the main in-scope web application. Full authenticated access as any user.

/auth/getAccessKey — Returns live AWS Access Key ID and Secret Key. Direct access to S3 buckets.

S3 access — Buckets contain subscriber PII: personal data, billing history, behavioral profiles, location data.

Impact

AuthenticationComplete bypass — any user including admin, zero credentials required

Data exposureSubscriber PII, billing, behavioral & location data via S3

InfrastructureLive AWS credentials exposed via /auth/getAccessKey

Recon assistEmployee emails leaked via unauthenticated /cron endpoint