# A plugin update installed a backdoor

> Merchants are told to update everything without delay. There is a rare but real case where the official update is the vector itself: when the publisher’s own build and distribution chain has been compromised.

- Source canonique : [https://allaux.fr/en/securite/mise-a-jour-d-extension-piegee](https://allaux.fr/en/securite/mise-a-jour-d-extension-piegee)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Compare each affected extension installed version against the list of trapped releases, then search the extension tree for a LicenseLoader.php file: it does not belong to its original code. Also scan the plugin list for an entry you never installed. Moving to the fixed version is not enough — the secrets read from wp-config.php have to be regenerated.

## An update installed from the publisher’s own channel

In June 2026, the build and distribution infrastructure of a WordPress plugin publisher was compromised. The merchants affected did nothing wrong: they updated paid plugins through that publisher’s official channel, and those were the packages carrying a backdoor.

The trojanised versions are Product Slider Pro for WooCommerce 3.5.2, Real Testimonials Pro 3.2.4 and 3.2.5, and Smart Post Show Pro 4.0.1. The fixed versions are 3.5.3, 3.2.6 and 4.0.2 respectively. The incident is tracked as CVE-2026-10735, CVSS score 9.8. Remediation on the publisher’s side began on 16 June 2026; the public analysis, by Wordfence, is dated 22 June 2026.

One point that narrows things down quickly: only the Pro versions, distributed through the publisher’s channel, were affected. The free versions published on the WordPress.org repository were not. If you never bought the Pro version, you are outside the scope.

## The conclusion you must not draw

This kind of incident is used as an argument by everyone who has been putting off updates for months. It is a misreading, and a dangerous one. A distribution chain compromise is rare, it covers a small number of identified versions, it is spotted and fixed within days, and the publisher names the exact packages involved.

A plugin left unpatched, by contrast, stays exposed for months or years on a flaw whose description is public and for which a fix already exists. The exposure window of a trojanised update is measured in days and only affects sites that installed the wrong version at the wrong moment. The exposure window of a site that never updates is permanent, and it widens with every new disclosure.

So what this incident really changes is not how often you update. It is the need to know exactly what runs on the site, in which version, and since when. Without that inventory you can neither clear yourself nor clean up: you cannot answer the only question that matters, which is whether you had that version on that day.

## What identifies this case after the fact

- The update history shows one of the trojanised versions installed before the move to a fixed version.
- A file named LicenseLoader.php sits inside the plugin folder, although it is not part of its original code.
- A plugin calling itself “WooCommerce Subscription” appears in the list without you ever installing it.
- The active theme’s functions.php holds a loader block reading a base64-encoded payload.
- Administrator accounts you do not recognise, or whose creation date matches no work you commissioned.
- The settings of an email-sending plugin have changed without anyone touching them.

## What has to be treated as compromised

The payload relied on a loader file named LicenseLoader.php. It extracted the full contents of wp-config.php, the administrator accounts, the credentials stored by email-sending plugins — WP Mail SMTP, Post SMTP, Easy WP SMTP — and the WooCommerce orders from the previous three months. All of that left the site. It is not a hypothesis to weigh up, it is the starting point of the clean-up.

Two persistence mechanisms were observed: a fake plugin presenting itself as “WooCommerce Subscription”, and loader code injected into the active theme’s functions.php, reading a base64-encoded payload. Updating the plugin removes neither. Moving to the fixed version is only step one, and skipping the rest is the most common mistake I see on these cases: you update, the warning disappears, you close the file.

Why the two-factor secrets have to be regenerated

Changing passwords is not enough if the second factor stays the same. The shared secret of an authenticator app is stored on the site side. If it could be read, it produces valid codes indefinitely, including after a password change: the second factor no longer proves anything, it only slows an attacker down. Revoke and regenerate those secrets account by account, which means re-enrolling every administrator.

The same logic applies to the API keys and tokens held by the email plugins. They left the site, so they must be revoked and reissued at the provider, not simply retyped into the settings form. A stolen credential stays valid until somebody revokes it at source.

## verification-fichiers.sh

```
# Fichiers PHP modifies recemment dans les extensions et les themes
find wp-content/plugins wp-content/themes -type f -name '*.php' -newermt 2026-06-01

# Recherche du fichier chargeur signale publiquement
find wp-content -type f -name 'LicenseLoader.php'
```

## The order in which I take back control

1. **Move to the fixed version** — Product Slider Pro 3.5.3, Real Testimonials Pro 3.2.6, Smart Post Show Pro 4.0.2. This closes the entry point; it removes nothing that was installed in the meantime.
2. **Strip out the persistence** — The fake “WooCommerce Subscription” plugin and the loader code injected into the active theme’s functions.php. While they remain, everything else you do can be undone remotely.
3. **Audit the administrator accounts** — Compare the list of privileged accounts against the people who should actually hold one, and check creation and last-login dates.
4. **Reset every password** — Admin accounts, database, FTP or SFTP, hosting control panel. The contents of wp-config.php left the site, which includes the credentials stored in it.
5. **Revoke and regenerate the two-factor secrets** — Account by account, with re-enrolment. A new password paired with an old secret does not restore the second factor.
6. **Revoke the email plugin credentials** — At the sending provider, not only in the site settings. Then re-read those settings: a changed sender address or forwarding rule is easy to miss.
7. **Treat the exported orders as a personal data breach** — The WooCommerce orders from the previous three months contain your customers’ data. That part of the case is documented and assessed; it is not settled by changing a password.

## The mirror image: a fake patch sent by email

> Distribution chain compromises are rare. The scenario where the merchant installs the malicious plugin themselves is far less so. A phishing campaign documented by Patchstack in April 2025 imitated an official WooCommerce alert, announced an invented flaw called “Unauthenticated Administrative Access” and invited recipients to download a patch; the link led to a fake site using an IDN homograph attack, where an accented character replaces a letter of the legitimate domain name. The downloaded file was a malicious plugin: administrator accounts with random names, hidden from the plugin list, a WP-Cron task running every minute, known webshells fetched onto the server. The rule is simple: neither WordPress nor WooCommerce ever asks you to download and install a patch by hand. Fixes ship as a new version through the official update channel.

## Related reading

- **Checking plugins before an update** — Building the inventory of installed versions — the one that lets you answer later. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))
- **An unknown file on the server** — How to qualify a file belonging to neither the core, nor the theme, nor the plugin. ([/securite/fichier-inconnu-sur-le-serveur](/securite/fichier-inconnu-sur-le-serveur))
- **Checking whether your site is compromised** — The checks to run when you suspect an install that should never have happened. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Admin passwords and shared access** — The subject that decides how long your clean-up takes the day credentials leak. ([/securite/mots-de-passe-administration-acces-partages](/securite/mots-de-passe-administration-acces-partages))

## FAQ

### How do I find out which version of a plugin was installed last month?

From backups, which contain the plugin header file with its version number, and from the site’s update logs. That is exactly why I keep an inventory of versions and their installation dates.

### I use the free version. Am I affected?

No. Only the Pro versions distributed through the publisher’s channel were affected. The free versions published on the WordPress.org repository were not.

### I installed the fixed version. Is it over?

No. The update closes the entry point but removes neither the fake plugin nor the loader code injected into the active theme, and it changes nothing about the credentials that already left the site.

### Does restoring a backup solve it?

Only partly, and only if you restore a state predating the trojanised version. A later backup contains the backdoor. Either way, restoring files does not revoke credentials that have already been exfiltrated.

### Do I have to tell my customers?

The WooCommerce orders from the previous three months were part of what was extracted, so customer personal data is involved. That part is assessed and documented as a data breach, separately from the technical clean-up.

### Should I stop buying plugins outside the official repository?

No, but you have to track them differently. A paid plugin updates through its publisher’s channel, bypassing the official repository: recording the installed version and its date, and following that publisher’s security announcements, is on you.