CVE-2026-62324: 
JavaScript vulnerability analysis and mitigation

CVE-2026-62324 is a stored cross-site scripting (XSS) vulnerability in Jodit Editor, a WYSIWYG editor with a built-in file browser and image editor. The flaw exists in the sanitizeHTMLElement method's href filtering logic, which fails to normalize javascript: scheme variants before checking, allowing attackers to bypass sanitization and execute arbitrary JavaScript when a victim clicks a crafted link. All versions up to and including 4.12.30 (npm package jodit) are affected; the issue was fixed in version 4.12.31. It carries a CVSS v3.1 base score of 5.4 (Medium), and was originally reported on June 26, 2026, with public disclosure to the GitHub Advisory Database on July 31, 2026 (Github Advisory, Jodit Security Advisory).

The root cause is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation) and CWE-83 (Improper Neutralization of Script in Attributes in a Web Page). The vulnerable code in src/core/helpers/html/safe-html.ts (line 213) uses a bare href.trim().indexOf('javascript') === 0 check to detect dangerous href values — this check is case-sensitive and does not strip C0 control bytes (\x00–\x1f), embedded tabs, or newlines before matching. Three confirmed bypass classes exist: (1) case variants such as JAVASCRIPT: or jaVaScRiPt:, (2) a leading C0 control byte (e.g., \x01javascript:), and (3) embedded tab or newline within the scheme (e.g., java\tscript:). The existing isDangerousUrl() function in the same file correctly normalizes all these forms but was explicitly excluded from href processing; the fix routes href through isDangerousUrl() like all other URL attributes (Jodit Security Advisory, Patch Commit).

Successful exploitation results in stored click-XSS: an attacker with write access to a Jodit editor instance (e.g., a content author or comment author in a multi-user application) can persist a crafted javascript: link in the stored editor value. Any user who subsequently clicks the link in a context that renders the stored HTML — such as a readonly editor, a server-rendered page, or any innerHTML consumer — will execute attacker-controlled JavaScript in that page's origin. This can lead to session hijacking, credential theft, unauthorized actions on behalf of the victim, and limited data exfiltration, though availability is not impacted. Applications that independently re-sanitize editor output before rendering are not affected (Github Advisory).

1. Gain editor write access: Obtain a low-privileged account or content author role in an application using Jodit Editor ≤ 4.12.30 (e.g., a CMS, comment system, or collaborative editor).
2. Craft an obfuscated javascript: payload: Construct an anchor tag with a javascript: href that bypasses the case-sensitive indexOf check. Example payloads include:
   • Case variant: <a href="JAVASCRIPT:alert(document.domain)">click me</a>
   • Leading C0 control byte: <a href="\x01javascript:alert(document.domain)">click me</a>
   • Embedded tab/newline: <a href="java\tscript:alert(document.domain)">click me</a>
3. Store the payload: Assign the crafted HTML to the editor value (e.g., editor.value = '<a href="JAVASCRIPT:alert(1)">click me</a>'). The sanitizer fails to neutralize the obfuscated scheme, and the malicious href persists in editor.value.
4. Wait for victim interaction: The stored content is rendered in a readonly editor, server-rendered page, or any innerHTML consumer visible to other users.
5. Trigger execution: When a victim clicks the link, the browser resolves the obfuscated javascript: scheme (stripping case differences, control bytes, or whitespace during URL parsing) and executes the attacker-controlled JavaScript in the victim's browser within the page's origin (Jodit Security Advisory, Github Advisory).

• Network: Unexpected outbound HTTP requests from victim browsers to attacker-controlled domains following clicks on editor-rendered links; unusual POST requests exfiltrating cookies or session tokens.
• Logs: Server-side application logs showing content submissions containing href values with mixed-case javascript: schemes (e.g., JAVASCRIPT:, jaVaScRiPt:), C0 control byte prefixes (\x01javascript:), or embedded whitespace (java\tscript:, java\nscript:).
• File System / Database: Stored HTML content in the application database containing anchor tags with obfuscated javascript: hrefs that were not neutralized by the editor sanitizer.
• Browser / Client-Side: Unexpected JavaScript execution (e.g., alert() dialogs, console errors, or network requests) triggered by clicking links in editor-rendered content (Jodit Security Advisory).

Upgrade the jodit npm package to version 4.12.31 or later, which routes href attributes through the existing isDangerousUrl() normalization function, closing all three bypass classes (Jodit Release 4.12.31, Patch Commit). As a workaround for applications that cannot immediately upgrade, implement server-side re-sanitization of all editor output before rendering it to users — applications that independently sanitize HTML output are not affected by this vulnerability. Additionally, applying a strict Content Security Policy (CSP) that disallows javascript: URI execution can reduce the impact of any XSS bypass.

The vulnerability was responsibly disclosed by Younghun Ko of AhnLab (@koyokr) and acknowledged in the official Jodit release notes and security advisory. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified at this time (Jodit Security Advisory, Jodit Release 4.12.31).