# I paid for my plugins: am I better protected

> The instinct is reasonable: a publisher who gets paid can afford to have its code reviewed. The figures published by the bodies that track these flaws tell a distinctly less comfortable story.

- Source canonique : [https://allaux.fr/en/securite/extensions-payantes-sont-elles-plus-sures](https://allaux.fr/en/securite/extensions-payantes-sont-elles-plus-sures)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> The useful criterion is not price but how often fixes ship. For each installed extension, look at the date of the latest release, how many releases came out over twelve months, and whether the vendor has a channel where security fixes are announced. Paid extensions often update only with an active licence: check yours still is.

## What the price actually buys

The reasoning holds in principle: a publisher who lives off sales can employ someone, run a support desk, ship quickly. That’s true, and I never advise defaulting to the free version of a component. But it pays to be precise about what the invoice covers.

It covers support — someone who answers when things break. It covers features the free build doesn’t have. Sometimes it covers a written maintenance commitment over a fixed period, guaranteeing compatibility updates. Three useful things, and I recommend them.

What it almost never covers is a security review of the code by someone who does that for a living. Nothing in a module’s price guarantees that an outside pair of eyes looked for missing authorisation checks or unfiltered input before it went on sale. Support quality and code security are separate dimensions, and paying mostly improves the first.

| Valeur | Description |
|---|---|
| 76% | of vulnerabilities reported in premium components were exploitable |
| 59% | of reports concerning premium components were high priority |
| 3x more | actively exploited vulnerabilities on the premium side than on the free side |

Source : Patchstack, State of WordPress Security in 2026 (2025 figures)

## Why paid components are structurally less well watched

I don’t read those figures as “paid is worse”. That would be as wrong as the opposite, and the bias is easy to spot: paid components tend to be more complex, closer to order data, and installed on shops that can afford them — so more interesting. But three structural mechanisms genuinely weigh on the outcome, and they come from how these plugins circulate, not from their authors’ diligence.

They don’t go through the public repository. A component published on an official repository is visible to anyone, reviewed by volunteers, scanned by automated tooling, and can be pulled the day a flaw is confirmed. A component sold from its publisher’s own site is only examined by those who bought it.

They don’t get the repository’s automatic updates. The CMS update mechanism only sees the official channel. A paid extension updates through its own licence system, which has to be valid, correctly configured, and which often stops working when the subscription lapses.

Their flaws are reported publicly less often. Auditing the code means buying a licence first, which few researchers do spontaneously. A flaw can therefore sit there undocumented — not harmless, just invisible to you.

The wider context is unambiguous: of the 11,334 new vulnerabilities recorded across the WordPress ecosystem in 2025, 42% more than the previous year, 91% were in plugins and 9% in themes. The CMS core accounted for just 6, all low severity. The risk isn’t the platform, it’s what gets added to it — free or paid.

## Three cases that shift the argument

Paying can itself be the exposure. In June 2026 the build and distribution infrastructure of publisher ShapedPlugin was compromised: several versions of its Pro plugins shipped with malicious code that pulled the site configuration, administrator accounts, mail-sending credentials and the last three months of WooCommerce orders. Remediation began on 16 June 2026, publication followed on 22 June 2026, and the reference is CVE-2026-10735, scored 9.8. The part that matters: only the Pro builds, distributed through the publisher’s own channel, were affected. The free versions on the WordPress.org repository were not.

A major publisher isn’t immune. The official ps_checkout module, published by PrestaShop, was hit by CVE-2025-61922, scored 9.1: a missing validation in the Express Checkout feature allowed a customer account to be taken over from its email address, with no privileges and no user interaction. Fixes shipped on 16 October 2025 in versions 4.4.1 and 5.0.5. Resources and diligence lower the risk; they don’t remove it.

A contract doesn’t outlive its publisher. In May 2026 an advisory documented CVE-2026-39079, scored 8.6, on a PrestaShop shipping module whose log directory was publicly reachable, exposing API credentials and customers’ personal data. No fix will ever be published: the publisher has ceased trading. The only remediation is removing the module — deactivating it isn’t enough. That’s the blind spot of buying: you pay for software, not for the survival of whoever maintains it.

## How to judge a publisher on something other than price

1. **Release frequency** — Read the changelog for the last two years. A publisher shipping regularly, small fixes included, has a living process. A component frozen for eighteen months while the CMS moved several times is a gamble, whatever it costs.
2. **Whether a security page exists** — An address for reporting a flaw, a disclosure process, a history of published advisories. A publisher with no way to receive a report won’t handle it faster because you’re a customer.
3. **Demonstrated responsiveness on past advisories** — Look up security advisories already published on their components and measure the gap between report and fixed release. It’s the only indicator based on facts rather than sales copy.
4. **The question to ask before paying** — “How will I be told if a flaw is published in this module?” If there’s no security mailing list, no back-office notification and no written commitment, the real answer is: you won’t be, and watching for it is on you.

## The list almost no shop has

> I ask for the same thing before every job: the list of paid components installed, each with its publisher, the version in place, the licence status and, above all, the answer to one plain question — does this one update itself, or must someone fetch it by hand? That last column is the one that matters. Those are the components that sit on a vulnerable version for months after a fix ships, not through neglect, but because nothing in the dashboard says a new version exists. Anything that doesn’t update itself has to be tracked manually, or replaced with something that does.

## Related reading

- **Abandoned modules and extensions** — What happens when a publisher, paid or not, stops shipping fixes. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Tracking flaws that affect your store** — How to hear about the components nobody will notify you about. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Checking plugins before an update** — Taking stock of versions and licences before touching the site. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))
- **PrestaShop modules** — The problems I most often meet on a shop’s third-party modules. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### Does this mean free plugins are safer?

No, and that would misread the figures. Free components account for the overwhelming majority of recorded vulnerabilities by volume. What the premium figures show is that price isn’t a security indicator: judge the publisher, its release cadence and how it handles reports, not the size of the invoice.

### Is an expired licence a security problem?

Yes, nearly always. On most paid components the licence is what authorises update downloads. An expired licence means the module keeps working but stays frozen at the version it had on expiry, including when a security fix ships afterwards. It’s one of the most common causes of vulnerable components I find on otherwise well-kept shops.

### How do I know whether my paid plugins update automatically?

Check component by component whether a new version shows up in the back office, or whether you have to log in to the publisher’s site to get it. The CMS’s built-in mechanism only sees the official channel; everything else relies on the publisher’s own licence system, which must be active and correctly configured.

### What should I do with a paid module whose publisher has gone?

Remove it, not just deactivate it: on many installations a deactivated module’s files stay reachable and executable. If it performs an essential function, plan its replacement, and in the meantime restrict access to its files at server level as tightly as possible.

### Is an official platform module more reliable than a third-party one?

It’s usually better maintained, with a clear reporting process and fixes shipped quickly, which counts for a lot. But it isn’t exempt: an official PrestaShop module was affected by a flaw scored 9.1 allowing customer account takeover, fixed in October 2025. The difference is in how fast flaws get fixed, not in their absence.