GHSA-RXCW-MC6F-6HR3

Vulnerability from github – Published: 2026-07-31 19:12 – Updated: 2026-07-31 19:12
VLAI
Summary
Jodit Editor: Mutation XSS in jodit clean-html via a MathML/style rawtext carrier
Details

Summary

jodit's built-in clean-html sanitizer can be bypassed by a MathML/<style> carrier that hides a dangerous element from the sanitizer's element walk, so a no-interaction event handler survives into the editor value. When an application supplies attacker-influenced HTML to the editor's value-set or insertion paths, the sanitized output still contains a live <img ... onload=...> (or another non-onerror handler such as onfocus). A consumer that renders that output (element.innerHTML = editor.value) executes the handler with no user interaction. This is a stored cross-site scripting vulnerability, confirmed live on the shipped es2021/jodit.min.js for 4.12.25 and the latest 4.12.27 (in Chromium via a client-side innerHTML consumer, and in Firefox via server-rendered / document-context output; see the cross-browser note under Proof of concept).

Details

The bypass exploits the order in which clean-html parses, walks, and re-serializes the value.

  1. On the value-set path, the clean-html plugin handles :beforeSetNativeEditorValue (src/plugins/clean-html/clean-html.ts:116), parsing the value into an inert document: sandBox.innerHTML = data.value.

  2. In that parse, the source nesting math > mtext > table > mglyph > style triggers MathML text-integration-point and foster-parenting rules: the <img> is parsed as text inside <style> (rawtext), not as an element. The <table> is foster-parented out, and the <mglyph> MathML text-integration point governs the namespace, so the <img> never becomes an element node in this parse.

  3. That value-set sanitizer is safeHTML (src/core/helpers/html/safe-html.ts:24); it walks the tree but acts on elements only (the Dom.isElement gate at :39) and runs against the parse-1 sandBox, in which the <img> is rawtext, not an element. So removeAllEventAttributes (the full on* strip at safe-html.ts:76) has no element to clean and the handler passes through. The onBeforeSetNativeEditorValue handler runs safeHTML on that parse-1 tree both before and after it captures the value, so neither pass ever sees the <img> as an element.

  4. The captured value (data.value = sandBox.innerHTML) is then assigned to the editable, a second parse, which hoists the <img> out of <style> and into the HTML namespace as a live element with its handler intact. The serialize-reparse moves the element across the tree and across namespaces:

BEFORE - parse 1 (sandBox): the <img> is <style> text
  <math>          [MathML]
    <mtext>       [MathML]
      <mglyph>    [HTML]      integration point: content parses as HTML
        <style>   [HTML]      text "<img ... onload=...>"   <-- <img> is RAWTEXT, not an element
      <table>     [HTML]

AFTER - editor.value (re-parsed): the <img> is hoisted OUT of <style>, live
  <p>             [HTML]
    <math>        [MathML]
      <mtext>     [MathML]
        <mglyph>  [MathML]
          <style> [MathML]    (now empty)
        <img>     [HTML]      <-- hoisted out, HTML namespace, LIVE -> its handler fires
        <table>   [HTML]
  1. editor.value now carries that live element. The value-set pass (Steps 1-4) only walked the parse-1 sandBox and never sees it; the other sanitizer, the on-change visitor (visitNodeWalker via a LazyWalker, clean-html.ts:56/:70), does reach the hoisted element, but its sanitizeAttributes filter calls sanitizeHTMLElement (safe-html.ts:139), which strips onerror only - it never reads the removeEventAttributes flag sanitizeAttributes passes it (sanitize-attributes.ts:30), so it never runs the full on* strip. So onload, onfocus, and every other non-onerror handler is never removed and persists in editor.value permanently. (onerror is the one handler the cleaner removes, but only after a ~300ms window in which it too fires.)

The two code points (jodit 4.12.27):

// 1. clean-html.ts onBeforeSetNativeEditorValue - the SYNCHRONOUS value-set pass runs on the parse-1 sandBox:
sandBox.innerHTML = data.value;                                       // :128  parse 1: the carrier hides the element as <style> rawtext
this.j.e.fire('safeHTML', sandBox);                                   // :129  safeHTML element-walk misses the rawtext element
data.value = sandBox.innerHTML;                                       // :130  value captured; re-parsing it into the editable hoists the element live
safeHTML(sandBox, { safeJavaScriptLink: true, removeOnError: true }); // :131  re-runs on the SAME parse-1 sandBox, never on the captured value

// 2. the ASYNC on-change filter (LazyWalker) reaches the hoisted element, but only strips onerror:
sanitizeHTMLElement(nodeElm, { /* ... */ removeEventAttributes: opts.removeEventAttributes });  // sanitize-attributes.ts:30 - passes the full-strip flag
export function sanitizeHTMLElement(elm, { safeJavaScriptLink, removeOnError } = { /* ... */ }) {  // safe-html.ts:139 - never destructures removeEventAttributes
  if (removeOnError && elm.hasAttribute('onerror')) attr(elm, 'onerror', null);  // onerror ONLY; onload / onfocus / ... are left live
}

All four layers are required: removing any of math + the integration point, table, the mglyph slot, or the rawtext element makes jodit strip the handler (substitutes per slot are under Carrier variants).

The four-layer carrier is required only on 4.11.2 and later. jodit 4.11.2 added cleanHTML.removeEventAttributes (the value-set full on* strip); before it (all 3.x and 4.0 through 4.10.x) the sanitizer only ever removed onerror, so on those versions a plain non-onerror handler such as <img ... onload=...> survives editor.value directly with no carrier (live-confirmed on 3.24.9, 4.0.1, 4.2.27). On 4.11.2 and later, the value-set walk strips the bare handler, so the carrier is needed to hide it as <style> rawtext past that walk; and because the on-change cleaner removes only onerror (Step 5), a non-onerror hoisted handler survives across the whole range.

The bypass is not specific to the value setter. The same carrier survives clean-html through editor.value = X, editor.setEditorValue(X), and editor.s.insertHTML(X) (the API jodit's own documentation uses for plugins and custom buttons).

This is distinct from jodit's known XSS advisories: CVE-2023-42399 (GHSA-95xr-cq6h-vwr3) is an iframe[src] URL-scheme issue fixed in a 4.0.0 beta, and CVE-2022-23461 (GHSA-42hx-vrxx-5r6v) is a paste-from-Word onerror desanitization in <= 3.24.2. Neither involves this parse-1 rawtext-hoist mechanism, and a search of the issue tracker for mglyph / mathml / mutation / "value xss" finds no prior report.

Proof of concept

Default configuration. Assign the payload, read it back, render it the way a consumer would:

const editor = Jodit.make('#editor');
editor.value = '<math><mtext><table><mglyph><style><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" onload=alert(document.domain)></style></mglyph></table></mtext></math>';

// editor.value (the sanitized, stored output) now contains a live handler, and it persists (onload, like any
// non-onerror handler, is not removed by jodit's on-change cleaner):
//   <p><math><mtext><mglyph><style></style></mglyph>
//      <img src="data:image/gif;base64,R0lGOD...AAIBRAA7" onload="alert(document.domain)">
//      <table></table></mtext></math></p>

document.getElementById('view').innerHTML = editor.value;  // a consumer renders the saved value
// -> the 1x1 gif loads, onload fires alert(document.domain), no interaction

Cross-browser: editor.value carries the hoisted live <img> in both Blink and Gecko, but the consumer's parse mode decides execution. Chromium fires it under both client-side element.innerHTML and document parsing; Firefox fires it only under document parsing (server-side rendering, document.write, <iframe srcdoc>), because under innerHTML Gecko leaves the <img> in the MathML namespace, inert. No iframe is required: a plain innerHTML consumer suffices in Chromium, any server-rendered consumer in Firefox.

Positive control, same run: a plain <img src=x onerror=alert(1)>, a plain <img onfocus=alert(1) autofocus tabindex=1>, and a plain <svg onload=alert(1)> are all stripped by the synchronous value-set pass to harmless output, proving clean-html is active; the same handlers pass through only when carrier-hidden as <style> rawtext, so the contrast isolates the rawtext-hiding step. (A plain <script> is a separate case - the value-set pass does not remove tags; only the async on-change cleaner removes it ~300ms later - so it is not part of this synchronous control.)

Carrier variants: three of the four layers accept substitutes: the MathML text-integration point (mtext / mi / ms / mn / mo), the integration-point child (mglyph / malignmark), and the rawtext element (style / xmp / noembed / script / plaintext; title / textarea / noscript do not work). math and table have no working substitute. The hidden element is not limited to <img>, and any non-onerror handler persists permanently. Element-name blocklisting will not close this.

Impact

Stored XSS with no user interaction, in the default configuration, on the input paths that jodit's own clean-html is responsible for sanitizing. jodit's own test suite asserts this is a sanitization boundary: src/plugins/clean-html/clean-html.test.js asserts that editor.value = '<p>test <img src="" onerror="alert(111)" alt=""></p>' sanitizes to <p>test <img src="" alt=""></p> (the onerror removed) under the default config. The carrier in this report passes that same default-config sanitizer yet keeps the handler live, defeating the asserted guarantee. A prior fix in 4.12.21 addressed a stored XSS premised on an application re-rendering editor.value as trusted HTML, so this threat model is maintainer-acknowledged. Precondition: an attacker can place HTML into the editor (a content-submission role) and the editor output is later rendered. Any integration binding value to application state in jodit-react, loading a previously stored document, or inserting content via a plugin/button will execute attacker script in the victim's page.

Suggested fix

Remove the gadget element at the source rather than re-sanitizing the output. A re-sanitize loop does not close this: nesting the carrier inside itself surfaces one level per parse, so one extra pass is bypassed at depth 2, and any fixed cap N is out-nested at depth N+2 (depth generalizes trivially). The robust fix is to drop any HTML-namespace element smuggled inside <math>/<svg> outside a spec integration point (<foreignObject>, <annotation-xml>, <desc>, <title>) during the element walk, the same approach DOMPurify's _checkValidNamespace uses. This is one pass and depth-independent. It must run on both entry points: the synchronous value-set safeHTML pass and the on-change walker (which does not call safeHTML). A regression test asserting that no on* survives a round-trip through editor.value, including the nested-carrier case, locks it in.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jodit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.12.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58263"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79",
      "CWE-83"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T19:12:40Z",
    "nvd_published_at": "2026-07-01T21:17:04Z",
    "severity": "HIGH"
  },
  "details": "### Summary\njodit\u0027s built-in `clean-html` sanitizer can be bypassed by a MathML/`\u003cstyle\u003e` carrier that hides a dangerous element from the sanitizer\u0027s element walk, so a no-interaction event handler survives into the editor value. When an application supplies attacker-influenced HTML to the editor\u0027s value-set or insertion paths, the sanitized output still contains a live `\u003cimg ... onload=...\u003e` (or another non-`onerror` handler such as `onfocus`). A consumer that renders that output (`element.innerHTML = editor.value`) executes the handler with no user interaction. This is a stored cross-site scripting vulnerability, confirmed live on the shipped `es2021/jodit.min.js` for 4.12.25 and the latest 4.12.27 (in Chromium via a client-side `innerHTML` consumer, and in Firefox via server-rendered / document-context output; see the cross-browser note under Proof of concept).\n\n### Details\nThe bypass exploits the order in which `clean-html` parses, walks, and re-serializes the value.\n\n1. On the value-set path, the `clean-html` plugin handles `:beforeSetNativeEditorValue` (`src/plugins/clean-html/clean-html.ts:116`), parsing the value into an inert document: `sandBox.innerHTML = data.value`.\n\n2. In that parse, the source nesting `math \u003e mtext \u003e table \u003e mglyph \u003e style` triggers MathML text-integration-point and foster-parenting rules: the `\u003cimg\u003e` is parsed as text inside `\u003cstyle\u003e` (rawtext), not as an element. The `\u003ctable\u003e` is foster-parented out, and the `\u003cmglyph\u003e` MathML text-integration point governs the namespace, so the `\u003cimg\u003e` never becomes an element node in this parse.\n\n3. That value-set sanitizer is `safeHTML` (`src/core/helpers/html/safe-html.ts:24`); it walks the tree but acts on elements only (the `Dom.isElement` gate at `:39`) and runs against the parse-1 `sandBox`, in which the `\u003cimg\u003e` is rawtext, not an element. So `removeAllEventAttributes` (the full `on*` strip at `safe-html.ts:76`) has no element to clean and the handler passes through. The `onBeforeSetNativeEditorValue` handler runs `safeHTML` on that parse-1 tree both before and after it captures the value, so neither pass ever sees the `\u003cimg\u003e` as an element.\n\n4. The captured value (`data.value = sandBox.innerHTML`) is then assigned to the editable, a second parse, which hoists the `\u003cimg\u003e` out of `\u003cstyle\u003e` and into the HTML namespace as a live element with its handler intact. The serialize-reparse moves the element across the tree and across namespaces:\n```\nBEFORE - parse 1 (sandBox): the \u003cimg\u003e is \u003cstyle\u003e text\n  \u003cmath\u003e          [MathML]\n    \u003cmtext\u003e       [MathML]\n      \u003cmglyph\u003e    [HTML]      integration point: content parses as HTML\n        \u003cstyle\u003e   [HTML]      text \"\u003cimg ... onload=...\u003e\"   \u003c-- \u003cimg\u003e is RAWTEXT, not an element\n      \u003ctable\u003e     [HTML]\n\nAFTER - editor.value (re-parsed): the \u003cimg\u003e is hoisted OUT of \u003cstyle\u003e, live\n  \u003cp\u003e             [HTML]\n    \u003cmath\u003e        [MathML]\n      \u003cmtext\u003e     [MathML]\n        \u003cmglyph\u003e  [MathML]\n          \u003cstyle\u003e [MathML]    (now empty)\n        \u003cimg\u003e     [HTML]      \u003c-- hoisted out, HTML namespace, LIVE -\u003e its handler fires\n        \u003ctable\u003e   [HTML]\n```\n\n5. `editor.value` now carries that live element. The value-set pass (Steps 1-4) only walked the parse-1 `sandBox` and never sees it; the other sanitizer, the on-change visitor (`visitNodeWalker` via a `LazyWalker`, `clean-html.ts:56`/`:70`), does reach the hoisted element, but its `sanitizeAttributes` filter calls `sanitizeHTMLElement` (`safe-html.ts:139`), which strips `onerror` only - it never reads the `removeEventAttributes` flag `sanitizeAttributes` passes it (`sanitize-attributes.ts:30`), so it never runs the full `on*` strip. So `onload`, `onfocus`, and every other non-`onerror` handler is never removed and persists in `editor.value` permanently. (`onerror` is the one handler the cleaner removes, but only after a ~300ms window in which it too fires.)\n\nThe two code points (jodit 4.12.27):\n```js\n// 1. clean-html.ts onBeforeSetNativeEditorValue - the SYNCHRONOUS value-set pass runs on the parse-1 sandBox:\nsandBox.innerHTML = data.value;                                       // :128  parse 1: the carrier hides the element as \u003cstyle\u003e rawtext\nthis.j.e.fire(\u0027safeHTML\u0027, sandBox);                                   // :129  safeHTML element-walk misses the rawtext element\ndata.value = sandBox.innerHTML;                                       // :130  value captured; re-parsing it into the editable hoists the element live\nsafeHTML(sandBox, { safeJavaScriptLink: true, removeOnError: true }); // :131  re-runs on the SAME parse-1 sandBox, never on the captured value\n\n// 2. the ASYNC on-change filter (LazyWalker) reaches the hoisted element, but only strips onerror:\nsanitizeHTMLElement(nodeElm, { /* ... */ removeEventAttributes: opts.removeEventAttributes });  // sanitize-attributes.ts:30 - passes the full-strip flag\nexport function sanitizeHTMLElement(elm, { safeJavaScriptLink, removeOnError } = { /* ... */ }) {  // safe-html.ts:139 - never destructures removeEventAttributes\n  if (removeOnError \u0026\u0026 elm.hasAttribute(\u0027onerror\u0027)) attr(elm, \u0027onerror\u0027, null);  // onerror ONLY; onload / onfocus / ... are left live\n}\n```\n\nAll four layers are required: removing any of `math` + the integration point, `table`, the `mglyph` slot, or the rawtext element makes jodit strip the handler (substitutes per slot are under Carrier variants).\n\nThe four-layer carrier is required only on 4.11.2 and later. jodit 4.11.2 added `cleanHTML.removeEventAttributes` (the value-set full `on*` strip); before it (all 3.x and 4.0 through 4.10.x) the sanitizer only ever removed `onerror`, so on those versions a plain non-`onerror` handler such as `\u003cimg ... onload=...\u003e` survives `editor.value` directly with no carrier (live-confirmed on 3.24.9, 4.0.1, 4.2.27). On 4.11.2 and later, the value-set walk strips the bare handler, so the carrier is needed to hide it as `\u003cstyle\u003e` rawtext past that walk; and because the on-change cleaner removes only `onerror` (Step 5), a non-`onerror` hoisted handler survives across the whole range.\n\nThe bypass is not specific to the value setter. The same carrier survives clean-html through `editor.value = X`, `editor.setEditorValue(X)`, and `editor.s.insertHTML(X)` (the API jodit\u0027s own documentation uses for plugins and custom buttons).\n\nThis is distinct from jodit\u0027s known XSS advisories: CVE-2023-42399 (GHSA-95xr-cq6h-vwr3) is an `iframe[src]` URL-scheme issue fixed in a 4.0.0 beta, and CVE-2022-23461 (GHSA-42hx-vrxx-5r6v) is a paste-from-Word `onerror` desanitization in `\u003c= 3.24.2`. Neither involves this parse-1 rawtext-hoist mechanism, and a search of the issue tracker for mglyph / mathml / mutation / \"value xss\" finds no prior report.\n\n### Proof of concept\nDefault configuration. Assign the payload, read it back, render it the way a consumer would:\n```js\nconst editor = Jodit.make(\u0027#editor\u0027);\neditor.value = \u0027\u003cmath\u003e\u003cmtext\u003e\u003ctable\u003e\u003cmglyph\u003e\u003cstyle\u003e\u003cimg src=\"data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7\" onload=alert(document.domain)\u003e\u003c/style\u003e\u003c/mglyph\u003e\u003c/table\u003e\u003c/mtext\u003e\u003c/math\u003e\u0027;\n\n// editor.value (the sanitized, stored output) now contains a live handler, and it persists (onload, like any\n// non-onerror handler, is not removed by jodit\u0027s on-change cleaner):\n//   \u003cp\u003e\u003cmath\u003e\u003cmtext\u003e\u003cmglyph\u003e\u003cstyle\u003e\u003c/style\u003e\u003c/mglyph\u003e\n//      \u003cimg src=\"data:image/gif;base64,R0lGOD...AAIBRAA7\" onload=\"alert(document.domain)\"\u003e\n//      \u003ctable\u003e\u003c/table\u003e\u003c/mtext\u003e\u003c/math\u003e\u003c/p\u003e\n\ndocument.getElementById(\u0027view\u0027).innerHTML = editor.value;  // a consumer renders the saved value\n// -\u003e the 1x1 gif loads, onload fires alert(document.domain), no interaction\n```\nCross-browser: `editor.value` carries the hoisted live `\u003cimg\u003e` in both Blink and Gecko, but the consumer\u0027s parse mode decides execution. Chromium fires it under both client-side `element.innerHTML` and document parsing; Firefox fires it only under document parsing (server-side rendering, `document.write`, `\u003ciframe srcdoc\u003e`), because under `innerHTML` Gecko leaves the `\u003cimg\u003e` in the MathML namespace, inert. No iframe is required: a plain `innerHTML` consumer suffices in Chromium, any server-rendered consumer in Firefox.\n\nPositive control, same run: a plain `\u003cimg src=x onerror=alert(1)\u003e`, a plain `\u003cimg onfocus=alert(1) autofocus tabindex=1\u003e`, and a plain `\u003csvg onload=alert(1)\u003e` are all stripped by the synchronous value-set pass to harmless output, proving clean-html is active; the same handlers pass through only when carrier-hidden as `\u003cstyle\u003e` rawtext, so the contrast isolates the rawtext-hiding step. (A plain `\u003cscript\u003e` is a separate case - the value-set pass does not remove tags; only the async on-change cleaner removes it ~300ms later - so it is not part of this synchronous control.)\n\nCarrier variants: three of the four layers accept substitutes: the MathML text-integration point (`mtext` / `mi` / `ms` / `mn` / `mo`), the integration-point child (`mglyph` / `malignmark`), and the rawtext element (`style` / `xmp` / `noembed` / `script` / `plaintext`; `title` / `textarea` / `noscript` do not work). `math` and `table` have no working substitute. The hidden element is not limited to `\u003cimg\u003e`, and any non-`onerror` handler persists permanently. Element-name blocklisting will not close this.\n\n### Impact\nStored XSS with no user interaction, in the default configuration, on the input paths that jodit\u0027s own `clean-html` is responsible for sanitizing. jodit\u0027s own test suite asserts this is a sanitization boundary: `src/plugins/clean-html/clean-html.test.js` asserts that `editor.value = \u0027\u003cp\u003etest \u003cimg src=\"\" onerror=\"alert(111)\" alt=\"\"\u003e\u003c/p\u003e\u0027` sanitizes to `\u003cp\u003etest \u003cimg src=\"\" alt=\"\"\u003e\u003c/p\u003e` (the `onerror` removed) under the default config. The carrier in this report passes that same default-config sanitizer yet keeps the handler live, defeating the asserted guarantee. A prior fix in 4.12.21 addressed a stored XSS premised on an application re-rendering `editor.value` as trusted HTML, so this threat model is maintainer-acknowledged. Precondition: an attacker can place HTML into the editor (a content-submission role) and the editor output is later rendered. Any integration binding `value` to application state in jodit-react, loading a previously stored document, or inserting content via a plugin/button will execute attacker script in the victim\u0027s page.\n\n### Suggested fix\nRemove the gadget element at the source rather than re-sanitizing the output. A re-sanitize loop does not close this: nesting the carrier inside itself surfaces one level per parse, so one extra pass is bypassed at depth 2, and any fixed cap N is out-nested at depth N+2 (depth generalizes trivially). The robust fix is to drop any HTML-namespace element smuggled inside `\u003cmath\u003e`/`\u003csvg\u003e` outside a spec integration point (`\u003cforeignObject\u003e`, `\u003cannotation-xml\u003e`, `\u003cdesc\u003e`, `\u003ctitle\u003e`) during the element walk, the same approach DOMPurify\u0027s `_checkValidNamespace` uses. This is one pass and depth-independent. It must run on both entry points: the synchronous value-set `safeHTML` pass and the on-change walker (which does not call `safeHTML`). A regression test asserting that no `on*` survives a round-trip through `editor.value`, including the nested-carrier case, locks it in.",
  "id": "GHSA-rxcw-mc6f-6hr3",
  "modified": "2026-07-31T19:12:40Z",
  "published": "2026-07-31T19:12:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xdan/jodit/security/advisories/GHSA-rxcw-mc6f-6hr3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58263"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xdan/jodit/commit/0ebb61692cbe84f9abf10ac76dd594dbb6343b90"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xdan/jodit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xdan/jodit/releases/tag/4.12.28"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jodit Editor: Mutation XSS in jodit clean-html via a MathML/style rawtext carrier"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…