Sécurité Joomla : ce que les alertes de l’été 2026 nous rappellent

Une vulnérabilité critique de JCE a notamment fait l’objet d’attaques automatisées. Helix 3 a également reçu une mise à jour de sécurité, tandis qu’AcyMailing corrigeait début juillet une vulnérabilité permettant une injection SQL.

Dans le même temps, le projet Joomla publiait Joomla 5.4.7 et Joomla 6.1.2 avec plusieurs correctifs de sécurité concernant directement le CMS.

Tous ces événements n’avaient cependant ni la même gravité, ni le même niveau d’exploitation.

Et surtout, ils ne concernaient pas tous les sites Joomla.

Une faille Joomla n’est pas forcément une faille de Joomla

C’est une distinction importante.

Un site Joomla est constitué du CMS lui-même, auquel peuvent s’ajouter un template, des composants, des modules et des plugins développés par différents éditeurs.

Lorsqu’une vulnérabilité concerne une extension, seuls les sites utilisant cette extension dans une version vulnérable sont concernés.

C’est exactement ce qui s’est produit avec JCE en juin 2026.

Le 3 juin, l’éditeur de JCE a publié la version 2.9.99.5 afin de corriger une vulnérabilité critique présente dans les versions précédentes.

Quelques jours plus tard, il indiquait publiquement que cette faille était activement exploitée, que du code permettant de l’exploiter était disponible et que les attaques étaient automatisées.

Autrement dit, il s’agissait bien d’un problème sérieux.

Mais il s’agissait d’une vulnérabilité de JCE, pas d’une compromission générale de Joomla.

Tous les sites Joomla n’étaient donc pas exposés de la même manière

Sur les sites suivis en maintenance par l’agence Pince à Linge, nous n’utilisions pas JCE ni Helix 3 sur les installations concernées par notre parc.

Nous avons donc vu passer ces alertes, vérifié nos sites, mais nous n’avons pas eu à gérer la vague de compromissions liée à ces outils.

C’est un point assez révélateur de notre manière de concevoir les sites Joomla.

Nous essayons autant que possible de limiter les dépendances externes et de n’installer un composant que lorsqu’il répond à un véritable besoin.

Cela ne rend évidemment pas un site invulnérable.

Mais moins un site dépend d’extensions tierces, moins il possède de composants différents à surveiller et à maintenir dans le temps.

AcyMailing était concerné par une autre alerte

Nous utilisons en revanche AcyMailing sur plusieurs projets lorsque nos clients ont besoin d’un véritable outil de gestion de newsletters.

Le 9 juillet 2026, AcyMailing a publié la version 10.11.1.

Son changelog indique explicitement qu’une vulnérabilité permettant une injection SQL a été corrigée et recommande fortement la mise à jour.

Nous avons donc appliqué rapidement cette mise à jour sur les installations concernées.

C’est exactement ce que nous attendons d’une maintenance :

identifier si une alerte concerne réellement un site et intervenir lorsqu’elle le nécessite.

Il ne s’agit pas de mettre à jour mécaniquement tous les logiciels tous les matins.

Il s’agit de savoir quelles mises à jour peuvent attendre et lesquelles doivent être traitées rapidement.

Joomla lui-même a aussi reçu des correctifs

Le 7 juillet 2026, le projet Joomla a publié Joomla 5.4.7 et Joomla 6.1.2 comme versions de sécurité et de correction de bugs.

Plusieurs problèmes concernaient directement le cœur de Joomla : contrôles d’accès insuffisants dans certaines fonctions, vulnérabilités XSS ou problèmes concernant certaines API du CMS.

Mais il faut là encore replacer l’information dans son contexte.

Le Joomla Security Centre classe la majorité de ces vulnérabilités avec une probabilité d’exploitation faible.

Cela n’a donc rien à voir avec la situation rencontrée au même moment avec l’ancienne version de JCE, pour laquelle l’éditeur confirmait des attaques automatisées en cours.

Les deux nécessitent une mise à jour.

Mais le niveau d’urgence et le contexte ne sont pas identiques.

Une mise à jour de sécurité n’est pas un signe de faiblesse

Voir apparaître régulièrement des correctifs de sécurité peut donner l’impression qu’un logiciel est fragile.

C’est plutôt l’inverse.

Tous les logiciels modernes évoluent.

Des chercheurs, développeurs ou utilisateurs découvrent des vulnérabilités. Elles sont signalées, analysées puis corrigées.

Joomla dispose pour cela du Joomla Security Strike Team (JSST), chargé notamment de traiter les vulnérabilités remontées au projet et de publier les informations correspondantes une fois les correctifs disponibles.

La question n’est donc pas de savoir si un logiciel connaîtra un jour une vulnérabilité.

La vraie question est :

que se passe-t-il lorsqu’elle est découverte ?

Le projet est-il encore maintenu ?

Un correctif est-il publié ?

Et ce correctif est-il effectivement installé sur votre site ?

Pourquoi nous cherchons à limiter les extensions

L’actualité de cet été illustre particulièrement bien notre approche.

Joomla permet aujourd’hui de répondre nativement à beaucoup plus de besoins qu’il y a dix ans.

Les champs personnalisés, les catégories, les articles, les modules, les ACL et les overrides permettent de construire des sites très élaborés sans multiplier systématiquement les extensions.

Nous utilisons naturellement des composants externes lorsqu’ils apportent une fonction dont nous avons réellement besoin.

AcyMailing pour les newsletters ou HikaShop pour certains projets e-commerce en sont de bons exemples.

Mais nous évitons d’installer une extension uniquement pour réaliser quelque chose que Joomla sait déjà faire proprement.

Chaque extension supplémentaire devient une dépendance supplémentaire.

Elle devra :

• rester compatible avec Joomla ;

• suivre les évolutions de PHP ;

• être maintenue par son éditeur ;

• recevoir ses propres mises à jour de sécurité ;

• être vérifiée lors des futures migrations.

Une architecture sobre simplifie donc énormément la maintenance du site dans le temps.

Et elle limite aussi les points sur lesquels nous dépendons d’un éditeur tiers.

Les attaques sont souvent automatisées

Une autre idée importante ressort de l’incident JCE.

Une entreprise n’a pas besoin d’être célèbre ou particulièrement intéressante pour être attaquée.

Lorsqu’une vulnérabilité exploitable devient publique, des robots peuvent parcourir automatiquement Internet à la recherche des installations concernées.

L’éditeur de JCE a lui-même indiqué en juin que les attaques contre les anciennes versions vulnérables étaient automatisées.

Le pirate ne cherche donc pas forcément votre société.

Il cherche une version particulière d’un logiciel.

Lorsqu’il la trouve, l’exploitation peut être automatique.

C’est pour cette raison qu’un petit site associatif, un cabinet ou une PME doit être maintenu avec la même attention qu’un site beaucoup plus visible.

Une mise à jour ne nettoie pas un site déjà compromis

C’est aussi un point sur lequel l’éditeur de JCE a été très clair.

Installer la version corrigée ferme la porte utilisée par l’attaquant.

Mais si celui-ci est déjà entré sur le site, la mise à jour ne supprime pas nécessairement ce qu’il a installé auparavant.

Un site compromis doit donc être analysé.

Selon l’attaque, il peut être nécessaire de rechercher des fichiers ajoutés ou modifiés, des comptes inhabituels, des scripts malveillants ou d’autres mécanismes permettant à l’attaquant de revenir.

C’est pour cela qu’il vaut toujours mieux intervenir avant l’exploitation de la faille qu’après.

Les sauvegardes restent indispensables

La maintenance ne se limite pas aux mises à jour.

Nous mettons également en place des sauvegardes régulières sur les sites que nous suivons.

Une sauvegarde récente et restaurable constitue un filet de sécurité essentiel en cas de problème technique, d’erreur humaine ou d’incident de sécurité.

Elle ne remplace cependant jamais une mise à jour.

Restaurer une sauvegarde d’un site vulnérable sans corriger la faille qui a permis l’intrusion revient simplement à remettre en ligne un site qui pourra être compromis de nouveau.

La sauvegarde et la maintenance sont donc complémentaires.

Et les anciens Joomla ?

Les sites fonctionnant encore sur des générations anciennes méritent une attention particulière.

Un Joomla 3 peut parfois continuer à fonctionner correctement en apparence.

Mais en 2026, nous ne conseillons plus de conserver cette génération comme socle technique durable pour un site professionnel.

Lorsqu’un client nous confie encore un Joomla 3, notre priorité est d’étudier sa migration vers une version actuelle.

Cela ne signifie pas nécessairement tout jeter.

Nous pouvons conserver les contenus, les URL, le référencement, les données métier et même l’apparence du site lorsque cela est pertinent.

En revanche, continuer indéfiniment à utiliser un environnement ancien augmente progressivement les contraintes de compatibilité et de sécurité.

Une maintenance doit permettre de réagir, pas seulement de cocher une case

Les événements de cet été illustrent finalement assez bien notre conception de la maintenance Joomla.

Sur notre parc, les principales attaques observées autour de JCE et Helix 3 ne nous concernaient pas directement parce que nous n’utilisions pas ces outils sur les sites suivis.

AcyMailing était présent sur certains projets.

Lorsque son correctif de sécurité est sorti, nous l’avons appliqué rapidement.

C’est exactement ce que nous voulons apporter à nos clients :

• connaître l’environnement technique du site ;

• limiter les dépendances inutiles ;

• disposer de sauvegardes ;

• suivre les évolutions importantes ;

• déterminer si une vulnérabilité concerne réellement le site ;

• intervenir rapidement lorsqu’elle le nécessite.

Le risque zéro n’existe pas.

Mais un site simple, régulièrement suivi et construit avec des outils maintenus est beaucoup plus facile à protéger qu’une installation composée d’une accumulation d’extensions que personne n’ose plus mettre à jour.

Vous ne savez plus vraiment ce qui est installé sur votre Joomla ?

C’est une situation beaucoup plus fréquente qu’on ne l’imagine.

Un site peut fonctionner depuis plusieurs années alors que personne ne sait précisément quelles extensions sont encore utilisées, lesquelles sont maintenues ou quand les dernières mises à jour ont été effectuées.

L’agence Pince à Linge peut reprendre un site Joomla existant, auditer son environnement technique et déterminer les actions réellement nécessaires.

Nous privilégions une approche simple :

conserver ce qui est utile, supprimer les dépendances devenues inutiles et maintenir correctement ce qui reste.