3vulnerabilities
- Critical1 (33.3%)
- High1 (33.3%)
- Medium0 (0.0%)
- Moderate1 (33.3%)
- Low0 (0.0%)
auth-core
Ecosystem: npm
Downloads: 22.13 Mln
- 1CriticalAffects 1 version
- 1HighAffects 1 version
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 0LowAffects 0 versions
Monthly breakdown
- 3 vulnerabilities
- Critical: 1
- High: 1
- Medium: 0
- Moderate: 1
- Low: 0
Vulnerabilities (3)
Known vulnerabilities affecting auth-core, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-7rqj-j65f-68wh | Critical | Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass## Summary The default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient |
| GitHub (opens in a new tab) | |
| GHSA-x445-f3h2-j279 | Moderate | Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them## Summary Auth.js stores the OAuth/OIDC anti-CSRF checks (`state`, `nonce`, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider's identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second pr |
| GitHub (opens in a new tab) | |
| GHSA-xmf8-cvqr-rfgj | High | Auth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers## Summary The exported `getToken()` helper (`next-auth/jwt` and `@auth/core/jwt`) can throw an uncaught exception when it reads a malformed `Authorization: Bearer …` header. When no session cookie is present, `getToken()` URL-decodes the bearer value before validating it, and malformed percent-encoding causes the decode step to throw rather than being treated as an invalid token. Because `getToken()` is commonly called in API routes, middleware, and other request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests. ## Am I a |
| GitHub (opens in a new tab) |
- GHSA-7rqj-j65f-68whCriticalAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
>= 0.1.0, < 0.41.3
## Summary The default email-address normalizer used by the email/magic-link sign-in flow validates the address **before** applying Unicode normalization. An address can contain a Unicode character that is not an ASCII `@` (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-`@` check, but a downstream mail library that normalizes the string then sees two `@` separators and may deliver the passwordless sign-in link to a different recipient
CVE: CVE-2026-73420
- GHSA-x445-f3h2-j279ModerateAuth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them
< 0.41.3
## Summary Auth.js stores the OAuth/OIDC anti-CSRF checks (`state`, `nonce`, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider's identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second pr
CVE: CVE-2026-73419
- GHSA-xmf8-cvqr-rfgjHighAuth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers
>= 0.1.0, < 0.41.3
## Summary The exported `getToken()` helper (`next-auth/jwt` and `@auth/core/jwt`) can throw an uncaught exception when it reads a malformed `Authorization: Bearer …` header. When no session cookie is present, `getToken()` URL-decodes the bearer value before validating it, and malformed percent-encoding causes the decode step to throw rather than being treated as an invalid token. Because `getToken()` is commonly called in API routes, middleware, and other request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests. ## Am I a
CVE: CVE-2026-73418