Vulnerability from cleanstart
Published
2026-09-01 11:17
Modified
2026-09-04 11:14
Summary
Security fixes in langfuse-worker 3.224.0-r1
Details
Package langfuse-worker version 3.224.0-r1 fixes 25 vulnerabilities: ghsa-p63j-vcc4-9vmv, ghsa-55q2-fjhq-7xh7, ghsa-c2j3-45gr-mqc4, CVE-2026-69192, CVE-2026-54272...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "langfuse-worker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.224.0-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.224.0-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package langfuse-worker version 3.224.0-r1 fixes 25 vulnerabilities: ghsa-p63j-vcc4-9vmv, ghsa-55q2-fjhq-7xh7, ghsa-c2j3-45gr-mqc4, CVE-2026-69192, CVE-2026-54272...",
"id": "CLEANSTART-2026-TC75125",
"modified": "2026-09-04T11:14:10Z",
"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.224.0-r1",
"upstream": [
"ghsa-p63j-vcc4-9vmv",
"ghsa-55q2-fjhq-7xh7",
"ghsa-c2j3-45gr-mqc4",
"CVE-2026-69192",
"CVE-2026-54272",
"CVE-2026-69198",
"ghsa-5p4m-2wfm-xmqj",
"CVE-2026-50159",
"CVE-2026-71436",
"CVE-2026-71437",
"CVE-2026-71439",
"CVE-2026-71438",
"CVE-2026-67213",
"CVE-2026-67214",
"ghsa-7rqj-j65f-68wh",
"ghsa-xmf8-cvqr-rfgj",
"ghsa-x445-f3h2-j279",
"ghsa-r28c-9q8g-f849",
"CVE-2026-69153",
"ghsa-f88m-g3jw-g9cj",
"CVE-2026-13697",
"CVE-2026-14643",
"CVE-2026-15157",
"CVE-2026-16728",
"CVE-2026-16729"
]
}
CVE-2026-69192 (GCVE-0-2026-69192)
Vulnerability from cvelistv5 – Published: 2026-08-03 19:56 – Updated: 2026-08-04 13:59
VLAI
EPSS
VEX
Title
ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass
Summary
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.3.1, Address4 accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, inet_aton, and getaddrinfo all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. new Address4('012.0.0.1') reports correctForm() of 12.0.0.1 and isPrivate() of false, but fetch('http://012.0.0.1/') connects to 10.0.0.1. An application that builds a network trust-boundary decision on these checks, for example a filter intended to block Server-Side Request Forgery, or SSRF, will classify an internal target as external and allow the request. The defect is in the parse gate rather than in any one classifier, so every consumer of Address4 inherits it: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() are all computed from the mis-decoded octets. This issue is fixed in version 10.3.1.
Severity
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-04 13:59 UTC
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/beaugunderson/ip-address/secur… | x_refsource_CONFIRM |
| https://github.com/beaugunderson/ip-address/commi… | x_refsource_MISC |
| https://github.com/beaugunderson/ip-address/relea… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| beaugunderson | ip-address |
Affected:
< 10.3.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-69192",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-04T13:59:11.084723Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-04T13:59:43.294Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-mwp4-54f8-5fhr"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "ip-address",
"vendor": "beaugunderson",
"versions": [
{
"status": "affected",
"version": "\u003c 10.3.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. Prior to 10.3.1, Address4 accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, inet_aton, and getaddrinfo all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. new Address4(\u0027012.0.0.1\u0027) reports correctForm() of 12.0.0.1 and isPrivate() of false, but fetch(\u0027http://012.0.0.1/\u0027) connects to 10.0.0.1. An application that builds a network trust-boundary decision on these checks, for example a filter intended to block Server-Side Request Forgery, or SSRF, will classify an internal target as external and allow the request. The defect is in the parse gate rather than in any one classifier, so every consumer of Address4 inherits it: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() are all computed from the mis-decoded octets. This issue is fixed in version 10.3.1."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20: Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-918",
"description": "CWE-918: Server-Side Request Forgery (SSRF)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T19:56:13.640Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-mwp4-54f8-5fhr",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-mwp4-54f8-5fhr"
},
{
"name": "https://github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e"
},
{
"name": "https://github.com/beaugunderson/ip-address/releases/tag/v10.3.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.3.1"
}
],
"source": {
"advisory": "GHSA-mwp4-54f8-5fhr",
"discovery": "UNKNOWN"
},
"title": "ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-69192",
"datePublished": "2026-08-03T19:56:13.640Z",
"dateReserved": "2026-08-03T16:00:23.483Z",
"dateUpdated": "2026-08-04T13:59:43.294Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-69198 (GCVE-0-2026-69198)
Vulnerability from cvelistv5 – Published: 2026-08-03 19:59 – Updated: 2026-08-04 17:21
VLAI
EPSS
VEX
Title
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
Summary
ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. An application that builds a network trust-boundary decision on these checks, for example a filter intended to block Server-Side Request Forgery, or SSRF, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-04 17:21 UTC
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/beaugunderson/ip-address/secur… | x_refsource_CONFIRM |
| https://github.com/beaugunderson/ip-address/commi… | x_refsource_MISC |
| https://github.com/beaugunderson/ip-address/relea… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| beaugunderson | ip-address |
Affected:
>= 10.1.1, < 10.2.2
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-69198",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-04T17:21:32.083041Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-04T17:21:59.584Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-4xrf-jv44-h6hh"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "ip-address",
"vendor": "beaugunderson",
"versions": [
{
"status": "affected",
"version": "\u003e= 10.1.1, \u003c 10.2.2"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ip-address is a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript. From 10.1.1 until 10.2.2, every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address\u0027s own subnet mask is shorter than the reference range\u0027s mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target. An application that builds a network trust-boundary decision on these checks, for example a filter intended to block Server-Side Request Forgery, or SSRF, may therefore treat an internal target as external and allow the request. The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask; the defect is solely that the containment guard sits in the classification path. This issue is fixed in version 10.2.2."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"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:H/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20: Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-918",
"description": "CWE-918: Server-Side Request Forgery (SSRF)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T19:59:05.731Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-4xrf-jv44-h6hh",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-4xrf-jv44-h6hh"
},
{
"name": "https://github.com/beaugunderson/ip-address/commit/488fe9bc7c35363b4b090494fc38c266d217740d",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/beaugunderson/ip-address/commit/488fe9bc7c35363b4b090494fc38c266d217740d"
},
{
"name": "https://github.com/beaugunderson/ip-address/releases/tag/v10.2.2",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.2.2"
}
],
"source": {
"advisory": "GHSA-4xrf-jv44-h6hh",
"discovery": "UNKNOWN"
},
"title": "ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-69198",
"datePublished": "2026-08-03T19:59:05.731Z",
"dateReserved": "2026-08-03T16:57:50.124Z",
"dateUpdated": "2026-08-04T17:21:59.584Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71436 (GCVE-0-2026-71436)
Vulnerability from cvelistv5 – Published: 2026-08-06 19:49 – Updated: 2026-08-07 16:17
VLAI
EPSS
VEX
Title
Mermaid XY Charts are vulnerable to an infinite loop DoS
Summary
Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 10.6.0 until 10.9.8 and 11.16.1, Mermaid XY Charts are vulnerable to an infinite loop denial of service in the setXAxisRangeData function when configuring an X-Axis with invalid parameters. Because each loop iteration appends an element to an array, this generally causes a RangeError to appear after a few seconds, but it may instead cause the page or JavaScript process to crash from memory exhaustion, depending on the environment. This issue is fixed in versions 10.9.8 and 11.16.1.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-07 16:15 UTC
CWE
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/mermaid-js/mermaid/security/ad… | x_refsource_CONFIRM |
| https://github.com/mermaid-js/mermaid/pull/8022 | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/commit/630a… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/commit/ef60… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/releases/ta… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/releases/ta… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| mermaid-js | mermaid |
Affected:
>= 10.6.0, < 10.9.8
Affected: >= 11.0.0-alpha.1, < 11.16.1 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71436",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T16:15:22.877895Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T16:17:15.115Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "mermaid",
"vendor": "mermaid-js",
"versions": [
{
"status": "affected",
"version": "\u003e= 10.6.0, \u003c 10.9.8"
},
{
"status": "affected",
"version": "\u003e= 11.0.0-alpha.1, \u003c 11.16.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 10.6.0 until 10.9.8 and 11.16.1, Mermaid XY Charts are vulnerable to an infinite loop denial of service in the setXAxisRangeData function when configuring an X-Axis with invalid parameters. Because each loop iteration appends an element to an array, this generally causes a RangeError to appear after a few seconds, but it may instead cause the page or JavaScript process to crash from memory exhaustion, depending on the environment. This issue is fixed in versions 10.9.8 and 11.16.1."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-835",
"description": "CWE-835: Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1325",
"description": "CWE-1325: Improperly Controlled Sequential Memory Allocation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-06T19:49:44.739Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-2v8p-3f2j-5mp7",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-2v8p-3f2j-5mp7"
},
{
"name": "https://github.com/mermaid-js/mermaid/pull/8022",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/pull/8022"
},
{
"name": "https://github.com/mermaid-js/mermaid/commit/630aa7e5dd417e1f56bff2a1ce8df2c5ad08d289",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/commit/630aa7e5dd417e1f56bff2a1ce8df2c5ad08d289"
},
{
"name": "https://github.com/mermaid-js/mermaid/commit/ef60adc837d9d5107af21285f01e83dea309bd0a",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/commit/ef60adc837d9d5107af21285f01e83dea309bd0a"
},
{
"name": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid@11.16.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid@11.16.1"
},
{
"name": "https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8"
}
],
"source": {
"advisory": "GHSA-2v8p-3f2j-5mp7",
"discovery": "UNKNOWN"
},
"title": "Mermaid XY Charts are vulnerable to an infinite loop DoS"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-71436",
"datePublished": "2026-08-06T19:49:44.739Z",
"dateReserved": "2026-08-06T16:28:51.183Z",
"dateUpdated": "2026-08-07T16:17:15.115Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71437 (GCVE-0-2026-71437)
Vulnerability from cvelistv5 – Published: 2026-08-06 19:51 – Updated: 2026-08-07 17:37
VLAI
EPSS
VEX
Title
Mermaid Architecture diagrams are vulnerable to prototype pollution
Summary
Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 11.5.0 until 11.16.1, Mermaid Architecture Diagrams are vulnerable to prototype pollution when a diagram defines a group with an id of __proto__. Because the group id is used directly as an object property key without validation, an attacker who can supply diagram text can pollute Object.prototype, potentially affecting the behavior of the embedding application. This issue is fixed in version 11.16.1.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-07 17:37 UTC
CWE
- CWE-1321 - Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/mermaid-js/mermaid/security/ad… | x_refsource_CONFIRM |
| https://github.com/mermaid-js/mermaid/pull/8022 | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/commit/99af… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/releases/ta… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| mermaid-js | mermaid |
Affected:
>= 11.5.0, < 11.16.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71437",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T17:37:12.586066Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T17:37:35.933Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-3rrr-jr9j-h3q3"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "mermaid",
"vendor": "mermaid-js",
"versions": [
{
"status": "affected",
"version": "\u003e= 11.5.0, \u003c 11.16.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 11.5.0 until 11.16.1, Mermaid Architecture Diagrams are vulnerable to prototype pollution when a diagram defines a group with an id of __proto__. Because the group id is used directly as an object property key without validation, an attacker who can supply diagram text can pollute Object.prototype, potentially affecting the behavior of the embedding application. This issue is fixed in version 11.16.1."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1321",
"description": "CWE-1321: Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-06T19:51:52.975Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-3rrr-jr9j-h3q3",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-3rrr-jr9j-h3q3"
},
{
"name": "https://github.com/mermaid-js/mermaid/pull/8022",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/pull/8022"
},
{
"name": "https://github.com/mermaid-js/mermaid/commit/99af3fc35ef0a9a9c8c6314521344d67523ddccf",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/commit/99af3fc35ef0a9a9c8c6314521344d67523ddccf"
},
{
"name": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid@11.16.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid@11.16.1"
}
],
"source": {
"advisory": "GHSA-3rrr-jr9j-h3q3",
"discovery": "UNKNOWN"
},
"title": "Mermaid Architecture diagrams are vulnerable to prototype pollution"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-71437",
"datePublished": "2026-08-06T19:51:52.975Z",
"dateReserved": "2026-08-06T16:28:51.183Z",
"dateUpdated": "2026-08-07T17:37:35.933Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71438 (GCVE-0-2026-71438)
Vulnerability from cvelistv5 – Published: 2026-08-06 19:59 – Updated: 2026-08-07 15:40
VLAI
EPSS
VEX
Title
Mermaid configuration APIs allow prototype pollution
Summary
Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. Prior to 10.9.8 and 11.16.1, Mermaid's configuration setters (mermaid.initialize, mermaidAPI.setConfig, and mermaidAPI.updateSiteConfig) merge caller-supplied configuration into Mermaid's internal config using the assignWithDepth deep-merge helper, which is vulnerable to prototype pollution. This is only exploitable if an application forwards untrusted data directly into one of these configuration entry points, which is outside their documented usage; diagram-supplied configuration (e.g. %%{init: {}}%% or YAML frontmatter) is not affected. This issue is fixed in versions 10.9.8 and 11.16.1.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-07 15:40 UTC
CWE
- CWE-1321 - Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/mermaid-js/mermaid/security/ad… | x_refsource_CONFIRM |
| https://github.com/mermaid-js/mermaid/pull/8022 | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/commit/2cd6… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/commit/c34b… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/releases/ta… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/releases/ta… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| mermaid-js | mermaid |
Affected:
< 10.9.8
Affected: >= 11.0.0-alpha.1, < 11.16.1 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71438",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T15:40:20.347360Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T15:40:29.335Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "mermaid",
"vendor": "mermaid-js",
"versions": [
{
"status": "affected",
"version": "\u003c 10.9.8"
},
{
"status": "affected",
"version": "\u003e= 11.0.0-alpha.1, \u003c 11.16.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. Prior to 10.9.8 and 11.16.1, Mermaid\u0027s configuration setters (mermaid.initialize, mermaidAPI.setConfig, and mermaidAPI.updateSiteConfig) merge caller-supplied configuration into Mermaid\u0027s internal config using the assignWithDepth deep-merge helper, which is vulnerable to prototype pollution. This is only exploitable if an application forwards untrusted data directly into one of these configuration entry points, which is outside their documented usage; diagram-supplied configuration (e.g. %%{init: {}}%% or YAML frontmatter) is not affected. This issue is fixed in versions 10.9.8 and 11.16.1."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 2.4,
"baseSeverity": "LOW",
"privilegesRequired": "HIGH",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "ACTIVE",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:N/VI:L/VA:L/SC:H/SI:H/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1321",
"description": "CWE-1321: Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-06T19:59:07.450Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-c4c3-pg64-4m4v",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-c4c3-pg64-4m4v"
},
{
"name": "https://github.com/mermaid-js/mermaid/pull/8022",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/pull/8022"
},
{
"name": "https://github.com/mermaid-js/mermaid/commit/2cd6dcf735533b323507e3e889ffdea870540b43",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/commit/2cd6dcf735533b323507e3e889ffdea870540b43"
},
{
"name": "https://github.com/mermaid-js/mermaid/commit/c34b07a0815842327e70794d69b0c8c5a1e2a956",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/commit/c34b07a0815842327e70794d69b0c8c5a1e2a956"
},
{
"name": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1"
},
{
"name": "https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8"
}
],
"source": {
"advisory": "GHSA-c4c3-pg64-4m4v",
"discovery": "UNKNOWN"
},
"title": "Mermaid configuration APIs allow prototype pollution"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-71438",
"datePublished": "2026-08-06T19:59:07.450Z",
"dateReserved": "2026-08-06T16:28:51.183Z",
"dateUpdated": "2026-08-07T15:40:29.335Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71439 (GCVE-0-2026-71439)
Vulnerability from cvelistv5 – Published: 2026-08-06 20:01 – Updated: 2026-08-07 17:09
VLAI
EPSS
VEX
Title
Mermaid radar diagrams are vulnerable to DoS
Summary
Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 11.6.0 until 11.16.1, Mermaid Radar Diagrams allow arbitrary large values for the ticks parameter, which can cause high CPU usage and freeze the rendering webpage or JavaScript process for long periods of time, potentially until the process is killed from memory exhaustion. This issue is fixed in version 11.16.1.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-07 15:26 UTC
CWE
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/mermaid-js/mermaid/security/ad… | x_refsource_CONFIRM |
| https://github.com/mermaid-js/mermaid/pull/8022 | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/commit/59b2… | x_refsource_MISC |
| https://github.com/mermaid-js/mermaid/releases/ta… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| mermaid-js | mermaid |
Affected:
>= 11.6.0, < 11.16.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71439",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T15:26:10.690336Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T17:09:23.203Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "mermaid",
"vendor": "mermaid-js",
"versions": [
{
"status": "affected",
"version": "\u003e= 11.6.0, \u003c 11.16.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 11.6.0 until 11.16.1, Mermaid Radar Diagrams allow arbitrary large values for the ticks parameter, which can cause high CPU usage and freeze the rendering webpage or JavaScript process for long periods of time, potentially until the process is killed from memory exhaustion. This issue is fixed in version 11.16.1."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-606",
"description": "CWE-606: Unchecked Input for Loop Condition",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1322",
"description": "CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-06T20:01:04.423Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-rhh3-jpg6-66xh",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-rhh3-jpg6-66xh"
},
{
"name": "https://github.com/mermaid-js/mermaid/pull/8022",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/pull/8022"
},
{
"name": "https://github.com/mermaid-js/mermaid/commit/59b22fad2b3bb04f87a476c84a8a2b24679e607e",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/commit/59b22fad2b3bb04f87a476c84a8a2b24679e607e"
},
{
"name": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1"
}
],
"source": {
"advisory": "GHSA-rhh3-jpg6-66xh",
"discovery": "UNKNOWN"
},
"title": "Mermaid radar diagrams are vulnerable to DoS"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-71439",
"datePublished": "2026-08-06T20:01:04.423Z",
"dateReserved": "2026-08-06T16:28:51.183Z",
"dateUpdated": "2026-08-07T17:09:23.203Z",
"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-5P4M-2WFM-XMQJ
Vulnerability from github – Published: 2026-08-06 20:27 – Updated: 2026-08-06 20:27
VLAI
Summary
JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported
Details
Quadratic CPU consumption in !!omap resolution (js-yaml 3.x and 4.x)
Summary
resolveYamlOmap() enforces key uniqueness for !!omap sequences with a linear
scan (objectKeys.indexOf(...)) inside the per-element loop, making resolution
O(n²) in the number of entries. A modestly sized YAML document therefore
consumes disproportionate CPU inside yaml.load(), giving a denial of service
against any consumer that parses untrusted YAML.
!!omap is registered in the default schema
(lib/schema/default.js → require('../type/omap')), so a plain
yaml.load(untrustedInput) with no options is affected — no custom schema or
non-default configuration is required.
This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm, which was fixed in the 5.x line in 5.2.1. That fix was never backported: both currently maintained legacy lines still carry the original implementation.
Affected versions
| Line | Latest tested | Status |
|---|---|---|
| 3.x | 3.15.0 | Affected — objectKeys.indexOf(pairKey) at lib/type/omap.js:29 |
| 4.x | 4.3.0 | Affected — objectKeys.indexOf(pairKey) at lib/type/omap.js:30 |
| 5.x | 5.2.2 | Not affected — fixed in 5.2.1 (uses a Set) |
Both figures are the newest release of each line at the time of writing, so this is not a "you are on an old version" issue.
Details
lib/type/omap.js (js-yaml 4.3.0):
if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)
else return false
objectKeys grows by one element per entry, and Array.prototype.indexOf is a
linear scan, so resolving an n-entry !!omap performs roughly
1 + 2 + … + n comparisons — quadratic in n. The work happens synchronously
inside yaml.load(), blocking the event loop for its whole duration.
The 5.x line already solves exactly this by tracking seen keys in a Set
(src/tag/sequence/omap.ts):
if (carrier.seen.has(key)) return 'duplicate key in ordered map'
carrier.seen.add(key)
Proof of concept
// poc.js — node poc.js
const yaml = require('js-yaml');
const doc = n => '!!omap\n' + Array.from({length: n}, (_, i) => `- k${i}: ${i}`).join('\n') + '\n';
for (const n of [10000, 20000, 40000, 80000]) {
const d = doc(n), t = Date.now();
yaml.load(d); // default schema, no options
console.log(`n=${n} bytes=${d.length} load=${Date.now() - t}ms`);
}
Measured (node v20.20.2, default heap, no flags)
js-yaml 4.3.0
n=10000 bytes=137787 load=54ms
n=20000 bytes=297787 load=169ms
n=40000 bytes=617787 load=646ms
n=80000 bytes=1257787 load=2607ms
js-yaml 3.15.0
n=10000 bytes=137787 load=53ms
n=20000 bytes=297787 load=166ms
n=40000 bytes=617787 load=641ms
n=80000 bytes=1257787 load=2567ms
Runtime grows by a factor of ~4 for each doubling of n, which is the
signature of O(n²) (linear growth would be ~2×).
Scaling further: a 2.48 MB document with 150,000 entries blocked
yaml.load() for 10.8 seconds.
Impact
Any service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be stalled with a small input. Because the loop is synchronous, a single request blocks the Node.js event loop and stalls every other request in the process — so the amplification is per-process, not just per-request.
Suggested severity: consistent with CVE-2026-59870 (the same weakness in 5.x), i.e. Availability-only impact, network attack vector, no privileges or user interaction required.
Suggested fix
Mirror the 5.x fix — replace the linear scan with a Set:
// lib/type/omap.js
const seen = new Set()
// ...
if (seen.has(pairKey)) return false
seen.add(pairKey)
This preserves the existing duplicate-key rejection semantics exactly while
making resolution O(n). A maxOmapLength-style cap would also work, but the
Set matches what 5.x already ships and requires no new option.
References
- CVE-2026-59870 / GHSA-724g-mxrg-4qvm — same weakness in 5.0.0–5.2.0, fixed in 5.2.1
lib/type/omap.js(3.x, 4.x) — the affected resolverlib/schema/default.js— registers!!omapin the default schema
Discovery
Found by an automated static-analysis and executed-proof-of-concept scanner run against js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by executing the proof of concept above. All timings in this report were measured on the current releases of each line, not on the version originally scanned.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T20:27:32Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x)\n\n## Summary\n\n`resolveYamlOmap()` enforces key uniqueness for `!!omap` sequences with a linear\nscan (`objectKeys.indexOf(...)`) inside the per-element loop, making resolution\n**O(n\u00b2)** in the number of entries. A modestly sized YAML document therefore\nconsumes disproportionate CPU inside `yaml.load()`, giving a denial of service\nagainst any consumer that parses untrusted YAML.\n\n`!!omap` is registered in the **default schema**\n(`lib/schema/default.js` \u2192 `require(\u0027../type/omap\u0027)`), so a plain\n`yaml.load(untrustedInput)` with no options is affected \u2014 no custom schema or\nnon-default configuration is required.\n\n**This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm**, which was\nfixed in the 5.x line in 5.2.1. That fix was never backported: both currently\nmaintained legacy lines still carry the original implementation.\n\n## Affected versions\n\n| Line | Latest tested | Status |\n|---|---|---|\n| 3.x | **3.15.0** | Affected \u2014 `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29` |\n| 4.x | **4.3.0** | Affected \u2014 `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30` |\n| 5.x | 5.2.2 | **Not affected** \u2014 fixed in 5.2.1 (uses a `Set`) |\n\nBoth figures are the newest release of each line at the time of writing, so\nthis is not a \"you are on an old version\" issue.\n\n## Details\n\n`lib/type/omap.js` (js-yaml 4.3.0):\n\n```js\nif (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)\nelse return false\n```\n\n`objectKeys` grows by one element per entry, and `Array.prototype.indexOf` is a\nlinear scan, so resolving an `n`-entry `!!omap` performs roughly\n`1 + 2 + \u2026 + n` comparisons \u2014 quadratic in `n`. The work happens synchronously\ninside `yaml.load()`, blocking the event loop for its whole duration.\n\nThe 5.x line already solves exactly this by tracking seen keys in a `Set`\n(`src/tag/sequence/omap.ts`):\n\n```ts\nif (carrier.seen.has(key)) return \u0027duplicate key in ordered map\u0027\ncarrier.seen.add(key)\n```\n\n## Proof of concept\n\n```js\n// poc.js \u2014 node poc.js\nconst yaml = require(\u0027js-yaml\u0027);\nconst doc = n =\u003e \u0027!!omap\\n\u0027 + Array.from({length: n}, (_, i) =\u003e `- k${i}: ${i}`).join(\u0027\\n\u0027) + \u0027\\n\u0027;\n\nfor (const n of [10000, 20000, 40000, 80000]) {\n const d = doc(n), t = Date.now();\n yaml.load(d); // default schema, no options\n console.log(`n=${n} bytes=${d.length} load=${Date.now() - t}ms`);\n}\n```\n\n### Measured (node v20.20.2, default heap, no flags)\n\n**js-yaml 4.3.0**\n\n```\nn=10000 bytes=137787 load=54ms\nn=20000 bytes=297787 load=169ms\nn=40000 bytes=617787 load=646ms\nn=80000 bytes=1257787 load=2607ms\n```\n\n**js-yaml 3.15.0**\n\n```\nn=10000 bytes=137787 load=53ms\nn=20000 bytes=297787 load=166ms\nn=40000 bytes=617787 load=641ms\nn=80000 bytes=1257787 load=2567ms\n```\n\nRuntime grows by a factor of ~4 for each doubling of `n`, which is the\nsignature of O(n\u00b2) (linear growth would be ~2\u00d7).\n\nScaling further: a **2.48 MB** document with 150,000 entries blocked\n`yaml.load()` for **10.8 seconds**.\n\n## Impact\n\nAny service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be\nstalled with a small input. Because the loop is synchronous, a single request\nblocks the Node.js event loop and stalls every other request in the process \u2014\nso the amplification is per-process, not just per-request.\n\nSuggested severity: consistent with **CVE-2026-59870** (the same weakness in\n5.x), i.e. Availability-only impact, network attack vector, no privileges or\nuser interaction required.\n\n## Suggested fix\n\nMirror the 5.x fix \u2014 replace the linear scan with a `Set`:\n\n```js\n// lib/type/omap.js\nconst seen = new Set()\n// ...\nif (seen.has(pairKey)) return false\nseen.add(pairKey)\n```\n\nThis preserves the existing duplicate-key rejection semantics exactly while\nmaking resolution O(n). A `maxOmapLength`-style cap would also work, but the\n`Set` matches what 5.x already ships and requires no new option.\n\n## References\n\n- CVE-2026-59870 / GHSA-724g-mxrg-4qvm \u2014 same weakness in 5.0.0\u20135.2.0, fixed in 5.2.1\n- `lib/type/omap.js` (3.x, 4.x) \u2014 the affected resolver\n- `lib/schema/default.js` \u2014 registers `!!omap` in the default schema\n\n## Discovery\n\nFound by an automated static-analysis and executed-proof-of-concept scanner run\nagainst js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by\nexecuting the proof of concept above. All timings in this report were measured\non the **current** releases of each line, not on the version originally scanned.",
"id": "GHSA-5p4m-2wfm-xmqj",
"modified": "2026-08-06T20:27:32Z",
"published": "2026-08-06T20:27:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/security/advisories/GHSA-5p4m-2wfm-xmqj"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodeca/js-yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) \u2014 CVE-2026-59870 fix not backported"
}
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."
}
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…