Une porte dérobée WordPress utilise huit points de restauration pour se reconstruire après un nettoyage

Une porte dérobée WordPress récemment documentée peut se reconstituer après la suppression de ses fichiers visibles par les défenseurs. Pour cela, elle s’appuie sur des copies redondantes réparties dans le système de fichiers, la base de données et, sur les serveurs compatibles, la mémoire partagée.

Le malware a été baptisé SC, en référence aux marqueurs SC_ repérés dans les contenus injectés. Sucuri le décrit comme un réseau « autoréparateur » piloté par la blockchain. Le chercheur Gabriel Barbosa indique que sa charge utile est présente dans au moins huit emplacements et que les composants encore actifs peuvent rétablir les parties supprimées de l’infection.

Le rapport consacré à SC a été publié en même temps que des informations sur l’exploitation d’une vulnérabilité distincte du plugin wpForo Forum. Les éléments disponibles n’établissent aucun lien entre cette faille et la diffusion ou le fonctionnement de SC. Ces deux problèmes de sécurité doivent être traités séparément.

Huit composants forment un système de persistance circulaire

La résilience de SC repose sur plusieurs mécanismes de restauration, et non sur un unique fichier dissimulé. Supprimer le plugin apparent peut ne servir à rien si un chargeur, une copie dans la base de données, une archive de restauration ou un segment de mémoire partagée reste accessible.

Sucuri a identifié huit composants principaux :

1. .user.ini définit la directive PHP auto_prepend_file, qui déclenche l’exécution d’un chargeur avant les requêtes PHP dans l’arborescence concernée.

2. wp-content/c1b12371.php charge un fichier caché dont le nom commence par un point lorsqu’il se trouve au même emplacement.

3. wp-content/.c1b12371.php sert de chargeur de première étape. Il recherche le faux plugin et peut le recréer dans mu-plugins à partir de trois sources : une copie classique du plugin, un stub encodé dans le répertoire cache ou une archive ZIP de restauration portant un nom hexadécimal aléatoire.

4. wp-content/db.php exploite le mécanisme des fichiers d’extension de base de données chargés automatiquement par WordPress. Il contient la charge utile de la porte dérobée sous forme compressée et encodée en Base64, puis redéploie le plugin si le fichier attendu est absent ou si sa taille est inférieure à un seuil défini.

5. wp-content/advanced-cache.php s’exécute avant les plugins ordinaires lorsque la mise en cache est activée. Il peut reconstituer le malware à partir de cinq emplacements : le plugin indispensable, une copie classique du plugin, du code PHP stocké dans la mémoire partagée System V, une archive ZIP ou la base de données. Il accroche ensuite l’événement plugins_loaded et inclut le plugin restauré.

6. wp-content/themes/khorshidi/functions.php assure la persistance au niveau du thème. Selon Sucuri, il contient la même porte dérobée et réécrit le plugin dès que celui-ci est absent.

7. wp-content/mu-plugins/hyper-engine-kit.php correspond au malware installé comme plugin indispensable, une catégorie que WordPress charge automatiquement.

8. wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php fournit une autre copie de la même charge utile dans le répertoire standard des plugins.

La porte dérobée masque ses noms de fonctions et recourt à un décodeur fondé sur un chiffrement par substitution pour rendre son code plus difficile à comprendre. Elle se dissimule également dans l’écran des plugins de l’administration WordPress et lors des vérifications de mises à jour.

Avec une telle architecture, supprimer les composants un par un n’est pas une méthode fiable. Un fichier qui semble secondaire peut servir à tout reconstituer lors de la prochaine exécution.

La mémoire partagée prolonge la persistance au-delà des fichiers et des données SQL

Sur les serveurs compatibles avec la mémoire partagée System V, SC écrit du code PHP dans un segment accessible à l’aide d’une clé numérique fixe. Le rapport ne précise pas la valeur de cette clé.

Comme ce segment réside en mémoire vive, il peut rester disponible après le nettoyage des fichiers du site et des enregistrements de la base de données. Le fichier malveillant advanced-cache.php peut récupérer le code PHP stocké dans ce segment et s’en servir pour recréer le plugin.

Les environnements d’hébergement mutualisé peuvent compliquer l’inspection et la suppression du malware. Selon Sucuri, le segment mémoire peut appartenir à un autre compte et se trouver ainsi hors de portée des droits d’administration habituels du propriétaire du site compromis.

L’infection enregistre également des hooks cron WordPress, dont certains portent des noms aléatoires, ainsi qu’un hook de récupération connu. Les éléments fournis ne précisent pas le nom de ces hooks. Une tâche cron système exécute le fichier cron de WordPress, ce qui permet un redéploiement planifié sans dépendre du trafic des visiteurs.

Les fichiers, le contenu de la base de données, les archives de restauration, les tâches planifiées et la mémoire partagée constituent donc les rouages d’un même mécanisme de récupération. Un nettoyage limité au répertoire des plugins WordPress laisse plusieurs sources potentielles de reconstitution intactes.

Le contrôle par Ethereum permet de poursuivre la compromission

Sucuri décrit SC comme une porte dérobée pilotée par la blockchain, qui communique avec une infrastructure de commande et de contrôle par l’intermédiaire de la blockchain Ethereum. Les informations disponibles ne fournissent ni identifiants de portefeuille Ethereum, ni adresses de commande et de contrôle, ni indicateurs comparables sur l’infrastructure.

Une fois actif, le malware peut dresser l’empreinte du site infecté, récupérer des charges utiles supplémentaires et créer un compte administrateur WordPress caché. Les capacités attribuées à ses opérateurs comprennent :

• La récupération de code JavaScript arbitraire à injecter dans les pages du site.
• La diffusion de skimmers ou d’autres malwares par le biais de scripts injectés.
• L’exécution de code PHP sur le serveur compromis.
• La désactivation ou la suppression de certains plugins.
• La relance du processus de réinfection lorsque des composants sont supprimés.

Ces capacités mettent en danger le site comme ses visiteurs. L’exécution de code PHP côté serveur donne à l’opérateur un contrôle étendu sur l’installation WordPress, tandis que l’injection de code JavaScript arbitraire permet d’ajouter du code malveillant aux pages présentées aux utilisateurs.

Le rapport cité ne désigne pas l’acteur à l’origine de SC. Il précise également que le mode de diffusion initial reste inconnu. Les composants WordPress vulnérables, les identifiants faibles, les chaînes d’approvisionnement de plugins compromises et les fonctions d’envoi de fichiers non sécurisées ne sont mentionnés qu’à titre de possibilités courantes, et non comme des points d’entrée confirmés pour ce malware.

L’injection SQL exploitée dans wpForo constitue un problème distinct

La faille du plugin divulguée au même moment est CVE-2026-1581, une injection SQL temporelle exploitable sans authentification, qui affecte wpForo Forum dans les versions 0 à 2.4.14 incluses.

La vulnérabilité est exposée par le paramètre wpfob. L’échappement insuffisant des données contrôlées par l’utilisateur, associé à une préparation inadéquate d’une requête SQL existante, permet à un attaquant non authentifié d’ajouter des requêtes SQL et d’extraire des informations sensibles de la base de données.

La fiche du programme CVE publiée par Wordfence désigne tomdever comme éditeur et attribue la découverte de la faille à Youssef Elouaer. La fiche a été publiée le 19 février 2026 et mise à jour le 8 avril 2026.

CVE-2026-1581 est classée HIGH, avec un score CVSS 3.1 de 7.5 et le vecteur suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Ce vecteur décrit une vulnérabilité exploitable à distance, de faible complexité, qui ne nécessite ni privilèges ni interaction de l’utilisateur. L’impact évalué est élevé pour la confidentialité, sans impact indiqué sur l’intégrité ou la disponibilité. La faille est classée CWE-89 : neutralisation incorrecte d’éléments utilisés dans une commande SQL.

La télémétrie de Previdian a recensé moins de 20 tentatives d’exploitation depuis le 3 juillet 2026. L’activité provenait de cinq adresses IP d’attaquants distinctes, géolocalisées en Bulgarie, en Suisse, en France, aux États-Unis et au Yémen. Les adresses exactes n’ont pas été communiquées.

Le rapport ne permet pas d’identifier les auteurs de ces tentatives. Il n’établit pas non plus de lien entre CVE-2026-1581 et la porte dérobée SC.

La réponse à incident doit couvrir toutes les sources de restauration

En cas de suspicion de compromission par SC, la suppression de hyper-engine-kit.php ou d’un seul des chargeurs ne suffit pas à prouver que l’infection a été éradiquée. Les équipes d’intervention doivent examiner les huit chemins de composants signalés ainsi que les autres sources de récupération auxquelles ils font référence.

Cet examen doit couvrir :

• Les répertoires des plugins ordinaires et des plugins indispensables.
• Les fichiers d’extension db.php et advanced-cache.php.
• Le fichier functions.php du thème concerné.
• .user.ini et sa directive auto_prepend_file.
• Le contenu du cache et les archives ZIP de restauration aux noms aléatoires.
• Les données malveillantes stockées dans la base de données WordPress.
• L’activité des tâches cron de WordPress et du système.
• Les segments de mémoire partagée System V sur les serveurs qui les prennent en charge.

Les informations disponibles ne fournissent ni procédure de suppression de SC validée, ni valeur numérique de la clé de mémoire partagée, ni liste complète des noms de hooks cron, ni indicateurs précis de commande et de contrôle. Les administrateurs ne devraient donc pas déclarer un site sain au seul motif que le plugin visible n’y apparaît plus.

Pour CVE-2026-1581, les opérateurs doivent déterminer si une installation WordPress utilise wpForo Forum 2.4.14 ou une version antérieure. Les fiches de vulnérabilité fournies ne précisent ni version corrigée ni solution de contournement : elles ne permettent donc pas de désigner une version particulière comme remède. Les administrateurs devraient consulter les recommandations actuelles de l’éditeur et examiner l’activité web et les journaux de la base de données afin de repérer d’éventuelles requêtes suspectes impliquant wpfob.

Ces deux incidents nécessitent des investigations différentes. SC impose de rechercher les mécanismes de persistance sur plusieurs couches de stockage et d’exécution, tandis que CVE-2026-1581 exige d’évaluer l’exposition du plugin et de rechercher d’éventuelles extractions de données. Les confondre risquerait d’orienter les défenseurs vers le mauvais point d’entrée ou la mauvaise stratégie de nettoyage.