Alongside building Myrad, I still spare weekends on independent security research and this turned out to be one of my best findings, on a well known bank I can't name.
The Finding
The application had a different authentication flow in the main app. While digging, I noticed it was still using Auth0.
And if you've worked with Auth0 before, you know one thing:
There's a default signup endpoint (Which was not the current flow of the app)
So I thought, why not try it.
The Try
Auth0 exposes:
POST /dbconnections/signup
I reused a valid client_id and sent a request:
curl -X POST https://<auth-domain>/dbconnections/signup \
-H "Content-Type: application/json" \
-d '{
"client_id": "CLIENT_ID",
"email": "test@attacker.com",
"username": "testuser",
"password": "Admin@123",
"connection": "Username-Password-Authentication",
"credential_type": "http://auth0.com/oauth/grant-type/password-realm"
}'Response came back 200.
Account created.

At that point, nothing special. Could just be a public signup.
Dead End… Almost
For a few days, nothing came out of it.
The creds just sat there.

Bing Did Its Thing
Switched to recon mode.
Started using Bing dorks to find anything indexed but not linked.
> And then I hit a dashboard
> A completely separate portal
> Used the same credentials
And it worked
The Goldmine
This wasn't meant for public users.
Inside, I had access to their customer records including:
- Company names
- Internal scoring data
- CR / registration numbers
- Sector and SME classification
- Number of employees
- Company emails and phones
- Revenue ranges
- Full company profile details
Straight up PII and business-sensitive data.
What Happened
- Auth0 signup endpoint was publicly accessible
- No restriction on account creation
- Created accounts were treated as valid internal users
- No authorization checks on the dashboard
Final Takeaway
Sometimes you don't need an exploit.
Just knowing how a service works is enough.
A default Auth0 endpoint + a bit of dorking + persistence
That's all it took.