The Staging Subdomain You Forgot About Is Still Online (And Still Logged In)
Every domain that's been around for more than a year has subdomains nobody remembers creating. staging.yourcompany.com from a redesign in 2023. test-api.yourcompany.com someone spun up for a two-week trial of a new backend. old-app.yourcompany.com that was supposed to be decommissioned when the new one shipped and never was.
None of these show up on your homepage. None of them are linked from anywhere. And that's exactly why they're dangerous, nobody's looking at them, but they're still online, still resolving, and often still running whatever version of the app or its authentication was live the day everyone stopped thinking about it.
Why staging environments are worse than production
Staging and test environments exist specifically so people can break things without consequences, which means they're built with that assumption baked in. It's extremely common to find:
- Default or weak admin credentials that were "temporary until launch"
- Authentication disabled entirely, because it was annoying during active development
- Debug modes left on, which often means verbose error messages that reveal internal file paths, database structure, or stack traces
- An older, sometimes vulnerable version of the same codebase running in production, if the staging environment was frozen after the last deploy that mattered to whoever was using it
A production site with solid security can still be fully compromised through a staging subdomain running a version of the same app from eight months ago, sharing the same database, the same session infrastructure, or the same underlying credentials.
How attackers find these before you do
This is the part that surprises most people: finding subdomains doesn't require guessing. Certificate Transparency logs are public by design, every SSL/TLS certificate ever issued for any subdomain of your domain is permanently recorded and searchable. An attacker (or an automated tool) can query these logs in seconds and get a full list of every subdomain that's ever had a certificate issued for it, including the ones you forgot existed.
Combine that with DNS brute-forcing against common subdomain names (staging, dev, test, old, api-v1, admin) and most organizations' full subdomain footprint is discoverable within minutes, using entirely free, entirely legal, publicly available tools. There's no hacking involved in the discovery step. The hacking, if it happens, starts once they find something live that shouldn't be.
What we typically find
Across the sites we scan, subdomain-related findings tend to fall into a few repeating patterns:
- A staging environment with an exposed, unauthenticated admin login
- An old marketing or landing page subdomain still resolving, sometimes still pointing at a third-party service the company no longer uses, which opens the door to subdomain takeover (where an attacker claims the abandoned service and now controls content served from your domain)
- A test API subdomain with CORS wide open and no rate limiting, happily answering requests from anywhere
- SSL certificates that expired months ago on subdomains still receiving traffic, silently training users and browsers to click through security warnings
How to check your own footprint
A full manual audit means pulling Certificate Transparency logs (crt.sh is a free, public tool for this), cross-referencing against your DNS provider's full record list, and checking each result manually for what's actually still live and what it exposes. It's genuinely useful to do once, but it's the kind of task that gets skipped because it's tedious and easy to defer indefinitely.
Decloak's subdomain discovery (part of the full agent scan) automates this: it enumerates your subdomains, checks which are still live, flags DNS and TLS issues on each one, and surfaces anything that looks like a forgotten staging environment or an expiring certificate, without you needing to know what Certificate Transparency logs are.
The fix is almost always the same
- Inventory everything. Pull your full subdomain list from your DNS provider and from Certificate Transparency logs, and compare.
- Kill what you don't need. If a subdomain isn't serving a current purpose, remove the DNS record and decommission whatever it points to. Don't just leave it "unlinked", unlinked isn't unreachable.
- Lock down what you keep. Staging environments that genuinely need to stay up should sit behind authentication or an IP allowlist, not rely on obscurity as their only defense.
- Set a recurring check. New subdomains get created constantly as teams spin up test environments and forget to tear them down. A one-time cleanup doesn't stay clean; this is exactly what scheduled scans are for.
The uncomfortable truth about subdomains is that almost nobody finds them until either a security scan or an attacker does, and only one of those outcomes is good for you.
Decloak's full agent scan enumerates subdomains, checks DNS and TLS posture, and flags forgotten environments automatically. See what a full scan finds →