DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation
Published 16 Apr 2026 · Updated 10 Sept 2026
Affected package
- Affected
- <3.4.0
- Fixed in
- 3.4.0
npm install dompurify@3.4.0Details
Summary
In src/purify.ts:1117-1123, ADD_TAGS as a function (via EXTRA_ELEMENT_HANDLING.tagCheck) bypasses FORBID_TAGS due to short-circuit evaluation.
The condition:
!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])
When tagCheck(tagName) returns true, the entire condition is false and the element is kept — FORBID_TAGS[tagName] is never evaluated.
Inconsistency
This contradicts the attribute-side pattern at line 1214 where FORBID_ATTR explicitly wins first:
if (FORBID_ATTR[lcName]) { continue; }For tags, FORBID should also take precedence over ADD.
Impact
Applications using both ADD_TAGS as a function and FORBID_TAGS simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.
Suggested Fix
Check FORBID_TAGS before tagCheck:
if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }Affected Version
v3.3.3 (commit 883ac15)
Is GHSA-39q2-94rc-95cp in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected dompurify, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.