Sécurité du site web d’une mairie : WordPress ou site statique ?

Le 21 octobre 2026, le CERT-FR a lancé une alerte sur deux failles critiques de PHP, le langage sur lequel repose WordPress. Depuis juillet, il avait déjà publié six avis sur le seul cœur de WordPress. Pour une petite commune, une question simple se pose : faut-il un serveur qui calcule chaque page à chaque visite pour publier les horaires de la mairie et le compte rendu du conseil municipal ?

Ce billet traite de la sécurité du site de mairie sous WordPress, ou sous un autre CMS dynamique, et d’une alternative : le site statique relié à un CMS « headless ». Il s’adresse aux élus, secrétaires de mairie et DGS comme aux développeurs ; chaque terme technique est expliqué et chaque chiffre sourcé. Un site statique réduit certains risques, pas tous, et la dernière partie le dit sans détour.

Octobre 2026 : deux séries d’alertes qui concernent les sites de mairie

Le CERT-FR est l’entité gouvernementale et nationale chargée de la prévention, de la détection et de la réponse aux attaques informatiques ; il fait partie de l’ANSSI, l’Agence nationale de la sécurité des systèmes d’information. Il publie des avis de sécurité, qui font état de vulnérabilités et des moyens de s’en prémunir, et des alertes, destinées à prévenir d’un danger immédiat¹.

PHP : une alerte pour tous les serveurs web qui l’utilisent

PHP est un langage de programmation exécuté par le serveur : à chaque visite, il fabrique la page avant de l’envoyer au navigateur. WordPress fonctionne avec PHP².

Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques, enregistrées sous les numéros CVE-2026-109618 et CVE-2026-109619. Un numéro CVE est l’identifiant public attribué à chaque faille de sécurité recensée. Selon l’avis de sécurité de PHP, ces failles peuvent permettre une exécution de code à distance sans authentification : un inconnu, sans aucun compte, peut faire exécuter ses propres instructions par le serveur. Sont exposées, toujours selon PHP, toutes les installations qui servent des pages web. Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12³.

Le CERT-FR a publié le même jour l’alerte CERTFR-2026-ALE-014 et l’avis CERTFR-2026-AVI-1359. Mise à jour le 22 octobre, l’alerte fait état de preuves de concept, c’est-à-dire de démonstrations d’attaque, pour certains déploiements de PHP. Elle rappelle que les versions 5.x, 7.x, 8.0.x et 8.1.x ne sont plus maintenues, et recommande d’isoler les équipements affectés puis de migrer vers une version maintenue et corrigée⁴⁵.

De son côté, WordPress.org précise que ces failles ne sont pas propres à WordPress : elles touchent tout serveur qui héberge une application PHP, et c’est PHP qu’il faut mettre à jour, pas WordPress². Pour une mairie, la question devient aussi : « qui met à jour PHP chez notre hébergeur, et dans quel délai ? »

WordPress : six avis du CERT-FR en moins de trois mois

Entre le 20 juillet et le 7 octobre 2026, le CERT-FR a publié six avis sur le cœur de WordPress, c’est-à-dire sur le logiciel lui-même, hors extensions et thèmes :

Avis du CERT-FR	Date	Version corrigée	Risques signalés (extrait)
CERTFR-2026-AVI-09046	20 juillet 2026	7.0.2	exécution de code arbitraire à distance, injection SQL
CERTFR-2026-AVI-09797	7 août 2026	7.0.3	exécution de code arbitraire à distance, élévation de privilèges
CERTFR-2026-AVI-10188	13 août 2026	7.0.4	exécution de code arbitraire à distance
CERTFR-2026-AVI-12009	18 septembre 2026	7.1.1	injection de code indirecte (XSS), atteinte à la confidentialité des données
CERTFR-2026-AVI-121610	23 septembre 2026	7.1.2	exécution de code arbitraire à distance
CERTFR-2026-AVI-127311	7 octobre 2026	7.1.3	injection SQL, déni de service à distance

Vocabulaire : une injection SQL fait exécuter par la base de données une commande non prévue, pour lire ou modifier son contenu ; une injection de code indirecte (XSS) glisse un script malveillant dans une page consultée par d’autres ; une élévation de privilèges donne plus de droits que prévu ; un déni de service rend le site indisponible.

Pour le premier de ces avis, le CERT-FR rapporte, d’après l’éditeur, que l’exploitation combinée de deux failles permet à un attaquant non authentifié d’exécuter du code à distance, et qu’il a connaissance d’une preuve de concept publique⁶. Ces deux failles, CVE-2026-60137 et CVE-2026-63030, ont été inscrites le 21 juillet 2026 au catalogue des vulnérabilités exploitées de la CISA, l’agence américaine de cybersécurité ; ce catalogue ne recense que les failles dont l’exploitation réelle est constatée. Une troisième faille du cœur, CVE-2026-87902, corrigée en version 7.1.2, y a été ajoutée le 25 septembre 2026¹²¹³¹⁴.

Tenir un site WordPress à jour n’est donc pas une tâche annuelle. La fiche pratique de Cybermalveillance.gouv.fr, réalisée avec l’ANSSI et le ministère de l’Intérieur, est claire : « La grande majorité des attaques de sites Internet est rendue possible par l’exploitation de failles de sécurité ». Elle recommande d’appliquer les mises à jour du système de gestion de contenu, des modules et des extensions « dès qu’elles sont disponibles »¹⁵.

Sécurité du site de mairie sous WordPress : ce qui est exposé

La surface d’attaque, selon l’OWASP

L’OWASP est une communauté internationale qui publie des références libres sur la sécurité des applications web. Sa fiche consacrée à l’analyse de la surface d’attaque la définit comme l’ensemble des points par lesquels un attaquant pourrait entrer dans un système et en faire sortir des données. Plus précisément, elle comprend la somme de tous les chemins par lesquels des données ou des commandes entrent dans l’application et en sortent, le code qui protège ces chemins, les données de valeur utilisées par l’application et le code qui protège ces données¹⁶.

Pour un élu, l’image est parlante : plus un bâtiment communal a de portes, plus il faut de serrures et de rondes. L’OWASP recommande d’ailleurs de réduire cette surface quand c’est possible, en simplifiant le système et en désactivant les fonctions et interfaces inutilisées¹⁶.

Les portes d’entrée d’un site WordPress classique

WordPress est un CMS, ou « système de gestion de contenu » : un logiciel pour publier sans écrire de code. Il est dit dynamique car, à chaque visite, le serveur exécute PHP, interroge une base de données et assemble la page. Sur une installation classique, le même serveur public héberge aussi l’interface d’administration, le thème (l’habillage graphique) et les extensions, ces modules ajoutés pour une fonction supplémentaire : formulaire, agenda…

Chacun de ces éléments est une porte au sens de l’OWASP : la page de connexion à l’administration, accessible depuis Internet ; l’API, l’interface de programmation par laquelle des logiciels échangent des données avec le site (l’une des failles inscrites au catalogue de la CISA en juillet passait justement par elle¹²) ; les extensions et le thème ; la base de données ; PHP et le serveur web.

Sur les extensions, les données détaillées viennent d’un éditeur privé spécialisé dans la sécurité de WordPress, Patchstack. Son rapport annuel avance 11 334 nouvelles failles recensées dans l’écosystème WordPress en 2025, soit 42 % de plus qu’en 2024. Selon lui, 91 % de ces failles concernent les extensions et 9 % les thèmes ; il n’en compte que 6 dans le cœur, de faible priorité. Il estime enfin, par un calcul pondéré, que les failles les plus attaquées sont exploitées dans un délai médian de 5 heures¹⁷. Ce sont les chiffres d’un acteur commercial, selon sa propre méthode, non ceux d’un organisme public.

L’ANSSI rappelle pour sa part que les sites web sont « par nature des éléments très exposés du système d’information ». Au-delà des défigurations et des dénis de service, un site peut servir de porte d’entrée vers le système d’information de son propriétaire, et externaliser l’hébergement ne transfère pas l’ensemble des risques¹⁸.

Le site statique relié à un CMS headless : comment ça marche

Des pages fabriquées à l’avance

Un site statique est fait de pages HTML (le langage qui décrit une page web), fabriquées une fois pour toutes à la publication, puis déposées chez un hébergeur qui se contente de les envoyer telles quelles au visiteur.

Astro est l’un des outils qui fabriquent ce type de site. Sa documentation indique que, par défaut, les pages sont pré-générées au moment de la construction du site, sous forme de pages statiques¹⁹. La construction est l’étape où l’outil assemble contenus et gabarits en fichiers HTML.

Un CMS headless pour écrire, à l’écart du site public

Le mot anglais « headless » signifie « sans tête ». Un CMS headless sert à saisir et à organiser les contenus, mais ne produit pas lui-même le site qui les affiche. La documentation d’Astro le formule ainsi : le CMS aide à écrire le contenu, mais ne génère pas de site pour l’afficher ; c’est Astro qui récupère les contenus et fabrique les pages²⁰.

Pour la secrétaire de mairie, le quotidien change peu : elle rédige l’actualité dans une interface d’édition, puis publie. En coulisses, la publication déclenche une nouvelle construction du site, et les nouvelles pages remplacent les anciennes.

Ce qui disparaît du site public

Sur le site que consultent les habitants, il n’y a plus ni PHP, ni base de données, ni page de connexion, ni extension exécutée à chaque visite. Le visiteur ne déclenche aucun programme applicatif côté serveur : il reçoit des fichiers déjà prêts.

Les failles qui les visent, comme celles de PHP corrigées le 21 octobre ou l’injection SQL de WordPress corrigée en juillet, n’ont donc plus de prise sur le site public. C’est ce que l’OWASP appelle réduire la surface d’attaque : moins de points d’entrée, moins de code à défendre¹⁶. Il reste un serveur qui envoie des fichiers, que l’hébergeur doit maintenir, mais il n’exécute plus le code d’un CMS.

Remettre le risque à sa juste place : les comptes d’abord

Encore faut-il regarder ce que disent les chiffres publics. Cybermalveillance.gouv.fr, le dispositif national d’assistance aux victimes de cybermalveillance, publie chaque année un rapport d’activité. Dans celui de 2025, page 38, la défiguration de site Internet, c’est-à-dire l’altération de l’apparence d’un site par un pirate²¹, ne représente que 2,2 % des parcours d’assistance des collectivités territoriales et des administrations, un volume en baisse de 20 % sur un an²².

Le piratage de compte arrive en tête, avec 20,1 % des parcours d’assistance. Il est suivi de l’hameçonnage, ces faux messages qui imitent un expéditeur de confiance pour voler des identifiants (19,2 %), et du rançongiciel, un logiciel qui chiffre les fichiers pour exiger une rançon (13,1 %)²².

Disons-le noir sur blanc : un site statique ne règle pas ce risque. Un compte de messagerie piraté, ou celui d’un agent sur le CMS headless, reste une porte d’entrée. La double authentification, qui exige en plus du mot de passe une seconde preuve d’identité comme un code reçu sur un téléphone, et l’hygiène informatique de base restent indispensables. La fiche pratique de Cybermalveillance.gouv.fr recommande des mots de passe longs, complexes et différents pour chaque service, et d’activer la double authentification si possible, notamment pour les comptes d’administration du site¹⁵.

Côté ANSSI, le Panorama de la cybermenace 2025 indique que « ministères et collectivités territoriales » représentent 24 % des 1 366 incidents portés à sa connaissance en 2025. L’agence précise que ces chiffres reflètent sa propre vision, sans être nécessairement représentatifs. Elle souligne aussi que les vulnérabilités des solutions exposées sur Internet « peuvent être exploitées très rapidement »²³. En revanche, le Panorama ne donne aucun chiffre propre aux sites web des petites communes : je n’en citerai donc pas.

Les limites du site statique, sans détour

Un site statique déplace et réduit la surface d’attaque ; il ne la supprime pas. Voici les cinq limites à connaître avant de choisir.

Le CMS headless reste exposé

Le CMS headless est un logiciel comme un autre : son interface d’administration est en ligne et son API transmet les contenus à l’outil de construction. Deux portes d’entrée. Il faut le tenir à jour, ou suivre de près son éditeur s’il s’agit d’un service hébergé. S’il est lui-même écrit en PHP, l’alerte d’octobre le concerne aussi. La CNIL recommande de limiter l’accès à ses interfaces d’administration aux seules personnes habilitées²⁴.

Le rendu à la demande réintroduit un serveur

Astro permet de faire générer certaines pages par un serveur au moment où le visiteur les demande. Sa documentation appelle cela le rendu à la demande, aussi connu sous le nom de rendu côté serveur, et il nécessite un adaptateur, c’est-à-dire un module qui fait tourner le projet sur un environnement serveur¹⁹. Une fois cette option activée, un programme s’exécute de nouveau à chaque visite, avec ses mises à jour et sa surveillance. Pour un site vitrine, mieux vaut s’en passer ou la réserver à un besoin précis.

La chaîne d’outils, un risque d’approvisionnement

Un site statique dépend de paquets installés avec npm, le gestionnaire de bibliothèques de code de l’écosystème JavaScript, que la documentation d’Astro utilise pour installer ses modules¹⁹. Il dépend aussi d’un service qui construit le site à chaque publication, puis d’un hébergeur. Chaque maillon peut être compromis. Le Top 10:2025 de l’OWASP, son classement des risques les plus critiques pour les applications web, place en troisième position, A03, les défaillances de la chaîne d’approvisionnement logicielle (« Software Supply Chain Failures »). Il les décrit comme des ruptures ou des compromissions dans la construction, la distribution ou la mise à jour d’un logiciel, souvent causées par du code tiers. Il recommande de suivre toutes les dépendances, y compris indirectes, de supprimer celles qui ne servent pas, et met en garde contre une chaîne de construction et de déploiement moins sécurisée que les systèmes qu’elle produit²⁵.

Formulaires et démarches en ligne : des services à part

Un site purement statique ne sait pas traiter un formulaire. Contact, signalement, inscription : chaque formulaire passe par un service séparé, qu’il faut choisir, sécuriser et rendre conforme au RGPD (lieu d’hébergement, durée de conservation des données). Les démarches en ligne plus lourdes, comme les inscriptions scolaires ou les paiements, relèvent d’applications distinctes, avec leur propre surface d’attaque. La CNIL compte par exemple parmi les précautions élémentaires de « rendre l’utilisation de TLS obligatoire pour toutes les pages d’authentification ou sur lesquelles sont affichées ou transmises des données personnelles »²⁴.

Accessibilité : la technologie ne fait pas la conformité

Les communes sont soumises à l’obligation d’accessibilité numérique prévue par l’article 47 de la loi du 11 février 2005²⁶, que détaille le billet RGAA : qu’est-ce que c’est et pourquoi c’est important. Or les critères du RGAA portent sur ce que reçoit l’usager : alternatives textuelles des images, étiquettes des champs de formulaire, titres des pages, contrastes…²⁷ Aucun ne dépend de l’outil qui a produit la page. Un site statique n’est donc pas plus accessible par nature : des gabarits mal conçus restent inaccessibles, quelle que soit la technologie. Seul un audit permet de le vérifier.

Que retenir pour une commune ?

Quelques questions simples aident à faire le point avec son prestataire ou son hébergeur :

• Quelle version de PHP fait tourner notre site, et qui la met à jour, dans quel délai, après une alerte du CERT-FR ?
• Combien d’extensions sont installées, et lesquelles servent encore ?
• La double authentification est-elle activée sur tous les comptes d’administration et de messagerie ?
• Notre site a-t-il vraiment besoin d’un serveur qui calcule chaque page à chaque visite ?

Pour un site vitrine d’actualités, d’horaires et de comptes rendus, le site statique relié à un CMS headless est une option sérieuse : il retire du site public les composants visés par les alertes d’octobre. À condition de traiter les cinq limites ci-dessus, et sans oublier que le piratage de compte est, en 2025, le premier motif de demande d’assistance des collectivités auprès de Cybermalveillance.gouv.fr.

Le prochain billet de ce blog portera sur la non-conformité des sites publics.

Mes autres travaux sur l’accessibilité, la sécurité et la sobriété des sites publics sont présentés sur nicolascollier.dev.

---

Notes

Note de bas de page

1. 1.

   CERT-FR, page « À propos » (statut et missions) et pages « Alertes de sécurité » et « Avis de sécurité » (définitions des deux types de documents). https://www.cert.cyber.gouv.fr/a-propos/ – https://www.cert.cyber.gouv.fr/alerte/ – https://www.cert.cyber.gouv.fr/avis/

   ↩
2. 2.

   WordPress.org, « Critical PHP Security Release », 21 octobre 2026 (failles « not specific to WordPress », aucune mise à jour de WordPress nécessaire, mettre à jour PHP). https://wordpress.org/news/2026/10/critical-php-security-release/

   ↩
3. 3.

   PHP, « Security advisory: Critical remote code execution vulnerabilities, update now », 21 octobre 2026 (CVE-2026-109618, CVE-2026-109619 ; « all PHP installations serving web requests » ; versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12). Avis PHP : https://www.php.net/archive/2026.php#2026-10-21-5 – fiches NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-109618 et https://nvd.nist.gov/vuln/detail/CVE-2026-109619

   ↩
4. 4.

   CERT-FR, alerte CERTFR-2026-ALE-014, « [Màj] Multiples vulnérabilités dans PHP », première version du 21 octobre 2026, dernière version du 22 octobre 2026 (systèmes affectés, preuves de concept, recommandation d’isolement puis de migration). https://www.cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/

   ↩
5. 5.

   CERT-FR, avis CERTFR-2026-AVI-1359, « Multiples vulnérabilités dans PHP », 21 octobre 2026. https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1359/

   ↩
6. 6.

   CERT-FR, avis CERTFR-2026-AVI-0904, « Multiples vulnérabilités dans WordPress », 20 juillet 2026 (WordPress 7.0.2 ; exploitation combinée par un attaquant non authentifié ; preuve de concept publique). https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-0904/

   ↩
7. 7.

   CERT-FR, avis CERTFR-2026-AVI-0979, « Multiples vulnérabilités dans WordPress », 7 août 2026, mis à jour le 10 août 2026 (WordPress 7.0.3). https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-0979/

   ↩
8. 8.

   CERT-FR, avis CERTFR-2026-AVI-1018, « Vulnérabilité dans WordPress », 13 août 2026 (WordPress 7.0.4, CVE-2026-65640). https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1018/

   ↩
9. 9.

   CERT-FR, avis CERTFR-2026-AVI-1200, « Multiples vulnérabilités dans WordPress », 18 septembre 2026 (WordPress 7.1.1). https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1200/

   ↩
10. 10.

    CERT-FR, avis CERTFR-2026-AVI-1216, « Vulnérabilité dans WordPress », 23 septembre 2026 (WordPress 7.1.2, CVE-2026-87902). https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1216/

    ↩
11. 11.

    CERT-FR, avis CERTFR-2026-AVI-1273, « Multiples vulnérabilités dans WordPress », 7 octobre 2026 (WordPress 7.1.3). https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1273/

    ↩
12. 12.

    NVD (NIST), fiches CVE-2026-63030 (confusion de route sur le point d’accès de traitement par lots de l’API REST, combinée à CVE-2026-60137 : injection SQL puis exécution de code à distance) et CVE-2026-60137 (injection SQL) ; ajout au catalogue de la CISA le 21 juillet 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-63030 et https://nvd.nist.gov/vuln/detail/CVE-2026-60137

    ↩
13. 13.

    NVD (NIST), fiche CVE-2026-87902 (inclusion de fichier menant, sous conditions, à une exécution de code à distance) ; ajout au catalogue de la CISA le 25 septembre 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-87902

    ↩
14. 14.

    CISA, Known Exploited Vulnerabilities Catalog, version 2026.10.23 (entrées WordPress Core du 21 juillet et du 25 septembre 2026). https://www.cisa.gov/known-exploited-vulnerabilities-catalog

    ↩
15. 15.

    Cybermalveillance.gouv.fr, avec l’ANSSI et le ministère de l’Intérieur, fiche pratique « La sécurisation des sites Internet » (mises à jour, mots de passe, double authentification). https://www.cybermalveillance.gouv.fr/medias/2024/06/210722_FichePratique_SitesInternet-3.pdf

    ↩
16. 16.

    OWASP, Attack Surface Analysis Cheat Sheet (sections « Defining the Attack Surface of an Application » et « Managing the Attack Surface »). https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html

    ↩
17. 17.

    Patchstack (éditeur privé, source secondaire), State of WordPress Security in 2026, données de l’année 2025. https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/

    ↩
18. 18.

    ANSSI, MesServicesCyber, « Sécuriser un site web ». https://messervices.cyber.gouv.fr/guides/securiser-un-site-web

    ↩
19. 19.

    Documentation d’Astro, On-demand rendering (pré-génération par défaut, rendu à la demande, adaptateurs serveur, installation par paquet npm). https://docs.astro.build/en/guides/on-demand-rendering/

    ↩
20. 20.

    Documentation d’Astro, guide « CMS » (section « Which CMSes work well with Astro? »). https://docs.astro.build/en/guides/cms/

    ↩
21. 21.

    Cybermalveillance.gouv.fr, fiche réflexe « Défiguration de site Internet ». https://www.cybermalveillance.gouv.fr/tous-nos-contenus/fiches-reflexes/defiguration-de-site-internet

    ↩
22. 22.

    Cybermalveillance.gouv.fr, Rapport d’activité 2025, mars 2026, p. 38, « L’assistance aux collectivités territoriales et aux administrations en 2025 ». https://www.cybermalveillance.gouv.fr/medias/2026/03/RA_2025_Cybermalveillance_gouv_fr.pdf

    ↩
23. 23.

    ANSSI, CERT-FR, Panorama de la cybermenace 2025 (CERTFR-2026-CTI-002), 11 mars 2026, résumé et p. 7 du rapport (« Répartition sectorielle des incidents traités en 2025 »). https://www.cert.cyber.gouv.fr/cti/CERTFR-2026-CTI-002/

    ↩
24. 24.

    CNIL, « Sécuriser les sites web », Guide de la sécurité des données personnelles (« Les précautions élémentaires » : rendre TLS obligatoire pour les pages d’authentification ou affichant ou transmettant des données personnelles ; limiter l’accès aux interfaces d’administration). https://www.cnil.fr/fr/securite-securiser-les-sites-web

    ↩
25. 25.

    OWASP, Top 10:2025, page d’accueil (présentation du classement) et « A03:2025 - Software Supply Chain Failures ». https://owasp.org/Top10/2025/ et https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

    ↩
26. 26.

    DINUM, RGAA, « Champ d’application » (personnes morales de droit public). https://accessibilite.numerique.gouv.fr/obligations/champ-application/

    ↩
27. 27.

    DINUM, RGAA 4.1.2, « Critères et tests » (notamment critères 1.1, 3.2, 8.5 et 11.1). https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/

    ↩