Update dependency dompurify to v3.4.0 [SECURITY]

[matticbot]

This PR contains the following updates:

Package	Change	Age	Confidence
dompurify	3.3.3 → 3.4.0

GitHub Vulnerability Alerts

GHSA-39q2-94rc-95cp

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)

---

DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

GHSA-39q2-94rc-95cp

More information

Details

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)

Severity

• CVSS Score: Unknown
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

• https://github.com/cure53/DOMPurify/security/advisories/GHSA-39q2-94rc-95cp
• https://github.com/cure53/DOMPurify

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

cure53/DOMPurify (dompurify)

v3.4.0: DOMPurify 3.4.0

Compare Source

Most relevant changes:

• Fixed a problem with FORBID_TAGS not winning over ADD_TAGS, thanks @​kodareef5
• Fixed several minor problems and typos regarding MathML attributes, thanks @​DavidOliver
• Fixed ADD_ATTR/ADD_TAGS function leaking into subsequent array-based calls, thanks @​1Jesper1
• Fixed a missing SAFE_FOR_TEMPLATES scrub in RETURN_DOM path, thanks @​bencalif
• Fixed a prototype pollution via CUSTOM_ELEMENT_HANDLING, thanks @​trace37labs
• Fixed an issue with ADD_TAGS function form bypassing FORBID_TAGS, thanks @​eddieran
• Fixed an issue with ADD_ATTR predicates skipping URI validation, thanks @​christos-eth
• Fixed an issue with USE_PROFILES prototype pollution, thanks @​christos-eth
• Fixed an issue leading to possible mXSS via Re-Contextualization, thanks @​researchatfluidattacks and others
• Fixed an issue with closing tags leading to possible mXSS, thanks @​frevadiscor
• Fixed a problem with the type dentition patcher after Node version bump
• Fixed freezing BS runs by reducing the tested browsers array
• Bumped several dependencies where possible
• Added needed files for OpenSSF scorecard checks

Published Advisories are here:
https://github.com/cure53/DOMPurify/security/advisories?state=published

---

Configuration

📅 Schedule: Branch creation - "" in timezone UTC, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the renovate/npm-dompurify-vulnerability branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack renovate/npm-dompurify-vulnerability

bin/jetpack-downloader test jetpack-mu-wpcom-plugin renovate/npm-dompurify-vulnerability

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report · JS report