Skip to content
CyberTemp
All posts
After the 6.8B email leak: rotate addresses, not passwords

After the 6.8B email leak: rotate addresses, not passwords

CyberTemp6 min read

An attacker posted a database of 6.8 billion email addresses online this month, with researchers estimating roughly 3 billion are real and active. The dump cross-references logins to Apple, Google, GitHub, Telegram, government portals — basically every consumer surface a single person touches. If your main address is in there (and statistically, it is), the fix isn't a new password. It's a different address for every door.

What's actually in the dump

Reports across the week put the headline number at 6.8 billion records, sourced from a long-running infostealer compilation rather than a single fresh breach. The relevant detail isn't the total — it's the shape. Each record ties an address to one or more services and, often, a stale credential. Even where the credential has been rotated, the address is now confirmed-valid and pre-mapped to specific platforms. That mapping is the part attackers actually pay for: a verified consumer's email plus a hint of which products they use is worth more than another generic spam list.

That same week, Instructure's Canvas platform leaked about 275 million student records (emails plus IDs), an NVIDIA GeForce NOW partner in Armenia exposed an account database, and the LexisNexis incident is still spilling files. The 6.8B compilation is just where this week's leaks will end up next quarter. Treating any one breach as a discrete event misses the pattern: the address you've used since 2014 is a single, persistent identifier across a dozen of these dumps now.

Why rotating passwords doesn't solve this

Password rotation is the reflex everyone reaches for after a breach headline. It's also mostly theater. A password change locks an attacker out of that one service with that one credential. It does nothing about:

  • Credential stuffing against every other site you used the same address on.

  • The pre-built address-to-service map that's now in the compilation.

  • Phishing that lands in the address attackers know you actually read.

  • Spam-list resale — your address is the product, not the password.

The address is the persistent identifier. Until you change that, you're playing whack-a-mole every quarter when the next compilation surfaces.

The per-service burner pattern

The pattern is simple and old: give every service its own address. When something leaks, you know exactly which service leaked it, you can deactivate that specific channel, and you've contained the blast radius to one signup.

The hard part has never been the concept. It's the operational tax: managing a hundred addresses across a hundred services, remembering which one belongs to which login, and retrieving verification codes without juggling tabs. That's the bottleneck a temp-mail service built for automation actually solves — not the "I need a one-off address for a download" use case, which any free page handles fine.

The practical breakdown:

  • Throwaway addresses for one-shot signups (downloads, trials, "verify to read the article" walls). Inbox lives long enough to grab the code, then expires.

  • Named persistent burners for services you actually use but don't trust. amazon-2026@…, linkedin-2026@…. Forward to your main, retire when one starts pulling spam.

  • API-generated inboxes for anything programmatic — CI signups, multi-account workflows, scrape-then-verify pipelines, automated QA.

For the first category, a generic temp-mail page works fine. For the second, a forwarding burner like the ones built into most password managers covers it. The third is where free pages stop being useful and an actual API matters.

Wiring it into a real signup flow

CyberTemp's flat endpoint structure makes the third category cheap. There's one endpoint that both creates and reads an inbox (GET /getMail?email=... — the inbox is implicitly created on first read), so you don't need a setup phase. A complete "create, sign up, wait for the OTP, return it" loop in Python:

import httpx, re, time

API_KEY = "tk_..."
HEADERS = {"X-API-Key": API_KEY}
BASE = "https://api.cybertemp.xyz"

def burner_for(service: str) -> str:
    addr = f"{service}-{int(time.time())}@cybertemp.xyz"
    httpx.get(f"{BASE}/getMail", params={"email": addr}, headers=HEADERS)
    return addr

def wait_for_otp(addr: str, timeout: int = 90):
    deadline = time.time() + timeout
    while time.time() < deadline:
        r = httpx.get(f"{BASE}/getMail", params={"email": addr}, headers=HEADERS)
        for msg in r.json():
            m = re.search(r"\b(\d{4,8})\b", msg.get("body", ""))
            if m:
                return m.group(1)
        time.sleep(3)
    return None

addr = burner_for("newsletter")
# ...trigger signup with `addr`...
code = wait_for_otp(addr)

One endpoint, one header, two functions. The first read against a fresh address implicitly provisions the inbox, so there's no setup phase to manage. The Go SDK wraps the same loop in a single WaitForOTP call (PRO tier and up) — polling, regex extraction, and timeout handling all in one blocking call so your code stays focused on the signup flow itself. The Python equivalent is just the ~15 lines above; no SDK needed for the common case.

One thing worth doing: name your burners after the service, not just a random string. [email protected] tells you instantly which signup leaked the address when (not if) it surfaces in a future compilation. A random hex string tells you nothing.

When a burner is the wrong tool

This isn't a "use temp mail for everything" post. There's a short list of accounts where a throwaway address is actively harmful:

  • Banking and government. You need the audit trail, the recovery path, and an address that won't expire mid-investigation.

  • Anything that ties to your legal identity — tax, insurance, healthcare. Use a real address you control for years.

  • Two-factor recovery for your primary accounts — your password manager and your email provider themselves. Recovering those is the whole game.

  • Anything you'd hate to lose access to. If the inbox is the only path back into the account, the temp lifetime works against you.

For everything else — newsletters, trials, "create an account to read this," forums, marketplaces, anything that asks for an email before it's earned it — the per-service burner is the predictable choice.

Bottom line

The 6.8B dump isn't a one-time event to react to. It's the steady-state of how email addresses get aggregated, and there will be a larger compilation next year. Password rotation is the wrong layer to defend at. Address rotation is the right one.

Throwaway addresses for one-shots, named persistent burners for accounts you keep, API-generated inboxes for automation. CyberTemp covers all three. For the simple case — one-off signups, "verify to read this" walls, newsletter trials, "I'll never visit this site again" downloads — just open cybertemp.xyz, generate an inbox in the browser, paste the address into the form, and watch mail arrive in seconds. No signup. No install. No account to create. You can do the per-service-burner pattern in the browser without writing a line of code, picking the local part you want to remember (amazon-2026@…) and rotating addresses when one starts pulling spam.

If you're scripting against signups — testing pipelines, multi-account workflows, automated QA, scrape-then-verify flows — the paid tiers are where the per-key request limits stop being the bottleneck and where the OTP-extraction helpers in the Go/Rust SDKs start paying for themselves. Sign up if that's you.

For the broader why, the privacy fundamentals post covers the long-form case. If you're choosing between providers for an automation use case specifically, the CyberTemp vs DraxonMails comparison is the more useful read.

Share