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.
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.
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.
Check FORBID_TAGS before tagCheck:
if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }
v3.3.3 (commit 883ac15)
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 5.3 | 4.0 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-39q2-94rc-95cp ↗ |
| CWE id | Name |
|---|---|
| CWE-783 | Operator Precedence Logic Error |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| npm | dompurify | <= 3.3.3 | 3.4.0 | — |