CVE-2026-65903

mediumpriority · track · 0EPSS 0.003 · 25 %ileEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.33% (25th) EPSS
CVSS 6.1 · medium
Is it mine?
3 products
Check your exposure
Who says so?
4 sources
cnnvd · enisa_euvd · nvd · osv

EPSS · scored 2026-10-27

DOMPurify before 3.4.0 contains a logic error in the ADD_TAGS function where short-circuit evaluation allows forbidden tags to bypass FORBID_TAGS restrictions. Attackers can craft input containing tags listed in FORBID_TAGS that are also added via ADD_TAGS function, causing them to be retained in sanitized output.

01

cvss

Technical severity, 0–10. One row per scoring source.

6.1
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · low–medium · 1.2–6.1

v3.16.1mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:Nsecondary · disclosure@vulncheck.comexploitability 2.8 · impact 2.7
v4.05.1mediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:Nsecondary · ENISA EU
v4.05.1mediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · disclosure@vulncheck.com
v4.01.2lowCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Trackcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (3)

Products and version ranges known to be affected.

05

advisories (1)

Vendor and ecosystem advisories describing this.

  • GHSA-39q2-94rc-95cpDOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation2026-04-16ghsa · osvUS

    ## 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)

06

also known as (2)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2026-07-23modified 2026-10-24
08

references (6)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan