eMudhra 1FA OTP Login Bypass: Why a Public RSA Key and No Rate Limiting Broke the Flow

The bypass in one paragraph

A researcher posting as @49016 on the Mastodon instance catgirl.cloud demonstrated a complete bypass of eMudhra's 1FA OTP login system by extracting the RSA public key that eMudhra ships to browsers, using it to encrypt their own OTP requests, and then brute-forcing the OTP verification endpoint. The post states that the brute force is not sped up in the demo video and that an attacker only needs to pass Cloudflare Turnstile once. The claimed consequence is account takeover for any eMudhra certificate holder whose email address can be found through OSINT.

What eMudhra's OTP flow actually does

eMudhra's login flow encrypts the OTP payload client-side to an RSA public key before sending it to the server. The public key is embedded in the JavaScript served to the browser, so it is not a secret in any meaningful sense — anyone who loads the login page can read it. The post publishes the key verbatim:

Client-side encryption to a published public key is a normal pattern. Its purpose is to keep request bodies opaque to intermediaries — in this case Cloudflare — rather than to authenticate the client. As one Hacker News commenter, ignatella, put it:

They put the public key into js and encrypt the body of the request. This is common practice to protect users' important data from being accessed by a proxy (in this case, Cloudflare) and is ok.

The actual bug is the verification endpoint, not the key

The vulnerability is not that the public key is public. The vulnerability is that the OTP verification endpoint apparently accepts unlimited guesses. Because the OTP space is small, an attacker who can submit requests freely can enumerate it. The same commenter summarized the failure precisely:

But the real bug is that they don't rate-limit, invalidate, or protect the endpoint related to OTP checks, so it can be brute-forced, as the search space is limited.

Cloudflare Turnstile is the only gate in front of that endpoint, and the post claims it only has to be solved once per attack session. Turnstile is a bot-detection layer, not an authorization control, so it does not constrain the number of OTP guesses an already-passing client can make.

How fast the attack runs

The researcher states that the brute-forcing shown in the demo video is not sped up, and characterizes it as "that fast." The post also notes that the attacker only needs to pass Cloudflare Turnstile once. No specific request-per-second figure is given in the source material, so the exact throughput is not established by the post itself.

Claimed impact: takeover of existing eMudhra certificates

The post's most serious claim is that the bypass is not limited to a single account. The author writes that you can "basically just rob any existing emudhra cert with this by just osinting the email associated and fucking logging in." In other words, the attack chain is: find a target's email address through open-source intelligence, trigger an OTP for that account, brute-force the code, and log in.

A Hacker News commenter, buildbot, asked the obvious follow-up question:

So basically anyone who used this CA is screwed if someone knows your email?

That question is not answered definitively in the source material. The post asserts the capability; it does not publish a per-account success rate or a list of confirmed compromises.

Caveats and unresolved details in the source

Several details in the discussion are worth flagging rather than smoothing over:

A numeric discrepancy in the demo. Commenter hoherd observed: "The number the tool found was 1861. The e-mailed OTP code was 1858. What am I missing?" The source does not resolve this, so the demo's exact output should not be treated as fully verified.
An unexplained prior incident. The post opens by asking whether readers still trust eMudhra "after the 4 incident." The source material does not describe what that incident was.
Scope of the claim. The bypass is described for the 1FA OTP login path. The post does not claim compromise of the certificate authority's signing infrastructure or of RSA private keys; it explicitly contrasts the finding with "a leaked ca cert key."

Context: eMudhra's position in the CA market

One Hacker News commenter, jttnr, linked to a separate discussion and wrote: "Oh man, good that they are leaving the CA business." Another, FLeXMurphy, commented that "Security represents less than 1% of their business." These are commenter characterizations, not statements from the post itself, but they frame why the disclosure landed as hard as it did.

Why this class of bug keeps recurring

Three design decisions combine to produce this failure mode, and each is independently avoidable:

Treating a public key as a trust boundary. Encrypting a request body to a key that ships in client JavaScript protects against passive intermediaries. It does not authenticate the sender, and it must never be relied on as an access control.
Short numeric OTPs without server-side attempt limits. A six-digit or similarly small code space is only safe when the server enforces a strict cap on failed attempts, expires codes quickly, and invalidates a code after first use.
Bot mitigation standing in for rate limiting. A CAPTCHA or Turnstile challenge raises the cost of starting an attack. It does not raise the cost of continuing one.

Practical takeaways for anyone running OTP login

Rate-limit OTP verification per account, per IP, and per session, and lock the account or require re-authentication after a small number of failures.
Expire OTPs aggressively and invalidate them on first successful use.
Never treat client-side encryption to a published key as evidence that a request is legitimate.
Treat CAPTCHA and Turnstile as anti-automation friction, not as an authorization boundary.
Log and alert on verification attempt volumes, which is the signal that would have surfaced this attack immediately.

Community reaction

The Hacker News thread (155 points, 46 comments) mixed alarm with dark humor. Commenters asked whether the bypass enabled login to any account in eMudhra's infrastructure (tommica) and whether every user of the CA was exposed (buildbot). Others reached for jokes — baal80spam wrote that "'S' in 'eMudhra' stands for 'Secure'" — while cyberpunk summarized the mood as "Don't piss off the internet, there will be consequences."

A separate thread of comments concerned the hosting site rather than the vulnerability. bragr and gilrain both reported being served nonsensical text by the Mastodon instance, which gilrain attributed to an anti-scraping system and described as resetting their connection on repeat visits. That is a delivery problem for the write-up, not a fact about the vulnerability.