CVE-2026-66010

Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to prototype pollution. It is possible to add or modify properties to the Object prototype through a malicious template. This may allow attackers to crash the application or execute Arbitrary Code in specific conditions.

Recommendation

Upgrade to version 3.0.8, 4.5.3 or later.

Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It is due to an incomplete fix for a previous issue. This vulnerability can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).

Recommendation

Upgrade to version 3.0.8, 4.5.3 or later.

DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.

DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.

DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.

Versions of handlebars prior to 3.0.8 or 4.5.2 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).

The following template can be used to demonstrate the vulnerability:

	{{#with split as |a|}}
		{{pop (push "alert('Vulnerable Handlebars JS');")}}
		{{#with (concat (lookup join (slice 0 1)))}}
			{{#each (slice 2 3)}}
				{{#with (apply 0 a)}}
					{{.}}
				{{/with}}
			{{/each}}
		{{/with}}
	{{/with}}
{{/with}}```


## Recommendation

Upgrade to version 3.0.8, 4.5.2 or later.

Summary

There is a possible hook-policy inconsistency in DOMPurify 3.4.11 involving CUSTOM_ELEMENT_HANDLING.

When a custom element is allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, it appears that the element does not go through afterSanitizeElements in the same way as a normal element. As a result, an application that relies on afterSanitizeElements as a security policy layer to strip sensitive attributes from all elements may see those attributes removed from normal elements but preserved on allowed custom elements.

This does not appear to be a direct DOMPurify XSS or a case where DOMPurify directly allows executable payloads. The preserved value is still inert at sanitize time. The issue becomes relevant when the allowed custom element later re-injects that attribute value into an HTML sink such as innerHTML, creating a second-order XSS gadget.

Details

The issue appears to originate from the control flow in src/purify.ts: line 1672~1691

const _sanitizeDisallowedNode = function (
    currentNode: any,
    tagName: string
  ): boolean {
    /* Check if we have a custom element to handle */
    if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
        regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
      ) {
        return false;
      }

      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
        CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
      ) {
        return false;
      }
    }

CUSTOM_ELEMENT_HANDLING is parsed from user configuration at src/purify.ts: line 741~748

const customElementHandling =
      objectHasOwnProperty(cfg, 'CUSTOM_ELEMENT_HANDLING') &&
      cfg.CUSTOM_ELEMENT_HANDLING &&
      typeof cfg.CUSTOM_ELEMENT_HANDLING === 'object'
        ? clone(cfg.CUSTOM_ELEMENT_HANDLING)
        : create(null);

    CUSTOM_ELEMENT_HANDLING = create(null);

In particular, tagNameCheck, attributeNameCheck, and allowCustomizedBuiltInElements are copied into the internal CUSTOM_ELEMENT_HANDLING object there.

During element sanitization, _sanitizeElements() checks whether a node is forbidden or not allowlisted at src/purify.ts: line 1805~1814

/* Remove element if anything forbids its presence */
    if (
      FORBID_TAGS[tagName] ||
      (!(
        EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
        EXTRA_ELEMENT_HANDLING.tagCheck(tagName)
      ) &&
        !ALLOWED_TAGS[tagName])
    ) {
      return _sanitizeDisallowedNode(currentNode, tagName);
    }

If so, it immediately delegates to _sanitizeDisallowedNode(currentNode, tagName) and returns its boolean result.

Inside _sanitizeDisallowedNode(), the custom-element-specific allow path is implemented at src/purify.ts: line 1672~1692

const _sanitizeDisallowedNode = function (
    currentNode: any,
    tagName: string
  ): boolean {
    /* Check if we have a custom element to handle */
    if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
        regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
      ) {
        return false;
      }

      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
        CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
      ) {
        return false;
      }
    }

If the node is treated as a basic custom element and CUSTOM_ELEMENT_HANDLING.tagNameCheck matches, the function returns false immediately at line 1682 or 1689, meaning “do not remove this node”.

That early return false is significant because control returns directly to _sanitizeElements() via the return _sanitizeDisallowedNode(...) at line 1813. As a result, the later logic in _sanitizeElements() is skipped for that custom element instance, including:

• the namespace validation at src/purify.ts: line 1816~1826 …

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-c2j3-45gr-mqc4. This link is maintained to preserve external references.

Original Description

DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.

Versions of handlebars prior to 4.0.14 are vulnerable to Prototype Pollution. Templates may alter an Objects' prototype, thus allowing an attacker to execute arbitrary code on the server.

Recommendation

For handlebars 4.1.x upgrade to 4.1.2 or later. For handlebars 4.0.x upgrade to 4.0.14 or later.

DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.

TuxCare rebuilt handlebars to address 1 CVE. Fixed in 1.3.0-tuxcare.1.

TuxCare rebuilt handlebars to address 3 CVEs. Fixed in 1.0.12-tuxcare.2.

TuxCare rebuilt dompurify to address 8 CVEs. Fixed in 3.2.3-tuxcare.2.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.0.3-tuxcare.3.

TuxCare rebuilt dompurify to address 2 CVEs. Fixed in 2.5.9-tuxcare.5.

TuxCare rebuilt dompurify to address 3 CVEs. Fixed in 2.5.8-tuxcare.6.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.3-tuxcare.7.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.0-tuxcare.4.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 2.3.0-tuxcare.1.

TuxCare rebuilt dompurify to address 16 CVEs. Fixed in 2.4.0-tuxcare.1.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 2.4.3-tuxcare.1.

TuxCare rebuilt dompurify to address 14 CVEs. Fixed in 2.4.7-tuxcare.1.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 3.2.3-tuxcare.3.

TuxCare rebuilt dompurify to address 34 CVEs. Fixed in 3.0.3-tuxcare.1.

TuxCare rebuilt dompurify to address 7 CVEs. Fixed in 3.1.6-tuxcare.7.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 3.2.7-tuxcare.1.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 2.3.0-tuxcare.5.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 2.4.0-tuxcare.5.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 3.0.3-tuxcare.5.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 2.4.7-tuxcare.5.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 2.4.3-tuxcare.8.

TuxCare rebuilt dompurify to address 4 CVEs. Fixed in 3.2.7-tuxcare.3.

TuxCare rebuilt dompurify to address 2 CVEs. Fixed in 3.4.8-tuxcare.4.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.4.11-tuxcare.1.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.4.10-tuxcare.1.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.4.9-tuxcare.1.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.4.7-tuxcare.1.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.4.6-tuxcare.1.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.4.5-tuxcare.1.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 3.1.3-tuxcare.2.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 3.1.2-tuxcare.2.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 3.1.4-tuxcare.2.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 3.0.2-tuxcare.2.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 3.0.9-tuxcare.2.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 3.0.8-tuxcare.2.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 3.0.1-tuxcare.2.

TuxCare rebuilt dompurify to address 13 CVEs. Fixed in 3.1.0-tuxcare.2.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 3.0.11-tuxcare.2.

TuxCare rebuilt dompurify to address 8 CVEs. Fixed in 3.1.1-tuxcare.2.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 3.2.6-tuxcare.2.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 3.0.6-tuxcare.2.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 3.3.3-tuxcare.3.

TuxCare rebuilt dompurify to address 13 CVEs. Fixed in 2.3.10-tuxcare.3.