Sid frames the bug as 'the goofiest exploit I've seen' precisely because it requires no sophistication — just hammering a 6-digit code endpoint until you exhaust the keyspace in ~14 minutes. His writeup emphasizes the sheer ordinariness of the vulnerability rather than any clever bypass, implying the gap is institutional rather than technical.
Argues this isn't a failure of capability — Meta invented Zstandard, RocksDB, and runs one of the most sophisticated security orgs in the industry. The bug exists because somewhere in the org chart, nobody owned the password-reset endpoint, which is a governance problem rather than an engineering one.
Points out that rate limiting on auth endpoints has been in OWASP Top 10 since the document existed, is covered before CSRF and session fixation in every tutorial, and is the first defensive control anyone teaches. Finding this missing on a service with 2 billion MAU owned by a $1.3T company is indefensible by any modern standard.
By submitting this to Meta's bug bounty and publishing the writeup, Sid implicitly argues that an endpoint grading unlimited guesses against a 6-digit secret is a baseline failure — not a clever find. The 1,861-point HN reception suggests broad agreement that this should never have shipped.
Lays out the math explicitly: 1,000,000 possible codes, 1,000 req/sec from a cheap VPS exhausts the space in 16 minutes, with real takeovers landing in ~14. The implicit argument is that the entropy of a 6-digit code is only meaningful if the system refuses to grade unlimited attempts — without throttling, the code is effectively no protection at all.
Security researcher Sid (0xsid) discovered that Instagram's password reset flow — the endpoint that validates the 6-digit code sent to a user's email — had no rate limiting. None. You could send the code-verification request as fast as your network would carry it, and Meta's backend would happily check every guess against the real code without ever locking the account, throttling the IP, or invalidating the token.
The math is grim. A 6-digit code has 1,000,000 possible values. At 1,000 requests per second — trivial from a single VPS — you exhaust the keyspace in 16 minutes. Sid reports successful takeovers in roughly 14. The only thing standing between any Instagram account and a stranger with a Python script was the entropy of a six-digit number that the system itself agreed to grade an unlimited number of times.
The report was submitted to Meta's bug bounty program, acknowledged, patched, and paid out. The blog post that hit the front page of Hacker News (1,861 points at time of writing) isn't a disclosure timeline drama — it's a writeup of the sheer ordinariness of the bug. As the title puts it: *the goofiest exploit I've seen*.
This is the kind of vulnerability that doesn't belong in 2026. Rate limiting on authentication endpoints has been in the OWASP Top 10 since the document existed. Every auth tutorial, every Auth0 / Clerk / Supabase quickstart, every CISSP study guide hammers it. It's covered before CSRF. It's covered before session fixation. It is the *first defensive control* anyone teaches.
And yet here it is, in production, on a service with two billion monthly active users, owned by a company with a market cap north of $1.3 trillion and a security org that has invented entire classes of tooling the rest of us depend on (Zstandard, RocksDB, the FB Whitehats program itself). The bug isn't a failure of capability. It's a failure of ownership — somewhere in the org chart, the password-reset endpoint was nobody's problem.
The top-voted HN comments converge on this read. "This is what happens when you have 47 teams touching the auth surface and none of them own the rate limiter." "Bet there's a WAF rule that was supposed to catch this and got disabled during a deploy three years ago and nobody noticed." "Meta's blue team is genuinely world-class — which is why the bug is interesting, not because it's exotic." The pattern is recognizable to anyone who's worked at scale: defense-in-depth becomes defense-by-assumption, and the assumption is always that *someone else* implemented the boring control.
There's a second pattern worth naming. Bug bounty programs work great at finding novel vulnerabilities and terribly at finding obvious ones, because the obvious ones "can't possibly still be there." Researchers spend weeks on logic flaws in OAuth scopes while the front door has no lock, because they assume the front door has a lock. Sid found this in what reads like an afternoon of curiosity. The reason it survived this long isn't that it was hidden — it's that it was *too dumb to look for*.
If you're shipping auth — and even if you're not building it from scratch, you almost certainly own at least one endpoint that gates access — there are three immediate checks worth running this week:
1. Inventory every endpoint that validates a secret. Not just `/login`. The password reset code endpoint. The email verification endpoint. The 2FA TOTP endpoint. The magic link consumer. The API key validator. The webhook signature verifier. Each of these is a guessing game with finite entropy, and each needs both a per-account lockout (5-10 attempts then exponential backoff) and a per-IP rate limit (independent of accounts, to catch credential-stuffing fan-out).
2. Test the limits, don't read the code. Static analysis won't catch a middleware that was removed in a refactor. Write a synthetic monitor that hits your own password-reset verifier 100 times in 10 seconds from a test IP and alerts if request 100 returns anything other than 429. Run it in production, continuously. If your rate limiter isn't being actively probed by your own monitoring, you don't know if it's working — you only know it was working the day you wrote the code.
3. Make the boring controls someone's job. Specifically: assign an owner to "every endpoint that consumes a secret" as a *cross-cutting* responsibility, not a per-team one. The Meta bug exists because rate limiting is everyone's responsibility, which means it's no one's. A single security engineer with a script that enumerates auth endpoints and probes each one weekly would have caught this in their first week on the job.
For practitioners using managed auth (Clerk, Auth0, Supabase Auth, Firebase Auth, AWS Cognito): you are probably fine on the basics, but verify. Each of these services exposes rate-limit configuration, and the defaults are not always conservative. Cognito's `AdminInitiateAuth` flow, for example, has notoriously generous limits unless you configure WAF in front of it.
The goofy exploits aren't going away — if anything, they're going to multiply. The half-life of an auth endpoint between "shipped with rate limiting" and "the rate limiter got removed during a microservice migration nobody documented" is shorter than most security review cycles. As more orgs decompose monoliths into 200-microservice meshes, the surface area of "endpoint that consumes a secret" explodes, and the per-endpoint cognitive load on the team that originally wrote the auth flow approaches zero.
Meta will fix this one and pay Sid his bounty. The interesting question is how many *other* Fortune 500 auth endpoints have the same hole right now, waiting for an afternoon of curiosity from a researcher who hasn't assumed the front door is locked.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.