A leftover localhost callback lets Cognito hand OAuth tokens to whatever binds port 3000

Collecting a redirect on port 3000 of someone else's machine costs the attacker a foothold first. The post's own list of exploitable environments says so: compromised workstations, shared development servers, CI runners with exposed ports ^[8]. Teams that also added 3001 and 8080 gave the attacker more listeners to pick from ^[9]. Two of the other patterns it flags need nothing at all on the victim's device. A dangling Route 53 CNAME or a decommissioned S3 bucket lets an attacker stand up attacker.example.com and receive the redirect under a wildcard match ^[10]. An http:// entry sitting beside the https:// one lets someone on the same coffee shop wifi take the redirect in transit ^[11]. Cleaning an allowed list in order of who can reach it puts those two ahead of the laptop entry.

Cognito's part in this is a comparison. At step 4 of the five-step flow the post lays out ^[3], it checks the supplied redirect_uri against the app client's allowed callback URLs, and if http://localhost:3000/callback is on the list, the redirect is valid ^[4]. The authorize link is otherwise ordinary: client_id, response_type=code, scope=openid+email+profile ^[5]. The user authenticates on the real login page of the real identity provider ^[6].

For the code-flow version to end in a hijacked session, the attacker has to complete the token exchange. On a public client that needs no secret, and the post notes that SPAs and mobile apps do not use client secrets ^[18]. Implicit grant removes the step. The access token and ID token land in the fragment of the localhost URL, where the listener reads them ^[7].

What happens after the theft depends on two app client settings the post supplies as an example. With EnableTokenRevocation = false, the legitimate user cannot invalidate the stolen tokens, and the attacker's session runs until they expire ^[15]. With AccessTokenValidity at 24 hours and RefreshTokenValidity at 365 days ^[16], one interception yields 365 successive access tokens before the refresh token runs out ^[17].

The post argues that no scanner asks whether the callback list contains an attacker-reachable entry, because the question is not a boolean ^[14]. Three of the four dangerous patterns are properties of the string, and a rule that reads the entries can flag a loopback host, an http scheme or a wildcard by pattern, which is more than confirming a URL is present ^[13]. The staging case is the one that needs someone who knows the estate, since nothing in an HTTPS URL says which environment has the thinner logging and the softer database ^[12].

This is one dev.to analysis, labelled human-authored with AI used for formatting and proofreading, and it argues from configuration without citing a breach ^[20]. Its author wrote that the leftover entry "is now a token exfiltration endpoint" ^[2], and puts the remediation at thirty seconds ^[19].