Jeg Kit for Elementor CVE-2026-100180: Stored XSS, Patch Now

A WordPress add-on installed on more than 300,000 sites just shipped its second unauthenticated comment-to-script fix in three weeks. On October 3, 2026, Wordfence published CVE-2026-100180, a stored cross-site scripting (XSS) flaw in Jeg Kit for Elementor that lets an unauthenticated visitor plant JavaScript through a blog comment. The fix is version 3.2.20. If you patched to 3.2.17 last month and assumed the comment problem was closed, it was not.

Stored XSS in a comment is worse than its score suggests. The payload lives in your database, not in a link a victim has to click, so it runs in the browser of everyone who later loads the affected page: readers, logged-in editors, you. Wordfence rates it 5.4 (medium) because the cleanest, no-moderation path needs one precondition, and that precondition happens to be the WordPress default.

Who is exposed

Jeg Kit for Elementor, also listed as Jeg Elementor Kit, is an Elementor extension with more than 300,000 active installs per its WordPress.org listing. Every site running version 3.2.19 or earlier is affected. The bug is CWE-79, improper neutralization of input during web page generation, and it is network-reachable with no authentication, scored 5.4 (medium).

The attack-complexity rating is high for a single reason: the most reliable route to immediate persistence needs the attacker's email address to already have one approved comment on the site. On a default WordPress install that is a low bar. WordPress ships with "comment author must have a previously approved comment" enabled, so once any one comment from an address clears moderation, every later comment from that address publishes automatically. Post one harmless comment, wait for approval, then post the payload.

What the flaw lets an attacker do

Wordfence attributes the issue to the plugin failing to clean and escape what people type into comments, and specifically to a widened allowlist that bypasses sanitization regardless of approval status. In plain terms, the plugin loosens the set of HTML that WordPress normally strips from comments, and that loosened set is wide enough to carry executable script onto the page. When a visitor opens a post that renders the plugin's front-end, the stored markup runs in their session.

Low confidentiality and integrity impact on paper. In the field, stored XSS that fires inside a logged-in administrator's session is a path to stolen cookies, a rogue admin account, or injected redirects and search spam. That is why a persistent comment payload deserves more urgency than a medium label implies.

Two comment flaws in three weeks

This is the part worth sitting with. On September 18, 2026, the same plugin received CVE-2026-18405, also an unauthenticated stored XSS via comment, rated 7.2 (high) and fixed in 3.2.17. That one hinged on the plugin's Countdown widget: its front-end script initialized on any matching element in the page, including forged widget markup an attacker had stored inside a comment. Three weeks later, 3.2.20 closes a second comment path. Same plugin, same bug class, same delivery channel, two CVEs and two patches apart.

The lesson for operators is one we keep relearning: a point fix on a vulnerability class is not the same as closing the class. If your patch policy treated 3.2.17 as "the comment XSS is handled," 3.2.20 is the correction. Cross-site scripting is the single most common bug class our desk tracks, and add-ons that reach into WordPress comment handling to render their own markup are a recurring source of it. We saw the same unauthenticated comment-XSS shape in the Bookly booking plugin and in WordPress core itself.

Find out if you were already hit

Patching stops new injections; it does not remove a payload already sitting in your comment table. On a host with WP-CLI, confirm the installed version and scan approved comments for the usual script markers before you assume you are clean.

wp plugin get jeg-elementor-kit --field=version
wp comment list --status=approve --search="<script" --field=comment_ID
wp db query "SELECT comment_ID, comment_post_ID, comment_author_email FROM wp_comments WHERE comment_content REGEXP 'onerror=|onload=|onmouseover=|javascript:|<script'"

A hit is not proof of this CVE specifically, but any approved comment carrying a <script> tag, an inline event handler, or a javascript: URL is something to pull and investigate no matter which plugin let it through. Remember the table prefix may not be wp_ on your install.

Update to 3.2.20, then audit the comment table

• Update Jeg Kit for Elementor to 3.2.20 or later now. No partial workaround beats the patch.

• If you cannot update immediately, raise comment moderation so nothing publishes without manual review, and turn off automatic approval for returning commenters until you have patched.

• Run the comment scan above and pull any entry with script-like content for review.

• If you find an injected payload, reset credentials for any account that may have loaded the affected page while logged in.

Stored XSS is quiet by design: it knocks nothing over, so it rarely surfaces in an uptime check. Catching it means watching for the vulnerable version across the hosts you run and for anomalous content landing in places that render to visitors. That kind of continuous vulnerability detection across your real stack is what turns a medium-severity plugin bug from a silent liability into a ticket you close the same week. For the wider pattern, we logged five critical WordPress plugin and theme flaws in a single recent batch; the add-on layer is where most of this risk now lives.