Attaques WordPress chez IONOS : notre retour d’expérience et la réponse SmallGuard 3.x

L’été 2026 aura été particulièrement agité pour la sécurité WordPress.

Chez Phenix Info, nous administrons plusieurs dizaines de sites WordPress hébergés notamment chez IONOS. Fin juillet, nous avons dû faire face à une vague d’attaques et de compromissions suffisamment importante pour remettre à plat une partie de notre stratégie de protection.

Fichiers PHP déposés dans des emplacements inhabituels, webshells, comptes administrateurs inconnus, modifications de fichiers sensibles, tentatives d’exfiltration de données ou encore mécanismes permettant de réinjecter du code malveillant : les attaques observées allaient bien au-delà d’un simple bot essayant quelques mots de passe sur /wp-login.php.

Cette expérience a directement participé à l’évolution de notre firewall WordPress SmallGuard, désormais en version 3.x.

L'objectif n'est pas de promettre un WordPress « impossible à pirater » — une telle promesse serait irréaliste — mais de multiplier les barrières, de détecter plus rapidement une compromission et surtout de bloquer une partie des attaques avant même que WordPress ait terminé de démarrer.

Juillet 2026 : WordPress devient la cible de wp2shell

Le contexte de cette vague d’attaques est important.

Le 17 juillet 2026, WordPress publie des correctifs concernant deux vulnérabilités particulièrement sensibles. Leur combinaison, connue sous le nom de wp2shell, permettait dans certaines versions de WordPress d’aboutir à une exécution de code à distance sans authentification.

IONOS a publié une alerte spécifique destinée à ses clients WordPress et indique que la recherche des installations vulnérables a rapidement été automatisée par des acteurs malveillants.

Le CERT-FR a également publié une alerte concernant les vulnérabilités CVE-2026-60137 et CVE-2026-63030, en anticipant des tentatives d’exploitation à grande échelle.

C'est un point essentiel à comprendre : un petit site WordPress n'est pas protégé par son manque de notoriété.

La majorité de ces attaques sont automatisées. Les robots parcourent Internet à la recherche d'une version, d'une extension, d'un thème ou d'un comportement vulnérable. Ils ne se demandent pas si le site réalise 500 visites ou 500 000 visites par mois.

Les attaques étaient-elles réellement dues à IONOS ?

Non, et la distinction est importante.

Nous avons observé ces compromissions sur des sites hébergés chez IONOS, mais cela ne signifie pas que l'infrastructure IONOS elle-même avait été compromise.

IONOS a au contraire communiqué sur la vulnérabilité wp2shell et effectué des contrôles de sécurité sur les installations concernées. L'hébergeur recommande également, lorsqu'une compromission est détectée, une restauration depuis une sauvegarde saine ainsi qu'une rotation des différents mots de passe et secrets utilisés par WordPress.

Sur notre parc, les éléments rencontrés correspondaient à plusieurs techniques classiques de post-exploitation WordPress. Il serait donc incorrect d'attribuer systématiquement chaque fichier malveillant observé à une seule vulnérabilité.

Cette distinction est importante en cybersécurité : constater une compromission ne suffit pas toujours à déterminer avec certitude le point d'entrée initial.

Ce que nous avons réellement trouvé sur les WordPress compromis

Les analyses réalisées pendant cette période nous ont permis d'identifier différents comportements caractéristiques d'une compromission WordPress.

Des fichiers PHP déposés à des endroits inhabituels

Un WordPress contient naturellement beaucoup de fichiers PHP.

La difficulté consiste donc à distinguer un fichier légitime d'un fichier qui n'a rien à faire là.

Nous avons notamment rencontré des fichiers PHP nouvellement créés :

• à la racine de WordPress ;
• dans wp-content/uploads ;
• dans certains répertoires d'extensions ;
• dans des thèmes ;
• dans des répertoires normalement destinés à du contenu statique.

Le répertoire uploads est particulièrement intéressant pour un attaquant : WordPress doit pouvoir y écrire afin de gérer les médias.

En revanche, une image n'a généralement aucune raison d'avoir besoin d'exécuter du PHP.

C'est l'une des raisons pour lesquelles SmallGuard applique aujourd'hui une surveillance et un durcissement spécifiques aux fichiers exécutables présents dans ces emplacements.

Des webshells pour conserver l'accès au serveur

Après avoir exploité une vulnérabilité, l'objectif d'un attaquant est souvent de conserver son accès.

Un petit fichier PHP peut alors servir de porte dérobée et permettre de reprendre la main sur le site ultérieurement.

Supprimer uniquement le fichier visible ayant provoqué le piratage n'est donc pas suffisant.

Un site peut sembler parfaitement fonctionner alors qu'un second mécanisme d'accès est encore présent ailleurs.

C'est précisément ce qui rend certains nettoyages WordPress compliqués : la page malveillante n'est parfois que la partie visible de la compromission.

Des comptes administrateurs WordPress inconnus

Autre comportement particulièrement critique : l'apparition de nouveaux utilisateurs disposant du rôle administrateur.

IONOS cite d'ailleurs la présence de comptes administrateurs inconnus parmi les indicateurs devant être recherchés après une attaque wp2shell.

Une fois administrateur, un attaquant peut potentiellement installer une extension, modifier certaines configurations ou tenter de réintroduire du code malveillant.

SmallGuard surveille donc également les créations et élévations de comptes administrateurs.

Des mécanismes de persistance plus discrets

Certaines infections rencontrées étaient beaucoup moins visibles.

Nous avons notamment porté une attention particulière aux fichiers tels que :

wp-config.php

.htaccess

.user.ini

aux drop-ins présents dans wp-content, aux MU-plugins ainsi qu'aux fichiers PHP nouvellement apparus à la racine.

L'utilisation d'un mécanisme comme auto_prepend_file peut par exemple provoquer l'exécution automatique d'un fichier PHP avant le script normalement demandé.

Ce type de modification explique pourquoi une vérification de sécurité WordPress ne doit pas se limiter à lancer un scanner sur le dossier des extensions.

Pourquoi simplement installer un antivirus WordPress ne suffit pas

Un scanner malware est utile.

Mais il intervient généralement après l'apparition du fichier.

Notre réflexion après les incidents de juillet a donc été la suivante :

Peut-on empêcher davantage d'attaques d'atteindre WordPress plutôt que simplement rechercher leurs conséquences après coup ?

C'est cette logique qui a progressivement conduit SmallGuard vers son architecture actuelle.

La documentation officielle WordPress recommande elle-même une approche de défense en profondeur comprenant notamment les mises à jour, des permissions adaptées, la surveillance des fichiers et l'utilisation éventuelle d'un firewall applicatif.

SmallGuard 3.x : protéger WordPress plus tôt

La principale évolution architecturale de SmallGuard 3.x est son système de Preload WAF.

Dans une installation WordPress classique, un plugin de sécurité fonctionne principalement une fois que WordPress a commencé son chargement.

Or certaines attaques peuvent justement chercher à viser des fichiers, chemins ou comportements situés en amont.

SmallGuard 3.x peut utiliser le mécanisme PHP auto_prepend_file afin de charger une couche de protection avant le chargement normal de WordPress.

Le principe devient alors :

Requête HTTP → Preload SmallGuard → filtrage WAF → WordPress → extensions → thème

Une requête considérée comme clairement malveillante peut ainsi être rejetée sans avoir besoin de charger complètement WordPress.

Cela améliore à la fois la sécurité et, lors d'attaques automatisées importantes, l'utilisation des ressources serveur.

SQL injection, XSS, LFI, RCE, SSTI...

Le moteur WAF de SmallGuard analyse plusieurs familles d'attaques Web connues.

Il recherche notamment des comportements associés à :

• SQL Injection ;
• Cross-Site Scripting (XSS) ;
• Local File Inclusion et traversées de répertoires ;
• Remote Code Execution ;
• injections de commandes ;
• SSTI ;
• scans de fichiers sensibles ;
• requêtes automatisées caractéristiques de bots malveillants ;
• tentatives d'accès à certains fichiers ou chemins dangereux.

Les règles sont volontairement combinées à différents mécanismes de normalisation.

Pourquoi ?

Parce qu'un attaquant n'envoie pas forcément :

../

Il peut essayer différentes représentations ou plusieurs niveaux d'encodage destinés à produire la même chaîne après décodage.

SmallGuard normalise donc les requêtes avant leur passage dans certaines règles afin de limiter ces techniques de contournement.

Une normalisation des chemins renforcée

La branche 3.x a également renforcé la normalisation des chemins.

Des requêtes conceptuellement équivalentes comme :

/./xmlrpc.php

ou certains chemins contenant des segments ../ ou encodés doivent être ramenées vers une représentation cohérente avant analyse.

Cette étape paraît anodine, mais elle est importante : une règle WAF n'est réellement efficace que si l'attaquant ne peut pas simplement modifier la représentation de la chaîne recherchée pour la contourner.

Une protection spécifique des uploads

Les attaques WordPress observées nous ont également conduits à renforcer fortement cette partie.

SmallGuard contrôle les extensions dangereuses et différentes formes de doubles extensions pouvant tenter de faire passer un fichier exécutable pour une image ou un document.

Les fichiers PHP et apparentés dans les zones d'upload font l'objet d'une attention particulière.

La version 3.x comporte également un durcissement de la gestion des SVG, format parfaitement légitime mais qui nécessite des contrôles adaptés en raison de sa nature XML et des possibilités qu'il offre.

L'objectif n'est évidemment pas de bloquer les fichiers légitimes, mais de contrôler beaucoup plus sévèrement ce qui peut devenir exécutable.

Détection malware et contrôle d'intégrité

Bloquer une attaque est une chose.

Détecter une compromission qui aurait déjà réussi en est une autre.

SmallGuard dispose donc également d'un contrôle d'intégrité capable de rechercher différentes anomalies :

• modifications du cœur de WordPress ;
• anomalies dans les extensions ;
• fichiers sensibles modifiés ;
• nouveaux fichiers exécutables ;
• PHP présent dans les uploads ;
• nouveaux comptes administrateurs ;
• modifications de certains drop-ins ;
• fichiers suspects nouvellement apparus.

Un scanner malware complète ces contrôles grâce à différentes signatures de détection.

L'objectif n'est volontairement pas de supprimer automatiquement n'importe quel fichier détecté.

Dans un environnement WordPress complexe, une suppression automatique agressive peut être aussi dangereuse qu'un faux positif.

SmallGuard privilégie donc la détection, l'alerte et l'analyse.

Surveillance automatique quotidienne

La sécurité ne doit pas dépendre uniquement d'une vérification manuelle effectuée lorsqu'un client indique que « quelque chose semble bizarre ».

SmallGuard effectue donc périodiquement différents contrôles.

Le système peut notamment vérifier l'intégrité du site, rechercher de nouveaux fichiers suspects et contrôler certains changements importants.

Cette surveillance permet de réduire le temps entre l'apparition d'une anomalie et sa découverte.

Et en sécurité informatique, ce délai est particulièrement important.

Un WAF doit aussi savoir laisser passer les requêtes légitimes

Bloquer toutes les requêtes suspectes serait relativement facile.

Construire un WAF utilisable sur un vrai WordPress est beaucoup plus compliqué.

WooCommerce, les constructeurs de pages, les APIs REST, les systèmes de paiement, les outils SEO ou certaines extensions peuvent légitimement envoyer des requêtes complexes ressemblant parfois à une attaque.

Nous avons donc également beaucoup travaillé sur les faux positifs.

SmallGuard dispose d'un système de bypass ciblé permettant d'autoriser précisément une requête légitime identifiée dans les journaux, plutôt que de désactiver entièrement une famille de protections.

C'est un principe auquel nous tenons particulièrement :

une exception doit rester aussi limitée que possible.

Des listes IP externes sans sacrifier les performances

SmallGuard peut également utiliser différentes listes externes d'adresses ou de réseaux identifiés comme problématiques.

Mais charger de très grosses listes PHP à chaque requête aurait rapidement un coût important en mémoire et en CPU.

La branche 3.x utilise donc des index binaires .idx associés aux données téléchargées.

La recherche peut être réalisée directement dans ces index sans devoir charger l'intégralité des listes en mémoire.

Sur nos benchmarks internes, cette architecture permet de conserver un coût de recherche très faible, y compris avec plusieurs centaines de milliers de plages IP.

C'est important car un firewall WordPress ne doit pas devenir lui-même la cause du ralentissement du site qu'il protège.

Et les tests de contournement ?

Nous ne testons pas SmallGuard uniquement avec quelques chaînes SQL copiées dans un navigateur.

Le moteur a été soumis à différents jeux de tests concernant notamment :

• encodages simples, doubles et multiples ;
• variations de casse ;
• séparateurs inhabituels ;
• transformations de chemins ;
• SQL injection ;
• XSS ;
• LFI ;
• RCE ;
• SSTI ;
• uploads malveillants.

Un fuzzing interne de 50 000 mutations de charges utiles n'a pas révélé de contournement réel sur le corpus testé après les derniers durcissements.

Cela ne signifie absolument pas que SmallGuard est infaillible.

En cybersécurité, zéro vulnérabilité n'existe pas.

Ces tests permettent simplement de vérifier que les protections existantes résistent à davantage de variations que les exemples les plus évidents.

SmallGuard remplace-t-il les mises à jour WordPress ?

Non.

Et c'est probablement l'un des points les plus importants de cet article.

Un firewall ne doit jamais servir d'excuse pour conserver une version vulnérable de WordPress ou une extension abandonnée.

La priorité reste :

1. maintenir WordPress à jour ;
2. maintenir les extensions et thèmes à jour ;
3. supprimer les extensions inutilisées ;
4. utiliser des mots de passe uniques et solides ;
5. limiter les comptes administrateurs ;
6. disposer de sauvegardes réellement restaurables ;
7. surveiller l'intégrité des fichiers ;
8. ajouter une couche WAF pour réduire la surface d'attaque.

WordPress recommande officiellement de maintenir le cœur, les thèmes et les extensions à jour et rappelle également l'intérêt d'une stratégie de firewall et de surveillance.

Vous avez mis WordPress à jour ? Cela ne suffit pas forcément après une compromission

C'est une erreur fréquente.

Lorsqu'une vulnérabilité est corrigée, installer la nouvelle version empêche normalement l'exploitation de cette vulnérabilité.

Mais si un pirate avait déjà installé une porte dérobée avant la mise à jour, celle-ci peut toujours être présente.

IONOS insiste d'ailleurs sur ce point concernant wp2shell : disposer maintenant d'une version corrigée ne permet pas de savoir si le site avait été compromis avant sa mise à jour.

Après une compromission, il faut donc également rechercher les mécanismes de persistance, vérifier les comptes, renouveler les secrets exposés et contrôler les fichiers.

Que faire si votre site WordPress a été piraté ?

La priorité est de ne pas simplement supprimer la page malveillante visible.

Il faut déterminer l'étendue de la compromission.

Chez Phenix Info, notre démarche consiste notamment à contrôler :

• la version de WordPress ;
• les extensions et thèmes ;
• les fichiers récemment créés ou modifiés ;
• les répertoires uploads ;
• les comptes administrateurs ;
• wp-config.php ;
• .htaccess et .user.ini ;
• les MU-plugins et drop-ins ;
• la base de données ;
• les tâches planifiées ;
• les mécanismes susceptibles de charger automatiquement un fichier ;
• les logs disponibles.

Lorsque des identifiants, mots de passe de base de données, clés API ou autres secrets peuvent avoir été accessibles à l'attaquant, ils doivent également être renouvelés.

IONOS recommande précisément plusieurs de ces opérations après une compromission wp2shell, notamment le changement du mot de passe de la base de données, des mots de passe liés aux applications et le renouvellement des clés de sécurité WordPress.

Ce que cette vague d'attaques a changé pour SmallGuard

Cette période nous a rappelé une règle simple :

un plugin de sécurité ne doit pas uniquement reconnaître une attaque. Il doit aussi être capable d'en limiter les conséquences lorsqu'une première barrière échoue.

C'est la philosophie actuelle de SmallGuard 3.x :

Filtrer → Bloquer → Surveiller → Détecter → Alerter

Le Preload WAF bloque le plus tôt possible.

Le moteur de règles analyse les requêtes.

La protection des uploads cherche à limiter le dépôt de fichiers dangereux.

Les contrôles d'intégrité recherchent les modifications inattendues.

Le scanner malware recherche certains comportements et signatures suspects.

Les journaux permettent enfin de comprendre ce qui s'est réellement passé et d'affiner les protections sans désactiver globalement le firewall.

La sécurité WordPress est une défense en profondeur

Les attaques de l'été 2026 nous ont permis de confronter notre outil à des incidents réels, et pas uniquement à des scénarios théoriques.

SmallGuard 3.x est directement issu de ce retour d'expérience.

Il ne remplace ni les mises à jour, ni une bonne configuration serveur, ni des sauvegardes, ni le travail d'un administrateur.

Il ajoute une couche supplémentaire.

Et face à des attaques désormais largement automatisées, cette accumulation de couches de sécurité est précisément ce qui permet de réduire les risques.

Votre site WordPress présente un comportement suspect ?

Fichiers inconnus, nouvel administrateur, redirection étrange, pages indésirables, fichiers PHP dans les uploads ou modifications inexpliquées sont autant de signaux qui doivent être vérifiés rapidement.

Phenix Info peut réaliser un audit de sécurité WordPress, rechercher les traces d'une compromission et mettre en place SmallGuard afin de renforcer la protection du site après nettoyage.

FAQ – Sécurité WordPress et attaques IONOS

Pourquoi des sites WordPress hébergés chez IONOS ont-ils été piratés en 2026 ?

Une importante vulnérabilité WordPress connue sous le nom de wp2shell a notamment été corrigée en juillet 2026 et a fait l'objet d'une alerte spécifique d'IONOS et du CERT-FR. D'autres vulnérabilités d'extensions, de thèmes ou des identifiants compromis peuvent également permettre l'infection d'un WordPress. Une analyse est nécessaire pour déterminer le point d'entrée réel.

Mettre WordPress à jour supprime-t-il un malware ?

Non. Une mise à jour corrige une vulnérabilité mais ne supprime pas nécessairement une porte dérobée installée avant l'application du correctif.

Quel est l'intérêt d'un firewall WAF pour WordPress ?

Un WAF analyse les requêtes arrivant sur le site afin d'identifier et bloquer certains comportements malveillants, notamment des tentatives de SQL injection, XSS, inclusion de fichiers ou exécution de commandes.

SmallGuard peut-il garantir qu'un WordPress ne sera jamais piraté ?

Non. Aucun outil sérieux ne peut garantir une sécurité absolue. SmallGuard cherche à réduire la surface d'attaque et à combiner filtrage WAF, surveillance, contrôle d'intégrité et détection de malware dans une stratégie de défense en profondeur.