> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

> CVE-2018-6873: Details about a security vulnerability identified in the Auth0 authentication service

# CVE-2018-6873: Security Vulnerability in the Auth0 Authentication Service

**Published**: April 4, 2018

**CVE number**: CVE-2018-6873

**Credit**: [Cinta Infinita](http://www.cintainfinita.com/)

## Overview

A vulnerability was identified in the Auth0 authentication service. It affected all Auth0 tenants, and was patched on October 15th, 2017 within four hours of report for all public cloud customers. This notice is informational and is intended to explain the vulnerability and the mitigation taken.

As part of an user authentication flow employed by the Auth0 service, a <Tooltip tip="JSON Web Token (JWT): Standard ID Token format (and often Access Token format) used to represent claims securely between two parties." cta="View Glossary" href="/docs/glossary?term=JSON+Web+Token">JSON Web Token</Tooltip> (JWT) is passed to the `/login/callback` endpoint identifying the user. This token contains a reference to which <Tooltip tip="Audience: Unique identifier of the audience for an issued token. Named aud in a token, its value contains the ID of either an application (Client ID) for an ID Token or an API (API Identifier) for an Access Token." cta="View Glossary" href="/docs/glossary?term=audience">audience</Tooltip> - an Auth0 tenant - it is intended for. A flaw in the Auth0 service did not properly validate this audience, and therefore allowed tokens intended for one tenant to be used at another. Further, the custom database functionality available to all Auth0 tenants allows for authenticated tokens to be generated with any desired identifier. Therefore, could an attacker learn the user identifier of an intended victim at a target tenant - which is generally considered public information - they could construct a token with that identifier. Due to the improper audience checking the target tenant would accept it, and establish a login session recognizing the attacker as the victim. This allowed for privilege escalation, among other possible attack vectors.

A specific concern was the potential use of this attack on the Auth0 management service. Auth0 tenants are managed by tenant administrators, who have accounts on an "authority tenant" with relevant permissions. If an attacker could learn the user identifier of a tenant administrator on the tenant authority (such as by social engineering), this allowed the attacker to login as the administrator by the described attack method. The attacker could then undertake administration actions and view all information at the tenant.

The attack was never effective if the user had <Tooltip tip="Multi-factor authentication (MFA): User authentication process that uses a factor in addition to username and password such as a code via SMS." cta="View Glossary" href="/docs/glossary?term=multifactor+authentication">multifactor authentication</Tooltip> enabled, which is recommended.

## Am I affected?

All Auth0 tenants were affected, but have been patched. Public cloud tenants were patched within four hours of the vulnerability report.

The attack was never effective if the user had multifactor authentication enabled.

## How to fix that?

The vulnerability was fixed by Auth0, accomplished by adding proper validation of the audience parameter. No additional actions are required of our customers.

### Will this update impact my users?

The fix was invisible to all users.