Vulnerabilites WordPress en 2025 : Pourquoi Votre Site Est Encore en Danger

Pourquoi WordPress Reste la Plus Grande Cible du Web

WordPress fait tourner environ 43% de tous les sites web sur internet. Ce chiffre a lui seul explique pourquoi les attaquants le ciblent aussi intensivement. Si vous trouvez un exploit qui fonctionne sur une installation WordPress par defaut, vous avez potentiellement acces a des centaines de milliers de sites. Pour un acteur malveillant, c'est un retour sur investissement extraordinaire.

Pourtant, de nombreuses entreprises en Suisse traitent encore WordPress comme une brochure statique configuree une fois et oubliee. La realite est bien plus complexe. WordPress est un logiciel vivant avec une chaine de dependances massive : un runtime PHP, une base de donnees MySQL ou MariaDB, un serveur web, le core WordPress lui-meme, un theme et entre cinq et cinquante plugins. Chacune de ces couches est un point d'entree potentiel.

Dans cet article, nous passons en revue les classes de vulnerabilites les plus critiques affectant les sites WordPress en 2025, nous referencerons des CVE reels, expliquerons pourquoi de nombreuses agences web ne maintiennent pas les sites securises, et vous donnerons une checklist concrete de durcissement.

Core et Versions PHP Obsoletes

Le Probleme des Mises a Jour du Core WordPress

WordPress dispose d'un mecanisme de mise a jour automatique decent pour les versions mineures (ex. 6.4.1 vers 6.4.2). Mais les mises a jour de version majeure (ex. 6.4 vers 6.5) necessitent une intervention manuelle, et beaucoup de proprietaires de sites les ignorent par crainte de casser quelque chose. Cette crainte n'est pas totalement infondee : les plugins et themes peuvent etre incompatibles avec les nouvelles versions du core. Mais l'alternative est bien pire.

Considerez CVE-2023-39999, une vulnerabilite dans le core WordPress qui permettait aux contributeurs de lire des articles prives ou en brouillon via l'API REST. Elle a ete corrigee dans WordPress 6.3.2, mais les sites sur des versions anterieures sont restes exposes pendant des mois. Ou prenez CVE-2024-31210, qui permettait aux utilisateurs admin d'executer du code arbitraire lors de l'upload de plugins sous certaines configurations serveur.

Fin de Vie PHP : Un Danger Silencieux

PHP 7.4 a atteint sa fin de vie en novembre 2022. PHP 8.0 en novembre 2023. Pourtant, une proportion significative de sites WordPress tourne encore sur ces versions non supportees.

Version PHP	Support Securite Jusqu'a	Statut (Jan 2025)
PHP 7.4	Novembre 2022	Fin de vie
PHP 8.0	Novembre 2023	Fin de vie
PHP 8.1	Decembre 2025	Correctifs securite uniquement
PHP 8.2	Decembre 2026	Support actif
PHP 8.3	Decembre 2027	Support actif

Si votre hebergeur utilise encore PHP 7.4 par defaut, c'est un signal d'alarme sur l'ensemble de sa posture de securite. Vous devriez utiliser PHP 8.2 ou 8.3 au minimum en 2025.

L'Ecosysteme des Plugins : La Plus Grande Force et Faiblesse de WordPress

Une Chaine de Dependances que Vous ne Controlez Pas

Le repertoire de plugins WordPress heberge plus de 60 000 plugins. Beaucoup d'entre eux sont maintenus par un seul developpeur qui peut abandonner le projet a tout moment. Quand cela arrive, vous vous retrouvez avec du code qui ne recevra jamais une autre correction de securite, en execution sur votre serveur de production.

Rien qu'en 2024, WPScan (desormais partie d'Automattic) a suivi plus de 5 000 nouvelles divulgations de vulnerabilites dans les plugins et themes WordPress. Parmi les plus severes :

• CVE-2024-27956 (WP Automatic Plugin) : injection SQL permettant a des attaquants non authentifies de creer des comptes admin. Score CVSS 9.8.
• CVE-2024-2876 (Email Subscribers by Icegram Express) : injection SQL non authentifiee permettant l'extraction complete de la base de donnees.
• CVE-2024-4345 (Starter Templates by Brainstorm Force) : XSS stocke permettant l'escalade de privileges. Plus d'1 million d'installations.

Le schema est toujours le meme : un plugin populaire avec des centaines de milliers d'installations contient une vulnerabilite critique trivialement exploitable. En quelques heures apres la divulgation, des scanners automatises sondent chaque site WordPress sur internet.

Attaques de la Chaine d'Approvisionnement

Une menace plus recente et insidieuse est la compromission de la chaine d'approvisionnement. En 2024, plusieurs plugins WordPress ont ete repris par de nouveaux proprietaires qui ont injecte du code malveillant dans les mises a jour. Pour en savoir plus sur la propagation des vulnerabilites des plugins, consultez notre analyse des vulnerabilites des plugins CMS.

Exposition de wp-admin et Attaques par Force Brute

Le Probleme de la Page de Connexion par Defaut

Chaque installation WordPress par defaut expose /wp-admin et /wp-login.php a l'ensemble d'internet. C'est l'equivalent de mettre un panneau "essayez d'entrer ici" sur votre porte d'entree. Des bots automatises scannent des plages d'IP et des listes de domaines 24h/24 et 7j/7.

Un site WordPress typique recoit entre 500 et 5 000 tentatives de force brute par jour. Nous approfondissons ce sujet dans notre article dedie sur les pages d'administration exposees.

Credential Stuffing vs. Force Brute

Le credential stuffing moderne est plus intelligent que la force brute traditionnelle : les attaquants utilisent des paires identifiant/mot de passe obtenues lors d'autres violations (LinkedIn, Adobe, Dropbox, etc.) et les essaient contre votre connexion WordPress. Comme les gens reutilisent leurs mots de passe entre les services, cela fonctionne avec une frequence inquietante.

XML-RPC : Le Vecteur d'Attaque Oublie

WordPress est livre avec XML-RPC active par defaut. La methode system.multicall permet a un attaquant de tester des centaines de combinaisons identifiant/mot de passe en une seule requete HTTP, contournant effectivement la limitation de debit sur le formulaire de connexion. Si vous n'utilisez pas XML-RPC, bloquez-le entierement au niveau du serveur web.

Injection SQL via les Plugins

Comment WordPress Gere les Requetes Base de Donnees

Le core WordPress utilise la methode $wpdb->prepare() pour les requetes parametrees. Le probleme est que les developpeurs de plugins contournent frequemment ce mecanisme. Une requete vulnerabile dans un plugin pourrait ressembler a :

$results = $wpdb->get_results(
  "SELECT * FROM {$wpdb->prefix}custom_table WHERE id = " . $_GET['id']
);

La version securisee utilise des parametres prepares :

$results = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}custom_table WHERE id = %d",
    intval($_GET['id'])
  )
);

Chaine d'Attaque par Injection SQL

1. Decouverte : L'attaquant utilise des outils automatises pour sonder chaque parametre GET et POST.
2. Confirmation : Un parametre retourne une erreur de base de donnees avec un simple apostrophe.
3. Extraction : L'attaquant utilise UNION SELECT pour extraire le hash du mot de passe admin.
4. Cassage : WordPress utilise le hachage phpass par defaut. Les mots de passe faibles tombent en minutes.
5. Acces : L'attaquant se connecte a wp-admin avec les identifiants craques.
6. Persistance : Un shell PHP backdoor est uploade via l'editeur de theme.
7. Exfiltration : Les donnees clients et informations sensibles sont extraites.

Vulnerabilites d'Upload de Fichiers

WordPress permet aux utilisateurs d'uploader des fichiers via la bibliotheque media et divers plugins. L'attaque classique consiste a uploader un fichier PHP deguise en image. Les mesures de mitigation incluent :

• Valider l'extension du fichier contre une liste blanche
• Verifier le type MIME cote serveur avec finfo_file()
• Renommer les fichiers uploades
• Stocker les uploads hors de la racine web
• Desactiver l'execution PHP dans le repertoire des uploads
• Utiliser un WAF qui inspecte le contenu des fichiers

Pourquoi les Agences ne Font Pas les Mises a Jour

Le modele commercial standard des agences web n'incite pas a la securite. Une agence typique construit un site WordPress, le livre au client et passe a autre chose. Le contrat de maintenance, s'il existe, couvre souvent la "surveillance de la disponibilite" plutot que le patching de securite.

Nous avons vu des entreprises suisses avec des installations WordPress 4.x et PHP 5.6, completement sans correctif depuis des annees. Pas parce qu'elles ne pouvaient pas se le permettre, mais parce que personne ne leur avait dit que c'etait important.

Checklist de Durcissement WordPress pour 2025

1. Mettez Tout a Jour Regulierement

• Activez les mises a jour automatiques mineures du core
• Configurez un environnement de staging pour tester les mises a jour majeures
• Mettez a jour tous les plugins et themes mensuellement au minimum
• Supprimez tout plugin ou theme que vous n'utilisez pas activement
• Utilisez PHP 8.2 ou 8.3

2. Verrouillez l'Authentification

• Imposez des mots de passe forts et uniques pour tous les comptes
• Activez l'authentification a deux facteurs (TOTP, pas SMS)
• Renommez ou deplacez l'URL de connexion
• Implementez la limitation de debit sur les endpoints de connexion
• Desactivez XML-RPC sauf besoin specifique

3. Minimisez la Surface d'Attaque

• Auditez chaque plugin installe
• Supprimez le plugin "Hello Dolly" par defaut et les themes inutilises
• Desactivez l'editeur de fichiers integre (define('DISALLOW_FILE_EDIT', true);)
• Desactivez le listing des repertoires

4. Securisez le Serveur

• HTTPS partout
• En-tetes de securite : X-Frame-Options, Content-Security-Policy, Strict-Transport-Security
• Permissions fichiers : repertoires 755, fichiers 644, wp-config.php 400
• Bloquez l'execution PHP dans wp-content/uploads/
• Utilisez un WAF (Cloudflare, Sucuri, ou ModSecurity)

5. Surveillez et Reagissez

• Surveillance de l'integrite des fichiers
• Monitoring des tentatives de connexion
• Sauvegardes (hors site, testees, automatisees)
• Abonnement aux flux de vulnerabilites
• Plan de reponse aux incidents

Quand WordPress n'Est Pas le Bon Choix

Pour beaucoup d'entreprises, la question n'est pas comment securiser WordPress mais si WordPress est le bon outil. Si votre site est principalement informatif, un generateur de sites statiques elimine des classes entieres de vulnerabilites. Pas de base de donnees signifie pas d'injection SQL. Pas de runtime cote serveur signifie pas d'execution de code a distance.

Nous explorons ce sujet en detail dans notre article sur la securite des sites statiques vs. dynamiques. Pour les entreprises en Suisse cherchant une presence web securisee, la decision architecturale est souvent plus impactante que n'importe quel plugin de securite.

Conclusion

La securite WordPress n'est pas une question a regler une fois pour toutes. Elle necessite une attention continue, des mises a jour regulieres et une comprehension claire de la surface d'attaque que vous exposez. Si vous gerez un site WordPress pour votre entreprise et n'avez pas examine sa securite recemment, contactez notre equipe. Nous pouvons realiser un audit de securite complet et vous aider a determiner la meilleure approche pour votre situation.