Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

GHSA-j839-gqq4-gf9j

MEDIUMFix: xdan/jodit@5fba6ef

GHSA-j839-gqq4-gf9j is a medium-severity (CVSS 5.4) Cross-site Scripting (XSS) vulnerability in jodit. O3 Security confirms whether GHSA-j839-gqq4-gf9j is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Jodit has incomplete javascript: scheme normalization in sanitizeHTMLElement href check that allows link XSS

Also known asCVE-2026-62324
Published
Jul 31, 2026
Updated
Jul 31, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 14, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-j839-gqq4-gf9j.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk+0.04%
Lower risk than most CVEs13th percentile — riskier than 13% of all scored CVEsHighest risk
0.00%0.24%0.48%0.72%0.2%0.2%0.2%Aug 26Sep 26Sep 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-j839-gqq4-gf9j plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 372,613 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

74other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
joditnpm
126Kdownloads / week

Description

Summary

jodit's sanitizeHTMLElement neutralizes a javascript: href using a bare href.trim().indexOf('javascript') === 0 check. This omits the normalization jodit applies to every other URL attribute: isDangerousUrl strips control bytes with value.replace(/[\u0000-\u0020]+/g, '') and lowercases the value before testing the scheme. Because the href check does neither, it is bypassed by three obfuscation classes, all confirmed firing on click against the shipped 4.12.30 build:

  1. Case variants: JAVASCRIPT:, Javascript:, jaVaScRiPt: (the check is case-sensitive).
  2. A leading C0 control byte, e.g. a \x01 prefix before lowercase javascript: (trim() does not remove bytes in the \x00-\x08 / \x0e-\x1f range, but the browser strips a leading control byte before resolving the scheme).
  3. An embedded tab or newline inside the scheme, e.g. java\tscript: or java\nscript: (the browser strips tab/newline from a URL, but indexOf('javascript') sees the broken word and does not match).

The dangerous href survives editor.value = assignment and the on-change LazyWalker, persisting in the stored editor value. A victim who clicks the link in any consumer that renders the stored value (readonly editor, server-rendered page, innerHTML consumer) runs attacker-controlled JS in that page's origin.

Details

The check is in sanitizeHTMLElement at src/core/helpers/html/safe-html.ts:213:

if (safeJavaScriptLink && href && href.trim().indexOf('javascript') === 0) {
    attr(elm, 'href', location.protocol + '//' + href);
    effected = true;
}

href.trim() removes leading/trailing ASCII whitespace only, and indexOf('javascript') is case-sensitive and literal. So the check fails to fire whenever the scheme is upper/mixed-case, prefixed by a non-whitespace control byte, or split by an embedded tab/newline - all of which a browser still resolves to javascript: on click (URI schemes are case-insensitive per RFC 3986 section 3.1; leading control bytes, tabs and newlines are stripped from a URL during parsing).

The same file already contains the correct routine, isDangerousUrl() (line 176), used for every other URL attribute (src, data, action, formaction, poster, background, xlink:href):

function isDangerousUrl(value, tagName) {
    const normalized = value.replace(/[\u0000-\u0020]+/g, '').toLowerCase();
    if (/^(?:javascript|vbscript|livescript|mocha):/.test(normalized)) {
        return true;
    }
    // ...
}

isDangerousUrl strips every control byte and ASCII space (/[\u0000-\u0020]+/g) and lowercases before testing the scheme, so it resists all three obfuscations. But href never goes through it: the attribute list isDangerousUrl is applied to (URL_ATTRIBUTES) is commented "besides href", and href is handled only by the weaker indexOf check. Both the synchronous value-set path (onBeforeSetNativeEditorValue -> safeHTML -> sanitizeHTMLElement) and the asynchronous on-change path (sanitizeAttributes -> sanitizeHTMLElement) use that same weak check.

Positive controls (filter is otherwise live): a plain lowercase javascript: href IS neutralized: jodit rewrites the value to location.protocol + '//' + href, so it reads about://javascript:... on an about:blank test page and https://javascript:... on an https page. A leading ASCII space or tab IS caught by trim(); the bypass is specific to the un-normalized forms above.

Proof of concept

Default configuration. Assign a payload to the editor and read back the stored value:

const editor = Jodit.make('#editor');
editor.value = '<a href="JAVASCRIPT:alert(document.domain)">click me</a>';
// editor.value getter returns the href unchanged:
//   <p><a href="JAVASCRIPT:alert(document.domain)">click me</a></p>
document.getElementById('view').innerHTML = editor.value;
// Clicking "click me" runs alert(document.domain) in the consumer's origin.

The same persists for the leading-control-byte form (a \x01 prefix before lowercase javascript:) and the embedded-tab/newline forms (java\tscript: / java\nscript:). Verified live on the shipped es2021/jodit.min.js for jodit 4.12.30. Positive controls in the same run: <img src=x onerror=...> stripped; lowercase javascript: neutralized to location.protocol + '//' + href (about://... on the about:blank test page used here, https://... on an https page).

Impact

Stored click-XSS. An attacker with write access to an editor instance (content author, or comment author in a multi-user application) stores a crafted javascript: link. Any user who clicks it in a view that renders the stored value (readonly editor, server-rendered page, innerHTML consumer) runs attacker-controlled JS in that origin. One user interaction (the click) is required. A consumer that re-sanitizes the editor output before rendering is not affected.

Suggested fix

Route href through the existing isDangerousUrl() rather than the bespoke indexOf check. isDangerousUrl already strips control bytes and lowercases, so it closes the case, control-byte, and embedded-whitespace bypasses at once:

-	if (safeJavaScriptLink && href && href.trim().indexOf('javascript') === 0) {
+	if (safeJavaScriptLink && href && isDangerousUrl(href, elm.nodeName.toLowerCase())) {
 		attr(elm, 'href', location.protocol + '//' + href);
 		effected = true;
 	}

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmjoditall versions4.12.31

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jodit. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update jodit to 4.12.31 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-j839-gqq4-gf9j is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-j839-gqq4-gf9j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-j839-gqq4-gf9j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary jodit's `sanitizeHTMLElement` neutralizes a `javascript:` `href` using a bare `href.trim().indexOf('javascript') === 0` check. This omits the normalization jodit applies to every other URL attribute: `isDangerousUrl` strips control bytes with `value.replace(/[\u0000-\u0020]+/g, '')` and lowercases the value before testing the scheme. Because the `href` check does neither, it is bypassed by three obfuscation classes, all confirmed firing on click against the shipped 4.12.30 build: 1. Case variants: `JAVASCRIPT:`, `Javascript:`, `jaVaScRiPt:` (the check is case-sensitive). 2. A lea
O3 Security · Impact-Aware SCA

Is GHSA-j839-gqq4-gf9j in your dependencies?

O3 detects GHSA-j839-gqq4-gf9j across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-j839-gqq4-gf9j: jodit XSS (Medium 5.4) | O3 Security