If you received an email from me pointing you to this page, it is because your website appears to be running a version of Welcart e-Commerce (the free WordPress e-commerce plugin by Welcart / Collne, which lives in your files at /wp-content/plugins/usc-e-shop/) that falls within the affected range of a known security issue. This page explains what the issue is, how much it matters for your site, how to read your version without being misled, and how to update.

The issue is CVE-2026-19914, an unauthenticated stored cross-site scripting (XSS) flaw. It affects every release up to and including 2.12.1 and is fixed in 2.12.2, released on 31 August 2026. If you are running 2.12.1 or anything older, update Welcart to 2.12.2 or later. The issue is rated CVSS 7.2 (High), as scored by Wordfence. I am not aware of any public exploit code for it.

There is no older version that is safe. This is not a flaw that was introduced partway through the plugin’s history and later fixed. The unescaped rendering behind this issue has been present throughout the plugin’s history - I confirmed it is present as far back as version 1.7.0 - so “my install is too old to be affected” is not a way out here. The only versions that are not affected are 2.12.2 and newer.

Before anything else, a word on what this issue is and how it is delivered, because I would rather state it plainly than let the notice sound bigger than it is. This is a stored cross-site scripting flaw, and the script it can run does so in the browser of a shop administrator, not in a visitor’s browser. For that to happen, two separate things both have to occur: someone placing an order as a guest has to submit a crafted value in a custom order field at checkout, and then an administrator has to open that order on the order-editing screen in your WordPress admin area. The submitted value is stored with the order and rendered on that screen without being escaped, so it runs when the order is viewed.

I can read your Welcart version from a public file, but I cannot see your orders, cannot see whether any order carries a crafted value, and cannot see whether anyone has actually done this to your site. So this notice is a precautionary heads-up based on your version number, not a confirmed finding about your site.

It is also worth being precise about what this issue is and is not. Cross-site scripting that fires in an administrator’s session is a real problem worth fixing: script running while an administrator is logged in can act with that administrator’s privileges for as long as the page is open. But it is not, by itself, a full site takeover. It is not remote code execution on your server, and it is not a way for an unauthenticated stranger to simply hand themselves an administrator account. It is narrower than the full-compromise issues I write about elsewhere, and it depends on both an order being submitted and an administrator opening it, so I would rather set the scale honestly than leave you with a scarier impression than the facts support.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Welcart plugin itself is on an affected version.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, place an order on it, or exploit anything.

All I did was look at pages and files that your website serves to every visitor (the same way your homepage is public) and note the version number that the plugin publishes. I specifically did not place an order, submit anything through your checkout, log in, or send anything to the affected feature. Nothing about this check touches your data, your admin area, your orders, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

Welcart turns a WordPress site into an online shop, and it is the most widely used e-commerce plugin for WordPress in Japan. Part of what it does is take a customer’s details at checkout, including any custom order fields a shop has added to collect extra information, and store them alongside the order so staff can review them later.

In affected versions, a value submitted into a custom order field during a guest checkout is stored with the order and then displayed on the order-editing screen in your WordPress admin area without being escaped. Escaping is what turns text that looks like markup back into plain text for display. Without it, a value crafted to contain active content is not shown as text but is instead run by the browser of whichever administrator opens that order. Because a guest can place an order without logging in, the person who supplies that value does not need any account on your site at all.

The precondition, to state it plainly because it is the part most likely to be misread in either direction: this needs both a crafted order to have been submitted and an administrator to open it. It does not fire on your storefront, and it does nothing to ordinary visitors. What it reaches is the session of a shop administrator viewing orders in wp-admin.

I am describing this at the level a site owner needs in order to act, and no further. I am not publishing the details that would let someone reproduce it, and I would ask you not to try it against your own site or anyone else’s. Reading your version number, as described below, tells you everything you need to decide what to do.

If my email cited this issue, it means the version your site reports is 2.12.1 or older. I did not test whether your particular site is exploitable, and I cannot see your orders. All I observed is the version.

Am I affected?

It comes down to one question: which version of Welcart are you running?

From the WordPress admin area (authoritative):

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Go to Plugins then Installed Plugins.
  3. Find Welcart e-Commerce, the entry whose folder is usc-e-shop, and note the version shown beneath its name.

From the public manifest (no login needed): open

yourdomain.com/wp-content/plugins/usc-e-shop/readme.txt

in a browser, and read the Stable tag: line near the top. If that address returns a “not found”, try README.txt with capital letters - some hosts are case-sensitive and a few packages ship the file capitalised.

From your page source (no login needed): view the source of your home page and look for the plugin’s own stylesheet at exactly this path:

/wp-content/plugins/usc-e-shop/css/usces_default.css?ver=...

The ?ver= number attached to that file is the plugin’s own version, and it is the public source I read. Welcart loads this stylesheet on its shop pages, so a shop or cart page is a reliable place to find it. Read the version only off usces_default.css: other files written into your page carry their own, entirely unrelated ?ver= numbers, and reading the first one you find can leave you with the version of a different piece of software. If you cannot get a readable number out of the page source at all, that is common and is not a sign of anything - caching and optimisation plugins routinely strip the ?ver= value off asset URLs - so use the readme.txt or the admin screen instead.

Then apply this rule, and note that versions compare numerically, not alphabetically, so 2.12.1 is newer than 2.9.1 even though “12” looks smaller than “9” as text:

  • 2.12.1 or older: affected. Update to 2.12.2 or later. There is no cut-off below which an older release becomes safe again.
  • 2.12.2 or newer: already fixed as far as this issue is concerned. Taking the latest available version is the best move.

How to upgrade

The plugin is free, still published, and actively maintained, so the fix is a normal update. The safest path is to update through WordPress itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a WordPress backup plugin.
  2. In the WordPress admin, go to Dashboard then Updates, or Plugins then Installed Plugins. If a Welcart update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update usc-e-shop (the command uses the folder name, not the display name).
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Welcart e-Commerce, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (2.12.2 or later) using the steps above, and open a recent order in your admin area to make sure the order screens still display normally.

The 2.12.2 release also addressed other security issues besides this one, so updating is worth doing regardless. While you are in there, it is worth confirming that WordPress core and your other plugins are up to date, since the same principle applies to all of them.

After updating

Updating to 2.12.2 or later closes the issue, and for most sites that is the whole task. This page is a precautionary notice, not an incident report: I have no visibility into whether anything happened on your site, and I did not look.

One small thing is worth doing while the update is fresh:

  • Confirm the version actually moved, using whichever of the checks above was easiest, and open an order in your admin area to make sure the order screens still render.

You will notice there is no “assume you have been compromised” checklist on this page, and that is deliberate rather than an omission. What this issue yields is script running in an administrator’s browser, and only where both a crafted order was submitted and an administrator later opened it. It does not run code on your server, and it does not by itself create an administrator account, so the administrator audit and password-rotation drill I recommend after a takeover-class flaw would not be proportionate here. Update, confirm, and carry on. If you have a specific reason to believe this was used against your site - which this notice, based only on a version number, gives you no evidence of

  • then treating your administrator logins with ordinary caution is reasonable, but the version alone does not call for it.

What I did and did not do

To be fully transparent about the check behind my email: I only read files that your site already serves to every visitor, specifically your home page and the address of the Welcart stylesheet written into it, and the plugin’s public readme.txt inside wp-content/plugins/usc-e-shop/. I did not access your WordPress admin area, your database, your orders, or any private part of the site.

In particular, I never placed an order, submitted anything through your checkout, logged in, or sent anything to the affected feature. Nothing was submitted, tested, or exploited. That matters here, because submitting a crafted value at checkout is close to the exact action this issue concerns, so “I did not touch it” is the whole difference between a disclosure and an intrusion.

I am also deliberately not publishing the details that would help someone act on this issue. The description above stops at the level a site owner needs, and I do not link any proof-of-concept code.

This is a version-based observation: your site reports a version of 2.12.1 or older. It is not a statement that your site was exploitable at the time I checked. Because this issue depends on both a crafted order being submitted and an administrator opening it - things I cannot see - a site in the affected range may well not have been exposed, and a site in that range may separately be protected by other means such as a web application firewall or a backported fix. If you have already updated, or otherwise remediated this, no action is needed, and I apologise for the noise.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / plugin