From Email Reuse to Org Takeover: How a JWT Flaw Exposed Multiple Subdomains

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 JWTs
• A shared API for multiple tenants
• A client-supplied Source header to differentiate subdomains

These 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.

SaaS Architecture Overview

The application structure was multi-tenant, segmented by subdomain:

• b-one.target.com
• b-two.target.com

Both routed to a central API:

api.target.com

A custom HTTP header handled tenant separation:

Source: B-One

No 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.

Discovery: Duplicate Emails, Duplicate Tokens

We registered the same email twice on different subdomains:

1. Signup on B-One:

POST /users/sign-up
Host: api.target.com
Source: B-One
{
  "email": "[email protected]",
  "password": "P@ssWord123"
}

1. Signup on B-Two:

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.

Exploitation: Cross-Tenant Identity Injection

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-One

The 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.

Escalation: From Email to Admin Dashboard

After successful user impersonation, we escalated further:

• Searched for public admin emails tied to the platform via Google, GitHub, WHOIS
• Repeated the same trick: register admin email on B-Two → get JWT → use it on B-One

Result? Full admin access across the platform. We could:

• View all user accounts
• Reset credentials
• View internal logs and configurations
• Access client billing and support data

Tools We Used

• Burp Suite – Modify tokens and spoof headers
• Postman – Automate token replay across headers
• JWT.io – Decode and inspect token claims
• Firefox Dev Tools – Real-time header manipulation
• OSINT – Find real users/admin emails to exploit

Why This Happened

1. JWT Validation by Email

Tokens were validated using the username field instead of a secure sub (subject) or ID. Emails can be duplicated or spoofed across tenants.

2. No Email Verification

Anyone could register any email address. This removed the ownership validation layer entirely.

3. No Tenant-Bound Claims

Tokens lacked any tenant_id, aud, or scope to restrict where they could be used.

4. Trusted Source Header

The backend used a client-controlled Source header to segregate tenants. Without cryptographic enforcement, this became a trivial bypass vector.

How to Fix It (The Right Way)

Identity & Claims

• Validate tokens by sub or a unique ID—not email or username
• Enforce email verification before activating sessions
• Add tenant context inside the JWT (tenant_id, aud, or scope)

Token Management

• Sign JWTs with tenant-specific keys or include tenant IDs in HMAC validation
• Rotate keys regularly and monitor for anomalies

Access Controls

• Never trust user-supplied headers like Source for security decisions
• Match the token's tenant ID against the backend context
• Log and alert on cross-tenant token reuse

Timeline of Events

• Mar 14, 2025 – Dual email registration test succeeded
• Mar 15, 2025 – Cross-tenant token injection confirmed
• Mar 16, 2025 – Admin account hijack successfully executed
• Mar 17, 2025 – Report submitted to the client with POC
• Mar 22, 2025 – Patch issued, token validation refactored

Frequently Asked Questions (FAQ)

Q: 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.

References

• RFC 7519: JSON Web Token

What to Do Now

• Review your token issuance and validation logic
• Enforce email verification as a baseline control
• Reject or verify all client-supplied tenant indicators
• Create test cases that simulate token reuse across tenants
• Schedule a tenant-segmentation red team test

Get the Checklist & Visual Flowchart

Download our JWT Security Checklist PDF and subscribe for the upcoming exploit flowchart.

Let DeepStrike Find the Flaws Before Attackers Do

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.