In short: Two security researchers bought "abandoned" domains — noreply.net and deleteduser.com — for less than $15 each, and immediately started receiving corporate emails from thousands of companies worldwide. One domain alone took in over 400,000 messages in 18 months: account passwords, medical data, hotel booking confirmations, security camera footage, and internal corporate communications. The culprit is a two-decade-old systemic mistake still affecting organisations globally.
What happened
On August 11, 2026, SecurityLab.ru and Western outlets including Digital Trends and SC Media published research by security investigators Cory Solovevich and Mike Sheward. Their experiment was straightforward: could they buy the domains that companies use as throwaway sender addresses — like noreply.net or deleteduser.com?
The answer was alarming. Solovevich registered noreply.net for a few dollars and had messages arriving within the hour. Over the 18 months leading up to publication, that single domain received more than 401,000 messages — around 700 per day — from organisations around the world. Sheward bought deleteduser.com, the domain many CRM platforms automatically substitute when a user account is deleted, and received mail from three separate companies within an hour of registering it.
Together, the pair purchased over 30 such domains to prevent malicious actors from acquiring them. They chose not to publish the full list for ethical reasons, but the scale of the problem they described is striking: thousands of automated systems worldwide are blindly sending sensitive data to addresses that nobody owned — until someone paid $15.
What was leaking
The types of data landing in the researchers' inboxes read like a fraudster's wish list:
- Passwords and login credentials: some notification systems duplicated account credentials in confirmation emails.
- Medical data: automated injury reports and insurance documents containing names and diagnoses.
- Booking details: hotel confirmation emails with guest names, addresses, and dates of stay.
- Security camera footage: corporate surveillance systems configured with a default "send to" address were forwarding clips and stills externally.
- Internal communications: service orders, equipment repair requests, student records from schools.
None of the end users whose data appeared in these emails made any mistake themselves. Their data wasn't stolen through an attack on their device — it was handed over by a systemic error on the sending company's side. The same pattern recurs with infostealer credential leaks: the threat often originates not from a direct attack on the user, but from poorly configured infrastructure at the service provider.
Why this keeps happening
The root cause is a two-decade-old bad practice. When a developer configures automated email sending, they often specify a throwaway sender address — noreply@something.com, [email protected], and so on. If the domain in that address is one the company doesn't actually own (noreply.net rather than noreply.their-own-domain.com), emails go to a third-party server.
Systems that auto-replace deleted users' email addresses are especially vulnerable. A CRM might substitute something like deleted_user_458@deleteduser.com when an employee leaves — and keep sending notifications to that address indefinitely, never checking who actually owns the domain.
The dangerous assumption: many developers believe that since nobody "needs" a domain like noreply.net, nobody will buy it. But domain registration costs $8–15 and is open to anyone. Companies have been leaking customer data this way for years and typically only find out when a researcher publishes their findings — if they find out at all.
What this means for you personally
If you've ever registered with a service that sent you confirmations or notifications, your data may theoretically be sitting in a stranger's inbox — not because of anything you did wrong, but because of a mistake the service made. This is especially worth considering for medical portals, online booking platforms, corporate HR systems, and banking applications.
The noreply-domain leak is a clear example of how privacy can be compromised not by attacking your device, but through carelessness in a company's infrastructure. Your traffic may be encrypted, your password strong — and your data may still end up in the wrong hands because a service sent a message to the wrong address. For practical privacy advice, visit our blog.
How to protect yourself
Minimise the data you share with services. The less information an organisation holds about you, the less can leak in incidents like this. Leave optional fields blank at sign-up wherever possible.
Use email aliases. Many privacy-focused email providers support creating unique aliases for each service you sign up to. If one alias leaks, only that service is compromised — not your primary inbox.
Monitor for breach notifications. Tools like HaveIBeenPwned let you check whether your email address has appeared in known data dumps.
Encrypt your traffic on untrusted networks. A VPN won't fix errors on someone else's server, but it closes a different threat vector: interception of your traffic on public Wi-Fi, where third parties can see which services you use and what data you transmit. LiMP VPN is a no-logs service for iOS and Android — explore the features and plans.
Who is responsible
Technically, the companies sending the emails. Data protection laws in most jurisdictions require operators to take technical measures to protect personal data from unauthorised access. Sending data to an unverified address with a third-party domain does not meet that standard. In Europe the same behaviour violates GDPR's data minimisation principle.
In practice, few affected users ever learn of the incident, and the companies responsible rarely receive any notification unless the researcher contacts them directly — which is precisely what Solovevich and Sheward do: they collect data and notify organisations through responsible disclosure, the standard practice in the security research community.
Sources
This report is based on: SecurityLab.ru (August 11, 2026), Digital Trends, SC Media.