fix(deps): update frontend dependencies#772
Open
renovate-sh-app[bot] wants to merge 1 commit into
Open
Conversation
Contributor
|
TruffleHog Scan Results Summary: Found 3 potential secrets (0 verified, 3 unverified)
Review: Check if unverified secrets are false positives. Ignoring False Positives: This works for files that support line numbers (most source files). After adding the comment, push your changes and the scan will re-run. |
1c7e7ba to
f4d2d72
Compare
| datasource | package | from | to | | ---------- | -------------------------------- | ------- | ------- | | npm | @axe-core/playwright | 4.11.3 | 4.12.1 | | npm | @babel/core | 7.29.0 | 7.29.7 | | npm | @grafana/data | 12.4.2 | 12.4.5 | | npm | @grafana/e2e-selectors | 12.4.2 | 12.4.5 | | npm | @grafana/i18n | 12.4.3 | 12.4.5 | | npm | @grafana/plugin-e2e | 3.7.1 | 3.9.1 | | npm | @grafana/plugin-meta-extractor | 0.12.2 | 0.13.0 | | npm | @grafana/plugin-ui | 0.13.1 | 0.16.0 | | npm | @grafana/runtime | 12.4.2 | 12.4.5 | | npm | @grafana/schema | 12.4.2 | 12.4.5 | | npm | @grafana/tsconfig | 2.1.0 | 2.2.0 | | npm | @grafana/ui | 12.4.2 | 12.4.4 | | npm | @openfeature/core | 1.10.0 | 1.11.0 | | npm | @openfeature/web-sdk | 1.8.0 | 1.9.0 | | npm | @playwright/test | 1.59.1 | 1.61.0 | | npm | @remix-run/router | 1.23.2 | 1.23.3 | | npm | @swc/core | 1.15.32 | 1.15.43 | | npm | @swc/helpers | 0.5.21 | 0.5.23 | | npm | @types/node | 25.6.0 | 25.9.4 | | npm | @types/react | 18.3.28 | 18.3.31 | | npm | @typescript-eslint/eslint-plugin | 8.59.1 | 8.62.0 | | npm | @typescript-eslint/parser | 8.59.1 | 8.62.0 | | npm | cspell | 10.0.0 | 10.0.1 | | npm | dompurify | 3.4.2 | 3.4.11 | | npm | eslint-plugin-prettier | 5.5.5 | 5.5.6 | | npm | i18next | 26.0.8 | 26.3.1 | | npm | jest | 30.3.0 | 30.4.2 | | npm | jest-environment-jsdom | 30.3.0 | 30.4.1 | | npm | prettier | 3.8.3 | 3.8.4 | | npm | sass | 1.99.0 | 1.101.0 | | npm | sass-loader | 16.0.7 | 16.0.8 | | npm | semver | 7.7.4 | 7.8.5 | | npm | serialize-javascript | 7.0.5 | 7.0.6 | | npm | terser-webpack-plugin | 5.5.0 | 5.6.1 | | npm | webpack | 5.106.2 | 5.107.2 | | npm | webpack-cli | 7.0.2 | 7.0.3 | | npm | @yarnpkg/cli | 4.14.1 | 4.17.0 | Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
f4d2d72 to
5e58de9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.11.3→4.12.17.29.0→7.29.712.4.2→12.4.512.4.2→12.4.512.4.3→12.4.53.7.1→3.9.10.12.2→0.13.00.13.1→0.16.012.4.2→12.4.512.4.2→12.4.52.1.0→2.2.012.4.2→12.4.41.10.0→1.11.01.8.0→1.9.01.59.1→1.61.01.23.2→1.23.31.15.32→1.15.430.5.21→0.5.2325.6.0→25.9.418.3.28→18.3.318.59.1→8.62.08.59.1→8.62.010.0.0→10.0.13.4.2→3.4.115.5.5→5.5.626.0.8→26.3.130.3.0→30.4.230.3.0→30.4.13.8.3→3.8.41.99.0→1.101.016.0.7→16.0.87.7.4→7.8.57.0.5→7.0.65.5.0→5.6.15.106.2→5.107.27.0.2→7.0.34.14.1→4.17.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
DOMPurify: SAFE_FOR_TEMPLATES bypass - template expressions survive sanitization inside content when using DOM output modes
GHSA-gvmj-g25r-r7wr
More information
Details
Summary
When DOMPurify is configured with both
SAFE_FOR_TEMPLATES: trueandRETURN_DOM: true(orIN_PLACE: true), an attacker can inject template expressions, such as${evil},{{evil}}, or<%evil%>, that survive the sanitization pass inside<template>element content. This bypasses the explicit purpose ofSAFE_FOR_TEMPLATES, which is to prevent template engine evaluation of user-supplied content.Description
Background
SAFE_FOR_TEMPLATESis designed to strip{{ }},${ }, and<% %>expressions from sanitized output so that downstream template engines do not evaluate user-controlled content. The feature operates through two mechanisms:_sanitizeElements,src/purify.ts:1403), scrubs individual text nodes during the main sanitization walk._scrubTemplateExpressions,src/purify.ts:1115), callsnode.normalize()to merge adjacent text nodes, then walks the merged nodes and strips any expressions that only appeared after merging.The Gap
_scrubTemplateExpressionsuses a standardNodeIteratorrooted at the output body:Per the DOM specification, a
NodeIteratordoes not descend into<template>.content. The template element's content is a separateDocumentFragmentthat lives outside the normal child-node tree. For the same reason,node.normalize()(called on line 1116) also does not normalize text nodes inside<template>.content.This means the final normalization and scrub pass, the only pass that catches expressions formed by merging split text nodes, never runs on
<template>content.How Split Text Nodes Are Created
When DOMPurify removes a disallowed element with
KEEP_CONTENT: true(the default), it moves the element's text children into the parent node. This is the standard code path atsrc/purify.ts:1361–1373:If the removed elements were adjacent siblings inside
<template>content, their extracted text nodes end up as adjacent text nodes in the template content fragment. Each individual text node is scrubbed by_sanitizeElements, but since$and{evil}do not match any expression regex on their own, neither is modified.The code comment at
src/purify.ts:1100explicitly acknowledges the threat class:The implementation guards against this on the main body, but the guard is not applied to
<template>content.Proof of Concept
Why the Split Works
The bypass relies on splitting
${...}across two adjacent custom elements so that neither fragment matches any DOMPurify regex on its own:TMPLIT_EXPR/\${[\w\W]*/gMUSTACHE_EXPR/{{[\w\W]*|^[\w\W]*}}/g$${- no{follows{{or}}{alert(document.domain)}$- absent{{, ends with single}not}}${alert(document.domain)}DOMPurify only sees each fragment in isolation. It never merges them before checking, so the expression is never detected.
PoC 1 - XSS via
alert()(baseline confirmation)PoC 2 - Session Hijacking via cookie exfiltration
PoC 3 - End-to-end: realistic application context
This shows the full path in an application that uses DOMPurify to sanitize user-submitted rich text before rendering it with a custom template engine:
Observed output:
alert("XSS: " + document.cookie)executes in the victim's browser context, leaking session tokens to the attacker.PoC 4 -
IN_PLACEmode (DOM input path)HTML File for testing
Root Cause
_scrubTemplateExpressions(src/purify.ts:1115) does not recurse into<template>.content:The fix is to extend
_scrubTemplateExpressionsto explicitly recurse into<template>.content, mirroring the approach already used by_sanitizeShadowDOM(src/purify.ts:1753):Suggested Patch Direction
Impact
Who is affected: Applications that use DOMPurify with
SAFE_FOR_TEMPLATES: truecombined withRETURN_DOM: true,RETURN_DOM_FRAGMENT: true, orIN_PLACE: true, whose downstream template engine processes<template>element content.What an attacker can achieve: Inject arbitrary template expressions (
${...},{{...}},<%...%>) into the sanitized DOM output inside<template>elements. If the consuming template engine evaluates these expressions, this leads to template injection, which in server-side contexts can escalate to Remote Code Execution and in client-side contexts to Cross-Site Scripting.Preconditions for Exploitation
SAFE_FOR_TEMPLATES: trueRETURN_DOM: trueorIN_PLACE: true<template>.contentWhat Is NOT Affected
The string output path (default) is not affected. The final regex scrub at
src/purify.ts:2067–2071operates on the serialized HTML string, where the injected expression is visible and stripped:Severity
CVSS: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:PReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
DOMPurify: IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM
CVE-2026-49459 / GHSA-r47g-fvhr-h676
More information
Details
IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM
CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — silent no-op when
_forceRemoveis called on a parent-less node)Summary
When
DOMPurify.sanitize(root, { IN_PLACE: true })is called androotis a<form>whose own attributes carry an event handler (onmouseover,onfocus,onclick, etc.), a single descendant element with aname=attribute matching any of the property names_isClobberedchecks (nodeName,setAttribute,namespaceURI,insertBefore,hasChildNodes,childNodes) is sufficient to bypass attribute sanitization on the root._forceRemovesilently no-ops because the root has no parent; the iterator drives on to_sanitizeAttributes, which early-returns on clobbered nodes — and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live.This affects current
mainat89da34e(the just-landed DOM-clobbering hardening fix at89da34eaddressed_sanitizeAttachedShadowRootswalk traversal, not the main_sanitizeElements/_sanitizeAttributespipeline against the iterator-root node).Affected
mainat89da34e03ec17868e561f87f3747a9371b61a9e7DOMPurify.sanitize(node, { IN_PLACE: true })wherenodeis built from untrusted HTML (e.g., parsed viacreateElement('template').innerHTML = dirtythentemplate.content.firstElementChildhanded in)Not affected:
DOMPurify.sanitize(dirtyString)— the library builds the DOM itself inside_initDocument, the root is the cleanly-created document body, and clobber-named children of the body cannot shadowbodynamed properties (HTMLBodyElement does not carry[LegacyOverrideBuiltIns])Vulnerability details
Code paths
[A] —
_forceRemoveatsrc/purify.ts:930-939:When the iterator-root has no parent (the standard IN_PLACE case where the caller hands in a detached node),
getParentNode(node)returnsnull,null.removeChild(node)throws, the catch falls toremove(node)— which per WebIDL isElement.prototype.remove.call(node), and per spec does nothing if the node has no parent. Nothing about_forceRemove's contract acknowledges this — the function appears to its callers as "the node is gone now," but the node is still in place.[B] —
_sanitizeAttributesatsrc/purify.ts:1490-1492:The skip at
[B]is deliberate — the intent is to avoid touching nodes the library has already decided to discard. The invariant the comment implies is "if_isClobbered, then_sanitizeElementsalready removed this node, so we will never reach_sanitizeAttributeson it." That invariant holds for every non-root node (their_forceRemovesucceeds in detaching them), but fails for the iterator root in IN_PLACE mode.The mismatch is between [A] and [B]: [A] assumes "removal" means the node will not be observed again, and [B] assumes any clobbered node it sees has already been removed. Neither holds for the iterator root. A correct guard would either make
_forceRemovefail loudly on parent-less nodes (so the caller can bail out of IN_PLACE entirely) or have_sanitizeAttributesstrip attributes from clobbered roots before returning.Iterator call site
src/purify.ts:1850-1864ignores the boolean return value of_sanitizeElements:If the return value were checked and
_sanitizeAttributesskipped when the node was "killed," the bug would not exist as a discrete issue — but currently_sanitizeAttributesis the only line of defense for a node that_sanitizeElementscould not actually detach.Why the clobber works
In Chromium/WebKit/Firefox,
HTMLFormElementcarries the WebIDL[LegacyOverrideBuiltIns]extended attribute on its named-property getter. A descendant element withname="X"(orid="X", for radio-button-like names) shadows the matching property on the form, including properties inherited fromElement,Node, andEventTargetprototypes. This is the same primitive the just-landed89da34efix addresses for shadow-root traversal, but_isClobbered's typeof checks (and the bypass-by-detection-failure path here) are independent of that fix.Verified clobber targets (each name= value independently triggers
_isClobbered):name=value_isClobberedchecksnodeNametypeof element.nodeName !== 'string'<INPUT>)setAttributetypeof element.setAttribute !== 'function'<embed>/<applet>/<iframe>ARE callable; see "Note on callable elements" belownamespaceURItypeof element.namespaceURI !== 'string'insertBeforetypeof element.insertBefore !== 'function'hasChildNodestypeof element.hasChildNodes !== 'function'childNodes!(element.childNodes && typeof element.childNodes.length === 'number')<INPUT>has no.lengthattributes!(element.attributes instanceof NamedNodeMap)<INPUT>is not a NamedNodeMap)textContenttypeof element.textContent !== 'string'removeChildtypeof element.removeChild !== 'function'removeAttributetypeof element.removeAttribute !== 'function'Any single one of the ten property names in
_isClobbered's checklist is sufficient as the bypass trigger.Proof of concept
(1) Minimal — runnable in a single browser context
(2) End-to-end — Playwright against
mainHEAD