The Day “eh” Opened Hotmail: Inside 1999’s Wildest Webmail Breach

Hotmail’s 1999 “eh” flaw briefly let anyone open almost any inbox by entering the literal password “eh”, making it one of the most sweeping webmail security lapses of the early internet and a defining case study in broken authentication.

How the hole worked

Contemporary reports describe a logic bug in a Hotmail login script nicknamed “start” that accepted crafted parameters and effectively bypassed password checks when the string “eh” was supplied, allowing session creation for arbitrary accounts.

Security write-ups at the time alternately framed it as a leftover maintenance/backdoor pathway or a brittle CGI flow that trusted hidden form fields and URLs, but Microsoft publicly rejected the “backdoor” claim.

Discovery and disclosure

A small collective calling itself Hackers Unite said it tipped Swedish media to the vulnerability to spotlight lax security and Microsoft’s outsized influence over internet services in 1999, emphasizing protest over profiteering. Multiple sites quickly mirrored simple web forms that automated the exploit, turning a handful of HTML lines into point‑and‑click account access for non‑experts.

Scope and timing

Hotmail had roughly 50 million users by summer 1999, so the potential exposure covered essentially the entire platform during the window before patches fully propagated. Some accounts suggest exploit pages may have existed as early as June 1998, but the “everyone can log in with ‘eh’” moment hit global headlines in late August 1999, when it became widely and trivially reproducible.

Microsoft’s containment

Microsoft said engineers began remediation within hours of notification, pushing an initial fix in the morning and then closing a related variant later the same day while manually verifying every server in the fleet. Company spokespeople stressed that the flaw was neither intentional nor tied to Passport single sign‑on, even as some outside analysts speculated about legacy or non‑production code left exposed.

Why “eh” mattered

The incident showed how a tiny authentication logic slip - trusting client-side parameters, using hidden alternate scripts, or skipping a definitive password check can escalate into a platform‑wide compromise. Because the exploit needed no malware or advanced tooling, the barrier to abuse was almost zero, amplifying reputational impact and public awareness far beyond typical server‑side bugs of the era.

Lasting lessons

1. Authentication must be centralized, server‑side, and unskippable: no hidden code paths, no parameter-based bypasses, and no legacy scripts reachable in production.
2. Defense in depth is essential: robust input validation, least-privilege session handling, feature flags that isolate non‑production code, and automated configuration verification across every host.
3. Rapid, audited incident response matters: detect, patch variants, verify propagation, and communicate clearly to reduce both technical and trust fallout.