Expired Premium Plugin Licenses: A Hidden Security Gap

Wordfence's firewall has blocked more than 100,000 exploit attempts against a single premium plugin, WooCommerce Wholesale Lead Capture. The flaw was disclosed on February 20, 2026, and Wordfence's September report shows attackers kept hitting it for months afterwards. WWLC is sold through the vendor's own site, not the WordPress.org repository, which means its updates never show up the way a free plugin's updates do. That distribution model is normal for premium plugins. It's also exactly where an expired license can quietly leave a site behind.

Premium plugins run a different update system than the plugins in the WordPress.org directory, and that difference matters most when a license lapses. This guide covers how that system actually works, what typically happens when a key expires, why WordPress's own auto-update toggle can't fix it, and how to audit a site (your own or a client's) for premium plugins that have quietly fallen behind.

How Premium Plugins Actually Deliver Updates

A plugin installed from the WordPress.org directory gets its update information from api.wordpress.org. WordPress core's own plugins_api() function queries that endpoint directly, and it only knows about plugins listed there.

A premium plugin, sold from the vendor's own site or a marketplace, is never in that directory. Its author instead ships a small updater library inside the plugin that calls the vendor's own server, usually passing your license key along with the request. If the key checks out, the vendor's server hands back the newest version and WordPress shows an update in your dashboard, the same as it would for any other plugin. If the key doesn't check out, the vendor's server has nothing to hand back.

You can see this split yourself. Query the official directory API for a plugin's slug:

curl "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=SLUG"

Run that against a plugin that lives on WordPress.org, like Akismet, and you get a full JSON record with a version number. Run it against a premium plugin's slug, Elementor Pro for example, and the API returns {"error":"Plugin not found."}. That single line is the fastest way to tell which of your installed plugins depend on a vendor's own update server instead of the WordPress.org one, and it costs nothing to check.

What Typically Happens When a License Expires

Behavior varies by vendor. Many premium WordPress plugins sell licences through Easy Digital Downloads' Software Licensing extension, and its documentation describes a common pattern. When a license lapses, automatic security and feature updates are discontinued, the download link disappears from your account on the vendor's site, and support access ends. The plugin itself, per the same documentation, "will continue to work past your license expiration," though some features tied to the license may be disabled once a renewal grace period passes.

That combination, still running but no longer updating, is the trap. Nothing crashes. No admin notice necessarily appears, because the notice is often something the plugin's own code has to render, and that code isn't the part checking your license status by default. The plugin keeps doing its job on the front end while the version underneath it stops moving forward. EDD's own documentation adds a longer-term risk on top of that: because WordPress core, PHP, and neighboring plugins keep changing, "there is the possibility that the extension will eventually stop working due to other updates" it never got patched to handle.

Don't assume every vendor behaves identically. Some display a persistent nag in the plugin list, some silently stop offering updates, and some grant a short grace window before cutting off entirely. Check the specific vendor's own licensing documentation if you need the exact policy for a plugin you rely on.

Why WordPress's Auto-Update Toggle Doesn't Save You

WordPress core has supported automatic plugin updates since 2020, and it's tempting to assume that toggle covers this problem. It doesn't, and the reason is mechanical rather than a missing setting. The auto-update feature applies whatever update WordPress finds already sitting in its update transient. For a premium plugin, that transient only gets populated when the vendor's own updater successfully calls home and gets a version back.

An expired license means that call never returns a new version in the first place. There's nothing for the auto-update toggle to act on, because as far as WordPress core can tell, no update exists. Flip auto-updates on for a premium plugin with a lapsed license and you'll see zero change in behavior, not because the setting failed, but because it was never in a position to help.

Real Cases: What Falling Behind on a Premium Plugin Costs

None of the three cases below confirm the specific sites involved had expired licenses. That detail isn't part of the incident data. What they do show, clearly, is the cost of a premium plugin running an outdated, vulnerable version, whatever kept it there.

WooCommerce Wholesale Lead Capture, CVE-2026-27540. This premium plugin from Rymera Web Co is sold through wholesalesuiteplugin.com, outside the WordPress.org repository. An unrestricted file upload flaw let anyone, logged in or not, upload a PHP file to the server. Disclosed February 20, 2026, it was still being actively attacked when Wordfence reported on September 14 that its firewall had blocked more than 100,000 exploit attempts, a seven-month window during which any site on the vulnerable version was exposed. We covered the full technical detail in our WWLC exploitation writeup.

Elementor Pro, CVE-2026-32475. Elementor Pro is the licensed, paid tier of a plugin running on more than six million active sites. A validation bug in its form file-upload handling let an unauthenticated visitor write a PHP file to disk. Wordfence's telemetry shows exploitation starting the same day the fix, version 4.2.2, shipped on August 19, 2026, and blocked close to 200,000 attempts within four days. Details are in our Elementor Pro exploitation writeup.

Super Forms, CVE-2026-14894. A missing authorization check in a public AJAX handler let an unauthenticated visitor upload a file through the form builder, no password or session required. Wordfence blocked more than 250,000 exploit attempts against it. Full breakdown in our Super Forms exploitation writeup.

All three are premium products distributed and licensed outside WordPress.org's own update pipeline. That's not a coincidence specific to these plugins. It's the whole category: any plugin whose updates depend on a vendor server and a valid key inherits a way to fall silently behind that a WordPress.org-hosted plugin doesn't have.

How to Audit Your Site for At-Risk Premium Plugins

Start with a full plugin inventory and versions:

wp plugin list --fields=name,status,version,update

Then check each active plugin's slug against the WordPress.org API from the section above. Any plugin that returns {"error":"Plugin not found."} is depending on its own vendor's update server rather than the .org one, which makes it a candidate for this whole problem. A closed wordpress.org plugin also returns an error, but it reads closed, and that's a different problem covered in our abandoned and closed plugins guide. A short loop sorts every installed plugin into the right bucket:

wp plugin list --field=name | while read -r slug; do
  body=$(curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=${slug}")
  case "$body" in
    *'"error":"Plugin not found."'*) echo "NOT on wordpress.org: $slug" ;;
    *'"error":"closed"'*) echo "CLOSED on wordpress.org: $slug" ;;
    *) echo "on wordpress.org: $slug" ;;
  esac
done

Every plugin flagged "NOT on wordpress.org" needs a manual check: does it have a valid, current license, and is the installed version current against the vendor's own changelog. That's not something an API call can answer for you, since it depends on an account you may or may not have access to.

Checking License Status in Each Vendor's Dashboard

There's no universal API for this, because every vendor runs their own licensing server. The check has to happen in each plugin's own admin settings screen or its vendor account dashboard, where an active license usually shows a green "active" state, a key with a renewal date, or a similar status indicator. A lapsed one typically shows an expired or inactive state, sometimes with a renewal link right there.

Log into the vendor account under which the plugin was purchased and look for a licenses or subscriptions page. Many vendors also email a renewal reminder in the weeks before expiration, so checking the account inbox tied to the purchase is worth doing if the dashboard itself is unclear.

Comparing Your Version Against the Vendor's Changelog

Once you know a plugin's installed version, compare it against the vendor's published changelog, which is usually linked from the plugin's own product or documentation page. Look specifically for any changelog entry mentioning "security," "hardening," "vulnerability," or a CVE number between your installed version and the current release.

The WWLC changelog is a useful example of why this step matters even after an initial patch. The version that first shipped a fix for the file upload bug was followed by two more releases carrying additional "security hardening" language in the same area, exactly the kind of follow-up work a version-number check alone won't surface unless you actually read what changed.

Agency and Client Sites: When the License Lives in Someone Else's Account

Agencies managing client sites hit a version of this problem that solo site owners don't: the license may be registered to the client's own account, a previous developer's account, or a reseller bundle nobody currently at the agency has credentials for. That's a common, awkward situation, not a rare one.

Start by checking the plugin's own settings page for a partially masked license key or an account email, which at least tells you which account to chase. If the client purchased the plugin directly, ask them to check their email for the original purchase receipt, since it usually names the account and renewal date. If a previous agency or freelancer bought it under their own account, that relationship needs to be resolved directly, since only the account holder can typically renew or transfer a license. Document who owns each premium plugin's license per client site going forward. It's a five-minute note now versus a stalled renewal later.

What to Do When You Can't Renew

Sometimes the license genuinely can't be renewed: the vendor is gone, the budget doesn't stretch that far this quarter, or the account holder is unreachable. A few options, in rough order of preference:

Ask about a security-only renewal. Some vendors will sell a shorter or cheaper renewal specifically to restore update access without the full feature-tier price. It doesn't hurt to ask directly; not every option is advertised on the pricing page.

Replace the plugin with an actively updated equivalent. If the category has a maintained alternative, whether a free WordPress.org plugin or a different premium product with a current license, migrating away from stalled software closes the gap for good instead of deferring it.

Remove the plugin if it's not doing essential work. An unused or lightly used premium plugin sitting on an old, unpatched version is attack surface with no offsetting benefit. Check what actually depends on it before removing it, but if nothing critical does, removing it is often the fastest fix available.

Whatever you choose, don't leave a known-outdated premium plugin active "for now." That's the exact state the three cases above were in when Wordfence's firewall started logging exploit attempts.

A Word on Nulled Copies

Some site owners respond to a lapsed license by installing a cracked, "nulled" copy of the same plugin instead of paying for renewal or switching products. That trades one risk for a worse one: nulled plugins frequently ship with backdoors baked into the crack itself, sometimes added months after the initial install through a fake "update." We cover exactly what that looks like in our breakdown of nulled plugin risks. It's not a shortcut around this problem, it's a different and larger one.

For general hardening that applies regardless of a plugin's licensing model, our WordPress security checklist covers fifteen steps worth having in place either way.

Related guides: how to check your plugins for known vulnerabilities, abandoned and closed plugins, verifying an update is genuine, and our weekly patch list.

Run a scan on your site to check your plugin versions against our vulnerability database.

References

• Easy Digital Downloads: License Renewal documentation
• WordPress Developer Reference: plugins_api()
• WordPress.org Plugin Information API endpoint