How I Created an Account Named "NULL" and Started Receiving Other Users' Domain Purchase Notifications
A security researcher created an account with the username "NULL" on a domain registrar and began receiving hundreds of email notifications about domain purchases made by other users, due to a classic null-value handling bug.
Editor's Context
This article is an English adaptation with additional editorial framing for an international audience.
- Terminology and structure were localized for clarity.
- Examples were rewritten for practical readability.
- Technical claims were preserved with source attribution.
Source: the original publication
Disclaimer: This article is purely informational and is not intended as instructions or encouragement to commit unlawful actions. We are all here to learn and share stories.
Hello everyone. My name is Anya (SavAnna), I work as an AppSec engineer at ATI.SU and do bug bounties as a hobby. Bug bounty is a great way to take a break from your own services and shift your focus from "defense" to "offense." Bugs aren't always found on purpose — sometimes it happens by accident. I want to show that many strange and simple bugs can be found by anyone.
As a Preface and Acknowledgment
I really love Timeweb's bug bounty program. Searching for bugs and interacting with their security team is a pleasure. They are doing great work and have grown a lot since launch.
The Bug Story
When registering for services, the username is created automatically. A feature was introduced to change your login name. I filed bugs there, but unfortunately they already knew about them. I received "Duplicates." But I was left with an account where username="NULL".
Six months passed since the testing.
And I started receiving emails. A lot of emails.
Over the course of a few days, my inbox was flooded with messages. I didn't immediately understand what was happening.
At first I thought the developers were testing a fix on the account mentioned in another report I had filed in this program. Looking more closely, I realized this was only happening with the account named "NULL." I checked via whoami and discovered that the messages were arriving by date after domain purchases or renewals. I logged into the account to check whether these domains had appeared under my management — no, these were just email messages that were apparently being duplicated to my account.
And so, by pure accident, a low-impact bug was found and reported.
What Was the Cause?
The developer commented that there were 2 causes:
- The portal started sending
nullinstead of the client's login "null" - Insufficient validation in the notification sending process
Since I was testing the service using a black-box approach, I can only speculate that there was possibly a system mailbox where all notifications were sent if the user was not found for whatever reason, and my account — due to a conditional error — became that destination.
Link to the Disclosed Report
https://bugbounty.bi.zone/reports/5077
Old News — This Has Happened Before
A similar report was submitted to QIWI: https://hackerone.com/reports/487296
A similar story also happened to American security researcher Joseph Tartaro, when he decided to make his license plate read "NULL" and started receiving traffic tickets for all cars with unrecognized plates.
Conclusion
- Some bug bounty bugs are found by accident — the key is to notice them in time
- These kinds of amusing validation errors do happen
- "null", "nil", "undefined", "NULL", "None" sometimes get converted into actual
null,nil,undefined,NULL,None— and they are worth using as entity names during testing
Why This Matters In Practice
Beyond the original publication, How I Created an Account Named "NULL" and Started Receiving Other Users' Domain Purchase Notifications matters because teams need reusable decision patterns, not one-off anecdotes. A security researcher created an account with the username "NULL" on a domain registrar and began receiving hundreds of email notifications...
Operational Takeaways
- Separate core principles from context-specific details before implementation.
- Define measurable success criteria before adopting the approach.
- Validate assumptions on a small scope, then scale based on evidence.
Quick Applicability Checklist
- Can this be reproduced with your current team and constraints?
- Do you have observable signals to confirm improvement?
- What trade-off (speed, cost, complexity, risk) are you accepting?
FAQ
What is this article about in one sentence?
This article explains the core idea in practical terms and focuses on what you can apply in real work.
Who is this article for?
It is written for engineers, technical leaders, and curious readers who want a clear, implementation-focused explanation.
What should I read next?
Use the related articles below to continue with closely connected topics and concrete examples.
