Failles WordPress d’octobre 2026 : ce que chaque site tunisien doit vérifier et corriger

Un site WordPress passé en 7.0.2 cet été pour échapper à wp2shell est aujourd’hui classé vulnérable par WordPress.org : six versions de sécurité ont suivi, la dernière le 28 octobre. Ce guide ne traite que du code du site, c’est-à-dire le cœur de WordPress, ses extensions et ses thèmes. La faille du moteur PHP corrigée le 21 octobre se joue un étage plus bas, sur le serveur : voir ce qui relève du serveur et ce qui relève du site. Faits arrêtés au 29 octobre 2026 au soir, chaque source citée en lien.

L’essentiel en cinq points

• Au 29 octobre, seule la dernière version de chaque branche de WordPress est sûre : 7.1.4, ou 7.0.8, 6.9.11, 6.8.12… pour un site resté sur une branche plus ancienne.
• Deux attaques contre le cœur sont confirmées par le catalogue des failles exploitées de l’agence américaine CISA : wp2shell en juillet, CVE-2026-87902 en septembre.
• Côté extensions, Elementor Pro et Bricksforge ont été attaquées dès la publication de leur faille, et des copies de Rank Math SEO PRO ont été piégées chez l’éditeur pendant onze heures.
• Mettre à jour ferme la porte sans faire sortir un intrus : un site resté exposé plusieurs jours se contrôle ensuite (comptes, fichiers, tâches planifiées, journaux).
• PHP2Shell et ces failles s’additionnent : un PHP réparé ne protège pas un WordPress en retard, et l’inverse non plus.

Juillet-octobre 2026 : sept versions de sécurité, sept bulletins

Depuis le 17 juillet, WordPress a publié sept versions de sécurité, et le tunCERT de l’ANCS a consacré un bulletin à chacune (liste des bulletins). Ces bulletins concernent plus d’un site en .tn sur deux parmi ceux dont le CMS est identifié : WordPress en fait tourner 58,2 %, selon le relevé de W3Techs du 29 octobre (W3Techs, CMS des sites en .tn).

Chaque correctif est aussi reporté, quand la branche est touchée, sur les branches plus anciennes jusqu’à la 4.7 (voir le tableau des versions sûres).

Trois de ces failles figurent au catalogue des vulnérabilités exploitées de la CISA : CVE-2026-63030 et CVE-2026-60137 depuis le 21 juillet, CVE-2026-87902 depuis le 25 septembre (fiche NVD de CVE-2026-63030, fiche NVD de CVE-2026-87902). Le bulletin du tunCERT du 20 juillet signalait déjà que les failles wp2shell étaient activement exploitées.

wp2shell, la plus grave

wp2shell enchaîne deux défauts : une confusion de routes dans le point d’accès « batch » de l’API REST (CVE-2026-63030, notée 9,8 sur 10) et une injection SQL dans le paramètre author__not_in de WP_Query (CVE-2026-60137). Ensemble, ils donnent l’exécution de code à un inconnu, sans compte, sur WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 ; la branche 6.8 n’est touchée que par l’injection SQL, et seulement quand une extension ou un thème transmet une saisie non filtrée à ce paramètre (avis GHSA-ff9f-jf42-662q, avis GHSA-fpp7-x2x2-2mjf).

Vu la gravité, WordPress.org a forcé la mise à jour automatique des sites concernés (annonce de la 7.0.2). Cela n’a pas suffi partout : le 21 juillet, selon BleepingComputer, le tableau de bord du chercheur Yutaka Sejiyama comptait 81,6 % de sites corrigés sur un échantillon de 124 580 (BleepingComputer, 21 juillet). Wordfence a vu les premiers sondages à 23 h 29 (UTC) le 17 juillet (Wordfence), et des démonstrations d’exploitation sont devenues publiques dans la foulée (même article de BleepingComputer). Après l’entrée, les attaquants ont téléversé des extensions piégées et des portes dérobées PHP, et tenté de lire wp-config.php pour en tirer les accès à la base (Wiz).

CVE-2026-87902 : tout dépend du thème

La faille du 22 septembre touche toutes les versions de 4.7.0 à 7.1.1. Sans compte, un attaquant peut faire charger par WordPress un fichier PHP situé hors du thème. Pour aller jusqu’à l’exécution de code, il lui faut deux conditions : un thème actif, parent ou enfant, qui a à sa racine un dossier dont le nom commence par page- (l’avis cite Twenty Twelve, Twenty Fourteen, Neve, Hestia et Sydney), et sur le serveur un fichier PHP exploitable, comme pearcmd.php quand le réglage register_argc_argv de PHP est actif, ce qui est le cas par défaut sous cPanel avec un PHP antérieur à 8.5 (avis GHSA-7hp8-65ch-5whp). Patchstack a relevé une première tentative le jour même du correctif, à 11 h 49 (UTC), et des outils de scan publics dès le lendemain (Patchstack, 22 septembre, mis à jour le 23).

Quelle version de WordPress est sûre aujourd’hui ?

WordPress.org publie l’état de chacune de ses versions : à jour, dépassée ou vulnérable. Au 29 octobre, seule la dernière version de chaque branche échappe à la mention « vulnérable » (état des versions sur WordPress.org) ; ces versions ont toutes été publiées le 28 octobre.

Les versions sûres, branche par branche

Deux choses à retenir. Une mise à jour mineure reste dans sa branche : un site en 6.8 passe à 6.8.12, pas à 7.1, ce qui limite le risque de casse ; c’est elle qu’on applique tout de suite. Ensuite, ces reports restent une facilité : chaque annonce rappelle que seule la dernière version est activement prise en charge. D’après les statistiques de WordPress.org, 64,4 % des installations sont sur la branche 7.1 ; les autres ont intérêt à préparer le passage avant la 7.2, annoncée pour le 8 décembre (annonce de la 7.1.4).

Les extensions à contrôler en priorité

Les failles du cœur se corrigent souvent toutes seules. Celles des extensions dépendent de vous, de votre licence et de la personne qui gère le site : nos packs WordPress permettent d’automatiser les mises à jour du cœur, des extensions et des thèmes depuis le WordPress Toolkit, avec vérification avant application, mais une extension payante sans licence active ne reçoit rien. Voici celles d’août à octobre qui méritent un contrôle immédiat, avec la version qui les corrige selon l’éditeur ou la base qui les a publiées. Les installations sont les seuils affichés par WordPress.org.

Les extensions touchées et leurs correctifs

« — » : aucune exploitation rapportée par les sources consultées au 29 octobre ; cela peut changer en quelques heures. Chaque ligne renvoie à sa source en fin d’article.

Elementor Pro : regardez vos formulaires

La faille CVE-2026-32475 (Patchstack, 19 août) ne demande qu’un formulaire Elementor publié avec un champ d’envoi de fichier non obligatoire, le réglage par défaut (CV, devis, pièce jointe). L’extension gratuite Elementor n’est pas visée : l’avis ne porte que sur Elementor Pro. Un premier fichier vide fait s’arrêter le contrôle des extensions, et le fichier PHP qui suit atterrit dans un dossier public. Si un tel formulaire tournait en 4.2.1 ou avant, ouvrez wp-content/uploads/elementor/forms/ : un fichier .php y est un signe d’intrusion, en général nommé de treize caractères hexadécimaux. Wordfence a bloqué plus de 190 000 tentatives du 19 au 23 août (BleepingComputer, 3 septembre).

Bricksforge : attaquée le soir même

Patchstack a publié la faille dans sa base le 7 octobre avec la note maximale de 10 (CVE-2026-85097, notée 9,8 par Wordfence, qui a attribué l’identifiant : fiche NVD), et relevé les premières tentatives à 21 h 47 (UTC) le même jour (The Hacker News, 12 octobre). L’extension valide une image contenant du PHP, puis fait confiance à un nom de fichier en .php fourni au moment de l’envoi du formulaire. À contrôler : wp-content/uploads/bricksforge/tmp/, les autres dossiers d’envoi, et tout fichier login_admin_*.php (Cybersecurity News). L’éditeur a publié depuis la 4.0.1 (8 octobre), qui corrige un autre problème du même module, puis la 4.0.2 (13 octobre), qui revoit tous ses points d’accès REST : prenez la dernière.

Duplicator : le danger arrive à la prochaine migration

CVE-2026-82814 est un piège à retardement. Un inconnu glisse un contenu préparé dans une partie publique du site, un commentaire par exemple ; il ne se déclenche que si un administrateur crée ensuite une archive, puis lance une migration ou une importation. Avec la version gratuite, l’attaquant peut alors exécuter des commandes sur le serveur (fiche NVD). Le code fautif appartient à l’installateur livré avec l’archive : mettez l’extension à jour avant votre prochaine migration, refaites les archives créées avant, et ne laissez ni archive ni installateur sur le serveur une fois l’opération terminée. Si vous comptiez sur Duplicator pour changer d’hébergeur, notre équipe peut se charger de la migration de votre site.

Kirki : une extension qui a changé de nature

Longtemps simple outil de personnalisation, Kirki se présente désormais comme un constructeur de pages (« Freeform Page Builder »). Patchstack lui compte plus de trente failles publiées depuis juillet ; la plus récente est corrigée en 6.4.1, sortie le 28 octobre. Si un thème vous a fait installer Kirki, vérifiez qu’il en a encore besoin : une extension inutile reste une porte.

Rank Math PRO : quand la mise à jour elle-même était piégée

Du 15 octobre à 20 h 02 (UTC), soit 21 h 02 à Tunis, au 16 octobre à 7 h 12 (UTC), soit 8 h 12 à Tunis, une partie des paquets de Rank Math SEO PRO 3.0.123 distribués par l’éditeur contenaient un logiciel malveillant (avis de Rank Math, CVE-2026-111862). Un site qui a activé l’un de ces paquets doit être considéré comme compromis : selon l’éditeur, le code peut s’installer durablement, communiquer avec le domaine rank1cdn.com, recréer des portes dérobées à chaque visite et exposer les mots de passe, les accès à la base et les clés d’API. La version gratuite, distribuée par WordPress.org, n’est pas touchée, et posséder la 3.0.123 ne prouve rien : tout dépend du moment où le paquet a été récupéré.

Les traces publiées par l’éditeur

• dans la table wp_options, les entrées _uf6qdn2hmm, t8krdk990phb et _np5pvf754c ;
• des administrateurs dont l’identifiant commence par wpsupport_ ou dont l’adresse se termine par @wp-mail.net ;
• un faux fichier du cœur, wp-includes/class-wp-cache-util.php, et des fichiers .cache contenant du PHP, rendus exécutables par une règle .htaccess ;
• le marqueur #ms6v46 dans la crontab du compte du serveur web ;
• du code mêlant base64_decode et des boucles XOR, la clé xmmqhn ou proc_open, à chercher dans mu-plugins, dans les autres extensions, dans les dossiers inc/, includes/ et lib/ des thèmes, et dans uploads/.

Rank Math conseille de restaurer une sauvegarde antérieure au 15 octobre à 20 h 02 (UTC), de changer tous les accès, puis d’installer la 3.0.124 depuis le compte Rank Math. À défaut, il faut commencer par supprimer le dossier rank-math-pro (le désactiver ne suffit pas) et les trois entrées de wp_options, avant toute autre recherche. L’éditeur précise qu’il n’envoie jamais de lien de téléchargement par courriel.

La leçon n’est pas d’arrêter les mises à jour : la 3.0.124, propre, arrive par le même canal. Deux réflexes : ne récupérer la version corrigée que depuis le compte Rank Math, jamais depuis un lien reçu par courriel, et garder des sauvegardes assez anciennes, car une copie écrasée chaque nuit ne permet pas de revenir au 15 octobre. Sur nos packs, la sauvegarde externalisée quotidienne, en option, garde 30 jours de copies sur un site distant.

Votre WordPress est-il touché ? Le contrôle en dix minutes

1. La version du cœur. Elle s’affiche dans Tableau de bord, puis Mises à jour, et dans l’onglet Infos de la Santé du site (menu Outils). Comparez-la au tableau des versions sûres : en dessous de la dernière version de sa branche, le site est à corriger.
2. Les extensions et leurs versions. La page Extensions installées donne chaque numéro ; cherchez celles du tableau des extensions, actives ou non. Dans Plesk, l’onglet WordPress (WP Toolkit) liste toutes vos installations et marque celles qui ont une faille connue : il confronte chaque heure la version du cœur, les extensions et les thèmes actifs à la base de Patchstack (annonce de Plesk), et depuis 2024 à celle de Wordfence (notes de la version 6.3).
3. Les mises à jour automatiques. L’écran des mises à jour dit si le site installe seul les versions de maintenance et de sécurité. Si ce n’est pas le cas, quelqu’un les a coupées : la constante AUTOMATIC_UPDATER_DISABLED réglée à true, ou WP_AUTO_UPDATE_CORE réglée à false, dans wp-config.php, ou une extension (documentation de WordPress). Dans Plesk, regardez aussi le réglage des mises à jour automatiques de l’installation dans le WP Toolkit (documentation de Plesk). C’est la première chose à regarder sur un site resté en arrière malgré les mises à jour forcées.
4. Les licences. Elementor Pro, Bricksforge ou Rank Math PRO se mettent à jour par le compte de leur éditeur. Si la licence a expiré, ou si elle est au nom de l’agence qui a livré le site, la mise à jour peut ne jamais apparaître. Une copie « nulled », récupérée hors du site de l’éditeur, ne reçoit aucun correctif.
5. Le thème. Notez le thème actif et son parent : Twenty Twelve, Twenty Fourteen, Neve, Hestia et Sydney sont cités par l’avis de CVE-2026-87902. Comptez aussi les thèmes et extensions désactivés : leurs fichiers restent sur le serveur.

Avec un accès SSH, sur un VPS par exemple, WP-CLI donne l’essentiel en trois commandes : wp core version, wp plugin list et wp theme list.

Corriger dans le bon ordre

1. Faites une copie, à part. Sauvegardez fichiers et base depuis Plesk avant de toucher à quoi que ce soit, sans écraser les sauvegardes plus anciennes : si le site a été compromis, ce sont elles qui seront saines. Méthode : sauvegarder puis restaurer un site dans Plesk.
2. Le cœur, dans sa branche. Passez à la dernière version de votre branche (7.1.4, 7.0.8, 6.9.11, 6.8.12…). C’est le geste le moins risqué.
3. Les extensions exposées sans compte. D’abord celles dont l’exploitation est constatée : Elementor Pro si un formulaire accepte des fichiers, Bricksforge. Puis LearnPress, 10Web Booster, Kirki et LiteSpeed Cache ; Duplicator avant toute migration ; Blocksy Companion si la boutique utilise Dokan ; FunnelKit si elle s’en sert pour sa page de commande.
4. Le reste : autres extensions, thème et thème parent, une par une, en vérifiant entre deux les pages qui comptent (accueil, formulaires, panier, paiement).
5. Supprimez ce qui ne sert plus. Une extension désactivée garde ses fichiers et peut rester atteignable.
6. Cherchez des traces (partie suivante) : la mise à jour ferme la porte, elle ne fait pas sortir quelqu’un qui serait déjà entré.

Si une extension ne peut pas être mise à jour tout de suite (licence expirée, développement sur mesure, incompatibilité), désactivez-la et retirez-la, ou au minimum enlevez le champ d’envoi de fichier du formulaire concerné. Un pare-feu applicatif, comme celui d’Imunify360 sur nos packs, peut freiner les attaques connues ; il ne remplace pas le correctif.

Et le passage à WordPress 7.1 ?

Il ne presse pas pour la sécurité tant que votre branche reçoit ses correctifs, mais il se prépare : les reports peuvent s’arrêter, et la 7.2 arrive en décembre. Faites-le sur une copie de test : nos packs WordPress la créent en un clic dès la formule WP BUSINESS, et notre guide de mise à jour de WordPress détaille la méthode, retour arrière compris.

Vérifier que personne n’est déjà entré

Ces contrôles s’imposent si le site est resté plusieurs jours sur une version vulnérable : 6.9.0 à 7.0.1 après le 17 juillet ; une version antérieure à 7.1.2 (ou à la version corrigée de sa branche) avec un thème, ou un thème parent, qui a à sa racine un dossier page-…, comme ceux cités ; Elementor Pro 4.2.1 ou antérieure avec un formulaire d’envoi de fichier ; Bricksforge 3.1.8.9 ou antérieure après le 7 octobre ; ou 10Web Booster jusqu’à 2.34.10, qui permet lui aussi de déposer un fichier exécutable sans compte (fiche NVD). Comptez une demi-heure, sans prétendre à une analyse complète.

Les comptes administrateurs

Dans la liste des comptes, filtrez sur le rôle Administrateur et regardez chaque ligne : identifiant que personne ne reconnaît, adresse inconnue, inscription récente. Des attaques wp2shell ont créé des administrateurs, selon le SANS cité par BleepingComputer, et l’incident Rank Math ajoute des comptes wpsupport_…. En ligne de commande : wp user list --role=administrator, qui affiche aussi la date d’inscription. Notez avant de supprimer : ces lignes servent à l’enquête.

Des fichiers PHP là où il ne devrait pas y en avoir

Le dossier wp-content/uploads ne contient que des médias : un fichier .php, .phtml, .php5 ou .php8 y est suspect, surtout dans uploads/elementor/forms/ et uploads/bricksforge/tmp/. Regardez aussi wp-content/mu-plugins/ (extensions chargées d’office) et wp-content/cache/, où un chercheur du SANS a trouvé une porte dérobée posée via wp2shell. Méfiez-vous enfin de toute extension que vous n’avez pas installée : Wiz en a vu une déguisée en outil de sécurité. Dans Plesk, le gestionnaire de fichiers trie par date de modification ; en SSH, find wp-content/uploads -type f -iname '*.ph*' liste les extensions suspectes et grep -rl '<?php' wp-content/uploads trouve le code PHP caché dans une image ou un fichier .cache. Imunify360, présent sur nos packs, analyse ces fichiers : voyez comment traiter une alerte Imunify360.

Le cœur et les extensions ont-ils été modifiés ?

WordPress.org publie l’empreinte de chacun de ses fichiers. wp core verify-checksums compare le cœur installé à ces empreintes et wp plugin verify-checksums --all fait de même pour les extensions de WordPress.org (documentation de WP-CLI). Le WP Toolkit de Plesk propose la même vérification du cœur sans ligne de commande, par « Check WordPress Integrity » puis « Verify Checksums » ; il ne contrôle ni index.php ni wp-config.php, propres à chaque installation (documentation de Plesk). Les extensions payantes, absentes de WordPress.org, se comparent à une copie propre téléchargée chez leur éditeur.

Les tâches planifiées

Un intrus qui veut revenir programme une tâche. Côté WordPress, wp cron event list affiche les événements prévus : un nom inconnu, rattaché à une extension que vous n’avez pas, est suspect. Côté serveur, ouvrez les tâches planifiées de l’abonnement dans Plesk : une commande qui télécharge un script ou lance PHP sur un fichier caché n’a rien à y faire. L’incident Rank Math laissait le marqueur #ms6v46 dans la crontab.

Ce que montrent les journaux

Les journaux d’accès du domaine, consultables dans Plesk, gardent la trace des tentatives. Quelques signatures publiées :

• wp2shell : des requêtes vers /wp-json/batch/v1 ou ?rest_route=/batch/v1 ; une réponse 207 (ou 200) y est, pour Wiz, un indice fort de réussite ;
• CVE-2026-87902 : un paramètre pagename contenant %2e%2e ou %252e%252e, ou une requête contenant pearcmd (Patchstack) ;
• Elementor Pro : un POST vers admin-ajax.php (action elementor_pro_forms_send_form) dépose le fichier, puis l’attaquant l’appelle directement. Cherchez des requêtes vers /wp-content/uploads/elementor/forms/ qui finissent en .php, et le fichier lui-même dans ce dossier (Patchstack).

Au premier indice, téléchargez ces journaux depuis Plesk et gardez-en une copie : ils servent à dater l’intrusion ; demandez aussi au support de préserver ceux du serveur. Les bons réflexes de fond, eux, sont dans notre guide pour sécuriser WordPress contre le piratage.

Si vous trouvez quelque chose

Traitez le site comme compromis. Copiez fichiers et journaux avant de nettoyer, corrigez d’abord ce qui a permis l’entrée, changez tous les accès (WordPress, base de données, FTP, clés d’API des services de paiement et d’envoi de messages), et ne restaurez qu’une sauvegarde antérieure à l’intrusion. La déclaration au tunCERT et ce que la loi tunisienne attend d’un site piraté sont détaillés dans la partie « Site compromis » de notre article sur PHP2Shell.

Le serveur et le site : deux étages, deux responsables

PHP2Shell, corrigée le 21 octobre, est une faille de PHP, le programme du serveur qui exécute WordPress : en hébergement mutualisé, c’est l’hébergeur qui installe le correctif. Les failles de cet article sont dans le code du site. Même en mutualisé, appliquer leurs correctifs revient au propriétaire du site ou à son prestataire : un hébergeur ne choisit ni vos extensions ni le moment de les changer. Sur nos packs WordPress, vous pouvez confier ces mises à jour au WordPress Toolkit, comme vu plus haut ; une extension payante sans licence active, ou un thème modifié à la main, reste à votre charge.

Les deux étages, point par point

Les deux s’additionnent : un WordPress 7.1.4 sur un PHP non corrigé reste exposé, comme un 7.0.1 sur un PHP réparé. C’est la faille de PHP qui a conduit la STEG, puis l’ATCT le 23 octobre, à suspendre leur site à titre préventif ; la presse a aussi rapporté l’interruption de celui de l’Office de la topographie et du cadastre (Managers, 24 octobre).

Sur un serveur VPS ou un dédié, le serveur vous revient aussi : PHP, mais aussi des réglages comme register_argc_argv. Selon Patchstack, désactiver ce dernier ne corrige pas CVE-2026-87902, mais coupe la chaîne qui passe par pearcmd.php, celle qui mène à l’exécution de code. Vous pouvez confier l’administration du serveur à notre équipe, qui pose les correctifs du système et des services ; le code du site, WordPress compris, reste de votre côté. Le détail côté PHP, versions corrigées et vérification comprises, est dans notre article sur la faille PHP2Shell.

Quand passer la main à un professionnel

Faites-vous aider sans attendre si :

• l’un des contrôles ci-dessus a trouvé quelque chose : compte inconnu, fichier PHP dans uploads, tâche planifiée étrangère ;
• Rank Math PRO 3.0.123 a été activé pendant la fenêtre des 15 et 16 octobre ;
• le site enregistre des commandes, des paiements ou des données de clients : un nettoyage incomplet coûte plus cher qu’un diagnostic ;
• plus personne n’a l’accès administrateur ni les licences des extensions payantes, parce que l’agence ou le freelance qui a livré le site ne répond plus ;
• le thème a été modifié directement et ne peut pas être mis à jour sans perdre ces modifications ;
• le site appartient à une structure publique : la circulaire n° 5 du 2 septembre 2026 lui demande de traiter sans délai les failles recensées et d’informer l’ANCS de tout incident, avéré ou suspecté.

Préparez l’adresse du site, la liste des extensions avec leurs versions, la date de la dernière mise à jour connue et ce que vous avez constaté. Le tunCERT reçoit les déclarations d’incident à incident@ancs.tn et assiste gratuitement particuliers et professionnels. Chez NovaHoster, le support répond par livechat et par ticket, 7j/7 ; une restauration faite par notre équipe est sur devis, sauf si l’incident vient de chez nous.

Sources

Pages consultées le 29 octobre 2026.

• WordPress.org — annonces des versions 7.0.2, 7.0.3, 7.0.4, 7.1.1, 7.1.2, 7.1.3, 7.1.4 ; état des versions et statistiques des versions (relevés du 29 octobre 2026) ; mises à jour automatiques ; wp core verify-checksums
• Avis de sécurité de WordPress — GHSA-ff9f-jf42-662q, GHSA-fpp7-x2x2-2mjf (17 juillet 2026), GHSA-7hp8-65ch-5whp (22 septembre 2026)
• NVD — CVE-2026-63030, CVE-2026-60137, CVE-2026-64638, CVE-2026-65640, CVE-2026-87902, CVE-2026-32475, CVE-2026-85097, CVE-2026-104736, CVE-2026-108587, CVE-2026-82814, CVE-2026-107645, CVE-2026-100147, CVE-2026-107746, CVE-2026-113499, CVE-2026-113500, CVE-2026-111862 ; CISA, catalogue des vulnérabilités exploitées
• ANCS — bulletins du tunCERT Vuln.2026-421, Vuln.2026-467, Vuln.2026-487, Vuln.2026-568, Vuln.2026-580, Vuln.2026-607, Vuln.2026-683 (20 juillet au 29 octobre 2026) ; liste des bulletins ; page du tunCERT ; circulaire n° 5 du 2 septembre 2026 (publiée le 4 septembre 2026)
• Patchstack — CVE-2026-87902 (22 septembre 2026, mis à jour le 23), Elementor Pro (19 août 2026), Bricksforge (7 octobre 2026), 10Web Booster (14 octobre 2026), LearnPress, Kirki ; WPScan, LiteSpeed Cache (23 octobre 2026)
• Wiz (20 juillet 2026) ; Wordfence, « wp2shell aftermath » (juillet 2026, cité par BleepingComputer) ; BleepingComputer, wp2shell (21 juillet 2026) et Elementor Pro (3 septembre 2026) ; The Hacker News (12 octobre 2026) ; Cybersecurity News (13 octobre 2026)
• Éditeurs — avis de Rank Math sur la version PRO 3.0.123 ; journal des versions de Bricksforge ; journal de Duplicator ; pages WordPress.org de LearnPress, 10Web Booster, Duplicator, Kirki, Blocksy Companion, FunnelKit Funnel Builder, LiteSpeed Cache (consultées le 29 octobre 2026)
• Plesk — WP Toolkit 5.8, analyse des failles (13 décembre 2021) ; notes de WP Toolkit 6.3 (27 mars 2024) ; documentation du WP Toolkit (consultée le 29 octobre 2026)
• W3Techs, CMS des sites en .tn (relevé du 29 octobre 2026) ; Managers, « BCT, Steg, Atct… plusieurs sites institutionnels suspendus » (24 octobre 2026)