# Chaining Auth0 Misconfigurations for 1-Click Account Takeover

Deep Dive into a Subtle Auth0 Misconfiguration Leading to Full Account Takeover

---

## Introduction

This post documents a **critical 1-click Account Takeover (ATO)** vulnerability discovered in an application using [Auth0](https://auth0.com?utm_source=chatgpt.com) for authentication.

By chaining:

* A **hidden, enabled** `Username-Password-Authentication` connection,
    
* A **Cross-Origin Authentication configuration**, and
    
* A **custom account-merging implementation** during token exchange
    

I was able to gain **full access to a victim’s primary account** (originally created via social logins or Passwordless) with only **one click** from the victim.

This vulnerability highlights how subtle misconfigurations in identity providers like Auth0 can lead to serious security risks.

---

## Inside Auth0: A Technical Breakdown

Let's understand two important things to grasp how the vulnerability works.

### 1\. Connections and User Profiles

In Auth0, each authentication method (social login, passwordless, username/password, etc.) is represented as a **connection**.

* Each connection creates a **separate profile** in the Auth0 tenant, even if the email is the same.
    
* Profiles are identified by a `user_id` that includes the connection name.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756725280919/2de05520-8b60-4145-a1f1-71c859854b5e.jpeg align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756968395185/c42450ec-0ccb-4172-951e-17e278902192.png align="center")

### 2\. Cross-Origin Authentication

While reviewing the authentication flow of the application, I noticed that the user-facing login options are limited to **social logins** and **passwordless authentication**. However, a deeper inspection revealed that the application also leverages Auth0’s **Cross-Origin Authentication** feature, specifically via the `POST /co/authenticate` endpoint. This endpoint allows credentials (username and password) to be sent directly to the Auth0 tenant (e.g., [`auth.nykros.com`](http://auth.nykros.com)), and in response, it issues authentication cookies — including the `auth0` session cookie, which represents the logged-in user session.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756724901977/f6bb0b9d-37be-490a-973e-87a745feccd6.png align="center")

---

## Vulnerability Overview

The ATO was made possible by **three chained weaknesses**:

1. **Hidden Username-Password-Authentication Connection**
    
    * The tenant allowed signup via email/password through `Username-Password-Authentication`, even though this option was not visible in the app’s UI.  
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756968669870/531eef0f-1ad1-475a-8ccf-91a55044c26d.png align="left")
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756725411706/4134a564-ac94-4057-a28f-4584b7c1f566.jpeg align="center")
        
    
2. **Account Merging Logic**
    
    * During the token exchange, the custom Auth0 Action checked the email associated with the code. If the email was linked to multiple profiles, it treated them as a single account and issued a token for the original account (the first account created).
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756969579237/becd79eb-fd92-454d-94ab-127fbe2cfb0a.png align="center")
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756725464700/f78fadfd-f87f-4639-a349-c3f94e00abec.jpeg align="center")
        
3. **Cross-Origin Authentication**
    
    * Enabled `co/authenticate` allowed the attacker to log in using their chosen password, bypassing UI-based restrictions and acquiring a full Auth0 session.
        

---

## Detailed Exploitation Walkthrough

This section demonstrates each step with **raw HTTP requests** captured in Burp Suite.

### Step 1: Discover Hidden Connections

The app had no visible way to register or log in using email and password. However, I discovered an Auth0 endpoint exposing the valid and available database connections — which is required to craft direct API requests.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756726070171/517ab800-69fd-4c6c-bba4-101329e27972.png align="center")

### Step 2: Create an Account with Victim’s Email

Using the `/dbconnections/signup` endpoint, an attacker creates a password-based account for the victim’s email.

**Request:**

```yaml
POST /dbconnections/signup HTTP/2
Host: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "email": "vic@nykros.com",
  "password": "AttackerPass123!",
  "connection": "Username-Password-Authentication",
  "user_metadata": {}
}
```

**Response:**

```yaml
{
  "_id": "XXXXXXXXXXXXXXXXXXXXXXX",
  "email": "vic@nykros.com",
  "email_verified": false
}
```

Auth0 sends a verification email. If the victim clicks the link, the attacker can then log in to their account without being prompted for email verification.

It’s highly likely the victim will click the link because their account was originally created using **Passwordless** or **Social Login** methods, neither of which requires email confirmation during signup. When the attacker registers a password-based account with the same email, Auth0 triggers a **generic verification email** that simply states, “Since you have an account, please verify your email.” Given that the victim has never seen a verification step before and the message appears legitimate, they are very likely to comply and click the link, unknowingly verifying the attacker-controlled account.

---

### Step 3: Login via Cross-Origin Authentication

With the victim’s email verified, the attacker sends credentials to `/co/authenticate`.

**Request:**

```yaml
POST /co/authenticate HTTP/2
Host: auth.nykros.com
Origin: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "username": "vic@nykros.com",
  "password": "AttackerPass123!",
  "credential_type": "http://auth0.com/oauth/grant-type/password-realm",
  "realm": "Username-Password-Authentication"
}
```

**Response:**

```yaml
{
  "login_ticket":"VkB82KWVEEQ8MYA4I6PQD-kNc0U_1bPx",
  "co_verifier":"leEMJtSeoWf3UHuwLmVUpJKOEl72D86O",
  "co_id":"O4GhzYzSKWQs"
}
```

The attacker receives an **Auth0 session cookie**:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1756726601571/41fc5da0-6dc4-47e8-8195-22a541b86cab.png align="center")

### Step 4: Full OAuth Authorization Flow

The attacker loads the target login page and uses **Burp Suite** to intercept and replay login requests, injecting the stolen `auth0` session at key points in the login flow (e.g., `/authorize`, `/continue`, `/authorize/resume` requests).  
By maintaining the attacker-controlled session through these steps, the application fully authenticates the attacker as the victim.

* **Result:**  
    The attacker gains **full access to the victim’s account** on the application, despite the victim never setting a password or explicitly enabling password-based login.
    

---

## Finally

> *Thanks for reading! If anything wasn’t clear or you’d like more details, feel free to reach out — I’d be happy to explain further.*