I locked unlimited subdomains on a SaaS platform without even finishing registration — and the…

I locked unlimited subdomains on a SaaS platform without even finishing registration — and the… | by BugWraith (Lokesh) - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original I locked unlimited subdomains on a SaaS platform without even finishing registration — and the… A ghost tenant, a broken registration flow, and a permanently blocked namespace. Welcome to SaaS logic bugs BugWraith (Lokesh) Follow ~4 min read · March 29, 2026 (Updated: March 29, 2026) · Free: Yes Wait, What? You know that satisfying moment when you pick a username and it says "already taken"? Annoying, right? Now imagine an attacker sitting at home, running a script, and permanently stealing thousands of subdomains — without ever creating a real account. No login. No email verification. No working account. Just vibes… and a permanently reserved subdomain. That's exactly what I found. A Little Background: How SaaS Subdomains Work Most SaaS platforms give each customer their own subdomain when they register. Something like: yourcompany.example.com This subdomain is your tenant's identity — it's how your team logs in, how clients find you, and how the platform identifies your organization. Now here's the important part: that subdomain has to be unique . Once it's taken, nobody else can use it. Ever. So what happens if a subdomain gets "taken" by an account that doesn't actually exist? The Bug: Ghost Tenants During the account registration flow, the platform reserves your chosen subdomain in the backend before completing email verification or account activation. Normal? Kind of. Most platforms do this to avoid race conditions. The problem? If registration fails — for any reason — the subdomain stays reserved. Permanently. The account is a ghost: Login doesn't work Password reset email never arrives The account cannot be accessed or recovered But visit ghost-subdomain.example.com ? You get: "Account is currently unavailable." The namespace is gone. Forever. For everyone. How I Found It (PoC) The steps are embarrassingly simple: Go to the registration page. Fill in account details and pick a unique subdomain (e.g., google-7-1 ). Intercept the registration response using Burp Suite. Modify any value in the response and forward it. The UI throws an error — "Something went wrong." Try logging in with those credentials → "We can't find an account with this combination." Try password reset → No email received. Now try registering again: Same email + same subdomain → "Subdomain already taken" Different email + same subdomain → "Subdomain already taken" 9. Visit the subdomain URL → "Account is currently unavailable." The subdomain is permanently locked. The account doesn't exist. I tested this with 5 subdomains in a row — google-7-1 through google-7-5 — all locked, all dead, all gone. And that was just manual testing. The platform had no rate limiting and CAPTCHA auto-verified , meaning this could be automated at scale. Unlimited subdomains. Permanently squatted. No real account required. The Real Impact This isn't just a quirky bug. Think about what an attacker can do: Brand squatting — Lock nike.example.com , apple.example.com , google.example.com before those companies register. Competitor sabotage — Reserve a competitor's brand name so they can't use the platform. Automated exhaustion — Script it, run it overnight, lock thousands of meaningful subdomains. No accountability — Since no real account is created, there's no identity tied to the attack. The barrier to exploitation? Nearly zero. What the Triage Said The program closed the report citing their DoS exclusion policy — since the impact involved "disruption of service resources," they classified it under denial of service and marked it out of scope. Respectfully — this isn't a DoS. DoS is about overwhelming a service with traffic until it goes down. This is a business logic flaw : the registration flow permanently commits a resource before validating the account, with no cleanup mechanism. The subdomain isn't disrupted — it's silently stolen . The distinction matters. But the report was closed, so here we are. Takeaway for Bug Hunters If you're hunting SaaS platforms, always check: Does the platform reserve a resource (subdomain, username, tenant ID) before completing verification? What happens if registration is interrupted or manipulated mid-flow? Is there a cleanup mechanism if account creation fails? Can the reserved resource be claimed back? These registration logic flaws are underrated and often slip through triage because they don't fit neatly into a CVE category. They're not XSS. They're not SQLi. They're business logic — and that's exactly why they get missed. Found something interesting? Connect with me on LinkedIn or check out my other writeups. — BugWraith #bug-bounty #cybersecurity #business-logic-error #p3 Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).