February 12, 2025
A real-world penetration testing case study showing how weak JWT validation, missing email verification, and subdomain misconfigurations led to full organizational compromise.
Ahmed M. Arafat
A SaaS platform exposed itself to full organizational compromise due to insecure JWT validation (based on email), a lack of email verification, and a spoofable Source header used for tenant routing. This allowed attackers to reuse tokens across subdomains and escalate to admin control. Learn how we exploited this flaw in a real-world red team engagement, how to fix it, and how to future-proof your architecture.
In this case study, we break down a real vulnerability found during a red team engagement that started with a duplicated email registration and ended in a full admin takeover.
The target? A SaaS provider that assumed the following were safe:
email as an identifier in JWTsSource header to differentiate subdomainsThese assumptions led to a silent, yet critical architectural security flaw. This walkthrough documents exactly how we exploited the flaw, which tools we used, and how teams can design better safeguards from the start.
The application structure was multi-tenant, segmented by subdomain:
b-one.target.comb-two.target.comBoth routed to a central API:
api.target.comA custom HTTP header handled tenant separation:
Source: B-OneNo cryptographic binding existed between the token and the tenant. No access control validation occurred on the server side to verify that a token issued to B-Two was being used on B-One. This was the Achilles' heel.
We registered the same email twice on different subdomains:
POST /users/sign-up
Host: api.target.com
Source: B-One
{
"email": "[email protected]",
"password": "P@ssWord123"
}POST /users/sign-up
Host: api.target.com
Source: B-Two
{
"email": "[email protected]",
"password": "P@ssWord123"
}Both registrations succeeded. Each one returned a different JWT, yet both shared the same username (email):
{
"iat": 1704719426,
"exp": 1704723026,
"username": "[email protected]",
"id": "960912"
}This revealed that the application logic was identifying users via username, not sub or a unique ID. JWT trust was based entirely on an email string.
Armed with a JWT from B-Two, we made a request to B-One:
GET /user/me
Host: api.target.com
Authorization: JWT <B-Two token>
Source: B-OneThe API returned the profile of the B-One user with the matching email. The token wasn't scoped to the tenant, and the backend trusted the Source header as-is.
What should have been isolated access per tenant became cross-tenant access based on email reuse.
After successful user impersonation, we escalated further:
Result? Full admin access across the platform. We could:
Tokens were validated using the username field instead of a secure sub (subject) or ID. Emails can be duplicated or spoofed across tenants.
Anyone could register any email address. This removed the ownership validation layer entirely.
Tokens lacked any tenant_id, aud, or scope to restrict where they could be used.
The backend used a client-controlled Source header to segregate tenants. Without cryptographic enforcement, this became a trivial bypass vector.
Identity & Claims
sub or a unique ID—not email or usernametenant_id, aud, or scope)Token Management
Access Controls
Source for security decisionsQ: Could this happen with Firebase/Auth0?
Yes. If the platform relies on email claims and lacks tenant-bound scopes or keys, it's vulnerable to similar exploits.
Q: Should I use 'email' in a JWT?
Only as a reference field. Never use it for access control or session validation. Always use sub or a UUID.
Q: Can I trust custom headers?
Not unless you're cryptographically verifying them. Headers can be spoofed by anyone with access to curl/Postman/Burp.
Q: What’s the best practice for multi-tenant tokenization?
Use separate keys, enforce tenant claims in access checks, and ensure backend logic maps tokens to the correct tenant context.
Download our JWT Security Checklist PDF and subscribe for the upcoming exploit flowchart.
If you're building a SaaS or multi-tenant platform, DeepStrike’s red team can help uncover flaws that slip past standard code reviews. Our team combines attacker mindset with architecture insight.
Book an engagement → DeepStrike.io
Stay sharp. Stay secure.