CVE-2026–10091: Stored XSS in Email JavaScript Cloak WordPress Plugin

When a simple shortcode becomes a persistent script injection vector

Email JavaScript Cloak is a WordPress plugin designed to hide email addresses from bots and scrapers by rendering them through JavaScript. The idea is simple: instead of placing a plain email address directly into the page source, the plugin uses a shortcode to generate a cloaked version that is harder for automated crawlers to collect.

This kind of plugin usually feels harmless. It does not manage payments, users, roles, authentication, forms, or sensitive business workflows. It simply transforms an email address into JavaScript-rendered output.

CVE-2026–10091 shows why even small content-formatting plugins can become security-sensitive.

The vulnerability affects Email JavaScript Cloak versions up to and including 1.03. It is a Stored Cross-Site Scripting issue in the plugin's email shortcode, caused by insufficient input sanitization and output escaping on user-supplied shortcode attributes.

In practical terms, an attacker able to create or influence content containing the vulnerable shortcode may inject JavaScript that is stored inside WordPress content and later executed whenever a user visits the affected page.

Vulnerability summary

CVE: CVE-2026–10091 Product: Email JavaScript Cloak Platform: WordPress plugin Affected versions: Up to and including 1.03 Vulnerability type: Stored Cross-Site Scripting Affected feature: email shortcode CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation CVSS 3.1: 7.2 HIGH Vector: AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N Known patch: No known patch available at the time of disclosure

The vulnerability is caused by improper handling of user-supplied shortcode attributes. Values passed to the shortcode are not sufficiently sanitized before processing and not safely escaped before being rendered into the final page output.

What is the vulnerable behavior?

The vulnerable feature is the plugin's email shortcode.

Shortcodes are a common WordPress mechanism that allows users to embed dynamic functionality into posts, pages, and other content areas. For example, a shortcode may generate a contact form, gallery, button, table, map, or in this case, a cloaked email address.

The problem is that shortcode attributes are still user-controlled input.

If a shortcode accepts attributes such as an email address, label, link text, subject, title, or other display-related values, those values must be treated as untrusted. They may appear simple, but they can still carry malicious HTML or JavaScript if not handled correctly.

The simplified vulnerable flow is:

1. A user creates WordPress content containing the vulnerable email shortcode.
2. The shortcode includes attacker-controlled attributes.
3. The plugin processes those attributes without sufficient sanitization.
4. The plugin renders the resulting output without proper escaping.
5. The payload becomes stored in WordPress content.
6. The script executes whenever another user views the affected page.

This is what makes the issue a Stored XSS rather than a reflected one. The malicious payload does not need to be sent in every request. Once saved, it can persist in the affected page or post.

Why Stored XSS matters

Stored Cross-Site Scripting is one of the most dangerous forms of XSS because the payload is saved inside the application.

A reflected XSS usually requires a victim to click a specially crafted link. A stored XSS can be more passive: the attacker places the payload once, and the application delivers it to future visitors as part of normal page rendering.

In WordPress, the impact depends heavily on where the payload is stored and who visits the affected content.

If the injected script executes in the browser of a normal visitor, the impact may include session-related attacks, redirects, phishing overlays, or browser-side manipulation.

If the injected script executes in the browser of an authenticated administrator, editor, or privileged user, the impact becomes more serious. JavaScript running inside an authenticated WordPress session may attempt to perform actions on behalf of that user, interact with admin endpoints, or abuse available permissions.

This is why stored XSS in content-related features should not be underestimated.

Why shortcode XSS is common in WordPress

Shortcodes are powerful, but they are also a frequent source of vulnerabilities.

The reason is simple: shortcodes sit at the boundary between content and code.

A shortcode may look like text inside a post, but when WordPress renders the page, the shortcode becomes executable plugin logic. That logic often transforms attributes into HTML, links, JavaScript snippets, image tags, iframes, buttons, or other dynamic elements.

If the plugin developer assumes that shortcode attributes are safe, XSS becomes possible.

For example, a plugin may expect an attribute to contain an email address, but an attacker may provide HTML-breaking characters, JavaScript event handlers, malformed attributes, or payloads designed to escape the expected output context.

The core security rule is:

Shortcode attributes are user input. User input must be sanitized on input and escaped on output.

Sanitization vs escaping

CVE-2026–10091 is a good case study because it involves both insufficient input sanitization and insufficient output escaping.

These two defenses are related, but they are not the same.

Sanitization happens when the application receives or processes data. It attempts to clean the value, remove unwanted characters, normalize the format, or reject invalid input.

For an email shortcode, sanitization might include validating that an email address is actually an email address, removing unexpected characters, or restricting attributes to a safe format.

Escaping happens when the application outputs data. It converts dangerous characters so that the browser treats them as text rather than executable code.

For example:

• text between HTML tags should be escaped for HTML context;
• values inside attributes should be escaped for attribute context;
• URLs should be validated and escaped as URLs;
• JavaScript strings need JavaScript-specific escaping.

A common mistake is to sanitize input once and assume the value is safe forever. That is not enough. The correct escaping depends on where the value is finally rendered.

A value that is safe in plain text may be unsafe inside an HTML attribute. A value that is safe in an attribute may be unsafe inside JavaScript. A value that is safe in storage may be unsafe in browser output.

That is why context-aware escaping is essential.

Why this plugin's purpose makes the issue ironic

Email JavaScript Cloak exists to protect email addresses from scraping. Its security goal is defensive: make email harvesting harder by hiding addresses from bots.

But the same rendering mechanism that generates cloaked JavaScript output can become dangerous if user-controlled values are placed into that output unsafely.

This is the irony of the vulnerability.

A plugin intended to reduce one web security and privacy risk can introduce another one if output handling is not strict.

The broader lesson is that protective features still need secure coding. Security-oriented functionality is not automatically secure just because its purpose is defensive.

Impact

The practical impact of CVE-2026–10091 depends on the WordPress site configuration, user roles, and where the vulnerable shortcode can be used.

Possible impact scenarios include:

• injecting malicious JavaScript into public pages;
• executing scripts when visitors view affected content;
• targeting authenticated users who view the page;
• manipulating page content in the browser;
• redirecting users to phishing or malware pages;
• stealing data accessible to the browser;
• abusing authenticated actions if a privileged user views the payload;
• damaging trust in the affected website.

Because this is stored in site content, the payload may remain active until the affected post, page, or shortcode usage is removed or cleaned.

The role question: unauthenticated or contributor-level?

One important detail deserves attention.

Some public vulnerability listings describe the issue as "Unauthenticated Stored Cross-Site Scripting," while the textual description states that attackers with contributor-level access and above can inject arbitrary scripts.

This difference matters.

If exploitation requires contributor-level access, the attacker needs an account capable of creating or editing content that includes the shortcode. That is still serious, because contributor accounts are common in multi-author WordPress sites, blogs, magazines, agencies, and community platforms.

If a site allows unauthenticated users to submit content that later renders shortcodes, the risk could become broader. However, in a standard WordPress configuration, shortcode injection through posts or pages normally requires some level of content-editing capability.

The safest interpretation is this:

Treat the issue as high risk wherever untrusted or semi-trusted users can create content that uses the vulnerable shortcode.

This includes contributor accounts, guest authors, compromised low-privilege accounts, imported content, and custom workflows that render user-submitted shortcodes.

No known patch: what should site owners do?

The most important part of this vulnerability is that there is no known patched version available at the time of disclosure.

That changes the remediation strategy.

When a patch exists, the advice is simple: update. When no patch exists, defenders need to reduce exposure.

Recommended actions:

1. Disable and remove Email JavaScript Cloak if it is not strictly necessary.
2. Replace it with a maintained alternative that properly sanitizes shortcode attributes and escapes output.
3. Search existing posts and pages for usage of the email shortcode.
4. Review content created by contributor-level users or other semi-trusted accounts.
5. Remove suspicious shortcode attributes or unexpected HTML-like values.
6. Restrict contributor and author permissions where possible.
7. Use a Web Application Firewall as a compensating control.
8. Monitor for unexpected JavaScript, redirects, or modified content.
9. Audit recently changed posts and pages if exploitation is suspected.

For many site owners, the safest option is to uninstall the plugin and replace the functionality with a safer maintained solution.

What developers can learn

CVE-2026–10091 reinforces several important lessons for WordPress plugin developers.

First, shortcodes must be treated as input handlers. Every attribute passed into a shortcode is potentially attacker-controlled.

Second, validation must be strict. If an attribute is supposed to contain an email address, validate it as an email address. If it is supposed to contain a label, treat it as plain text.

Third, escaping must happen at the last moment before output. Do not rely only on data being "clean" earlier in the flow.

Fourth, use the correct escaping function for the correct context. WordPress provides different escaping helpers for HTML text, attributes, URLs, JavaScript, and other contexts.

Fifth, never assume that only trusted users can reach a shortcode. In real WordPress environments, content creation workflows are often complex. Imported content, guest authors, page builders, custom roles, REST integrations, and compromised accounts can all change the threat model.

Why low-install plugins still matter

A plugin does not need millions of installations to be security-relevant.

Smaller plugins are often used on older sites, niche blogs, legacy installations, or custom client projects. They may receive fewer updates and less security attention. In many cases, site owners forget that the plugin is installed at all.

That creates a dangerous situation: a plugin can remain active for years, quietly handling output in a vulnerable way, even if the functionality is no longer needed.

Attackers do not care whether a plugin is popular. They care whether it is installed and exploitable.

This is especially true in WordPress, where automated scanners routinely look for vulnerable plugins across large numbers of sites.

Final thoughts

CVE-2026–10091 is a small but useful reminder of a larger WordPress security principle:

Any plugin that renders user-controlled content can become an XSS surface.

Email JavaScript Cloak was built to hide email addresses from bots, but its shortcode handling created a Stored XSS risk when attributes were not properly sanitized and escaped.

For site owners, the recommendation is clear: if the plugin is installed, review your exposure immediately. Since no known patch is available, disabling or replacing the plugin is the safest path.

For developers, the lesson is broader: shortcode attributes are not trusted data. They must be validated, sanitized, and escaped according to the exact output context.

A shortcode may look like simple content, but in WordPress it is executable plugin logic. And whenever plugin logic reaches the browser, security depends on how carefully that output is handled.