GHSA-PG53-56CG-4M8Q
Vulnerability from github – Published: 2021-02-11 21:36 – Updated: 2021-02-22 20:43Impact
Implementations using the Prisma database adapter with the Email provider are impacted.
Implementations using the Prisma database adapter that are not using the Email provider are not impacted. Implementations using the default database adapter (TypeORM) with the Email provider are not impacted. Implementations not using a database are not impacted.
Patches
This issue is fixed in 3.3.0 and newer versions.
Workarounds
Those not able to upgrade can alternatively disable the Email provider as a workaround.
Description
The Prisma database adapter was checking the verification token but not the identifier (the email address associated with the token). This made it possible to use a valid token assigned to one user, to sign in as another user when using the Prima adapter in conjunction with the Email provider. The defect is specific to the community-supported Prisma database adapter in versions <3.3.0 and is not present in the default database adapter (TypeORM).
Note: The current community-supported adapter was not developed by Prisma.
The defect was a problem in the implementation of verification function the adapter and is not directly related to Prisma.
The flaw may exist in other third party database adapters that do not check both the identifier and token values.
The design of the database adapter API may be revised in future to help reduce the likelyhood of similar defects.
Timeline
On Monday (2021-02-08) we were notified via responsible disclosure by Alessandro Angelino (@AlessandroA) of a flaw in the implementation of the Prisma database adapter included with NextAuth.js. A detailed write up and proof of concept were provided.
The following day (2021-02-09) we published a fix in v3.3.0 and confirmed through internal testing, and with Alessandro, that the issue was resolved in the new release and prompted users to upgrade.
On 2021-02-10 we received a CVE ID and published this advisory within a few hours of notification.
We would like to thank Alessandro for using responsible disclose to allow us to address the issue promptly and publish this advisory once an update was available that resolved the issue and Balázs Orbán (@balazsorban44) for facilitating a timely release of the fix.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21310"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2021-02-11T21:36:12Z",
"nvd_published_at": "2021-02-11T22:15:00Z",
"severity": "LOW"
},
"details": "### Impact\n\nImplementations using the **Prisma database adapter** with the **Email provider** **are impacted**.\n\nImplementations using the Prisma database adapter that are not using the Email provider are not impacted.\nImplementations using the default database adapter (TypeORM) with the Email provider are not impacted.\nImplementations not using a database are not impacted.\n\n### Patches\n\nThis issue is fixed in 3.3.0 and newer versions.\n\n### Workarounds\n\nThose not able to upgrade can alternatively disable the Email provider as a workaround.\n\n### Description\n\nThe Prisma database adapter was checking the verification token but not the identifier (the email address associated with the token). This made it possible to use a valid token assigned to one user, to sign in as another user when using the Prima adapter in conjunction with the Email provider. The defect is specific to the community-supported Prisma database adapter in versions \u003c3.3.0 and is not present in the default database adapter (TypeORM).\n\n*Note: The current community-supported adapter was not developed by Prisma.*\n\nThe defect was a problem in the implementation of verification function the adapter and is not directly related to Prisma.\n\nThe flaw may exist in other third party database adapters that do not check both the identifier and token values.\n\nThe design of the database adapter API may be revised in future to help reduce the likelyhood of similar defects.\n\n### Timeline\n\nOn Monday (2021-02-08) we were notified via responsible disclosure by Alessandro Angelino (@AlessandroA) of a flaw in the implementation of the Prisma database adapter included with NextAuth.js. A detailed write up and proof of concept were provided.\n\nThe following day (2021-02-09) we published a fix in v3.3.0 and confirmed through internal testing, and with Alessandro, that the issue was resolved in the new release and prompted users to upgrade.\n\nOn 2021-02-10 we received a CVE ID and published this advisory within a few hours of notification.\n\nWe would like to thank Alessandro for using responsible disclose to allow us to address the issue promptly and publish this advisory once an update was available that resolved the issue and Bal\u00e1zs Orb\u00e1n (@balazsorban44) for facilitating a timely release of the fix.",
"id": "GHSA-pg53-56cg-4m8q",
"modified": "2021-02-22T20:43:03Z",
"published": "2021-02-11T21:36:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-pg53-56cg-4m8q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21310"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/v3.3.0"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/next-auth"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Token verification bug in next-auth"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.