Si vous avez reçu un courriel de ma part vous renvoyant vers cette page, c’est que votre site web semble utiliser une version d’iCagenda (le com_icagenda de JoomliC, une extension de calendrier d’événements pour le système de gestion de contenu Joomla) affectée par un problème de sécurité connu. Cette page explique en quoi consiste le problème, comment vérifier s’il s’applique à vous, et comment le corriger.

Cet avis concerne CVE-2026-48939, une faille critique et activement exploitée qui permet un téléversement de fichier arbitraire non authentifié menant à l’exécution de code à distance via le formulaire front-end « Soumettre un événement » de l’extension. Elle a été ajoutée au catalogue des Known Exploited Vulnerabilities (vulnérabilités connues et exploitées) de la Cybersecurity and Infrastructure Security Agency des États-Unis le 10 juillet 2026.

Deux conditions, et les deux doivent être réunies

Votre site est concerné par le problème d’exécution de code à distance lorsque ces deux conditions sont réunies :

  1. iCagenda se situe sur la ligne 4.0.x, à une version inférieure à 4.0.8 (c’est-à-dire de 4.0.0 à 4.0.7), et
  2. le noyau Joomla est inférieur à 6.1.2.

Si iCagenda est en version 4.0.8 ou ultérieure, vous n’êtes pas concerné. Et si votre noyau Joomla est en version 6.1.2 ou ultérieure, vous n’êtes pas concerné non plus, même avec un iCagenda ancien, car le noyau lui-même bloque le téléversement. Si cela décrit votre site, vous pouvez arrêter votre lecture ici, si ce n’est pour noter que mettre à jour iCagenda reste malgré tout une bonne chose à faire.

La seconde condition est le point sur lequel cette page diverge de l’avis de l’éditeur lui-même, qui affirme que le problème ne touche que les sites utilisant Joomla 6. Il touche aussi les sites Joomla 4 et Joomla 5 pleinement à jour, et j’expose les éléments qui l’établissent plus bas, car vous verrez l’éditeur affirmer le contraire si vous suivez le lien.

Si vous utilisez une version concernée, mettez à jour iCagenda, et comme cette faille a été exploitée avant qu’un correctif n’existe, vérifiez également votre site à la recherche de signes indiquant que quelqu’un vous a précédé (voir Si vous utilisiez une version concernée ci-dessous).

Une remarque pour quiconque utilise l’ancienne ligne 3.9.x. La plage de la CVE publiée inclut la 3.9.x, et l’éditeur a également corrigé cette ligne, dans la version 3.9.15. D’après ma propre lecture et mes propres tests, la ligne 3.9.x emprunte pour le téléversement un chemin de code différent et protégé, de sorte que le résultat d’exécution de code à distance n’y est pas atteignable : sur Joomla 4 et 5, le téléversement est bloqué par le noyau, et sur Joomla 6, ce chemin de code n’existe même plus, si bien que la fonctionnalité échoue simplement. Ce n’est pas une raison d’ignorer la mise à jour. Ces mêmes versions corrigent une vérification d’autorisation manquante qui permet à un visiteur anonyme de pousser un événement non approuvé sur votre site (et, sur Joomla 4 et 5, un fichier d’un type autorisé avec lui). Sévérité moindre, mais qui mérite tout de même d’être corrigée : mettez à jour vers la version 3.9.15 ou ultérieure. Notez également que l’éditeur ne fournit des correctifs de sécurité pour la ligne 3.9.x que jusqu’au 13 octobre 2026.

Ce message est-il légitime ?

Oui. Il s’agit d’un avis de divulgation responsable et de bonne foi émis par un chercheur en sécurité indépendant. Je ne vous demande pas d’argent, de mots de passe ou d’accès à votre site, et je n’ai pas tenté de pénétrer dans votre site, de téléverser quoi que ce soit, ni d’exploiter quoi que ce soit.

Ce que j’ai lu, ce sont deux fichiers publics que votre site sert à quiconque les demande : le manifeste du composant iCagenda à /administrator/components/com_icagenda/icagenda.xml, et le manifeste du noyau Joomla à /administrator/manifests/files/joomla.xml. Ce sont tous deux de simples fichiers XML de version, et ce sont les deux mêmes fichiers décrits sous Comment vérifier vos versions ci-dessous, afin que vous puissiez voir exactement ce que j’ai vu. C’est tout. Je n’ai spécifiquement pas soumis votre formulaire d’événement, je n’ai rien téléversé, et je n’ai pas demandé le répertoire des pièces jointes de votre site. Ce chemin n’apparaît plus bas sur cette page que comme un endroit où vous pouvez regarder sur votre propre site. Rien dans cette vérification ne touche à vos données, à votre zone d’administration, ou à toute partie privée de votre site.

Si vous souhaitez vérifier qui je suis, consultez les coordonnées au bas de cette page et la page À propos.

Pourquoi cela compte

iCagenda publie un calendrier d’événements sur les sites Joomla. L’une de ses fonctionnalités permet à un visiteur de soumettre un événement via un formulaire front-end, en joignant éventuellement un fichier, qui atterrit sous images/icagenda/frontend/attachments/.

Dans les versions concernées, cette soumission est acceptée sans connexion, et la pièce jointe est écrite sur le disque sans aucun contrôle du type de fichier dont il s’agit, en conservant le nom et l’extension choisis par le soumissionnaire. Cette combinaison permet à un attaquant de déposer sur votre serveur un programme de son choix et de l’exécuter : une exécution de code à distance complète, sans compte et sans aucune coopération de votre part.

Rien n’a besoin d’être activé pour que cela s’applique. Le formulaire n’a pas besoin d’être publié ni visible par les visiteurs : dans les versions concernées, le contrôleur qui le sous-tend acceptait la soumission dans tous les cas.

Ce risque n’est pas théorique. Il est noté 9,8 sur 10 par le NVD (et 10,0 par l’autorité d’attribution selon le système de notation le plus récent), et il est activement exploité dans la nature. L’éditeur signale le début de l’exploitation le 15 juin 2026 à 08h00 UTC, avant que le correctif n’existe, et décrit les attaques comme automatisées. La CISA l’a ajoutée à son catalogue des Known Exploited Vulnerabilities le 10 juillet 2026.

Je décris cela au niveau qu’un propriétaire de site doit connaître pour agir, et pas plus. Je ne publie pas les détails qui permettraient à quelqu’un de le reproduire, et je vous demande de ne pas essayer de le reproduire contre votre propre site ou celui de quiconque. Lire vos deux numéros de version, comme décrit ci-dessous, vous dit tout ce dont vous avez besoin pour décider quoi faire.

Si mon courriel a cité ce problème, cela signifie que les versions signalées par votre site le situent dans la plage concernée sur les deux points. Je n’ai pas testé si votre site en particulier est exploitable ou déjà compromis.

En quoi cette page diffère de l’avis de l’éditeur

L’avis de l’éditeur mérite d’être lu et je le mets en lien plus bas. Ils ont publié un correctif rapidement et leurs recommandations sont bonnes. Mais une phrase de portée qui s’y trouve ne tient pas, et comme c’est justement la phrase qui inciterait la plupart des lecteurs de cette page à se rassurer, je préfère montrer mon raisonnement plutôt que de simplement l’affirmer. L’avis indique :

Les téléversements de fichiers non sécurisés étaient déjà bloqués par défaut sur toutes les versions de Joomla antérieures à Joomla 6. Seule l’installation d’iCagenda sur Joomla 6 (6.0.0-6.1.1) présentait la vulnérabilité critique de téléversement.

Voici ce que j’ai mesuré, sur des installations isolées qui m’appartiennent en propre. Aucun site tiers n’a été impliqué à aucun moment.

  • iCagenda 4.0.x effectue le téléversement via la classe framework Joomla\Filesystem\File, qui provient du paquet joomla/filesystem fourni avec le noyau Joomla. Elle n’utilise pas l’ancienne classe du CMS Joomla portant le même nom, celle qui a toujours comporté une vérification de fichier sûr et qui est probablement celle à laquelle l’avis fait référence.
  • Cette méthode du framework n’a acquis sa propre vérification de fichier sûr (le paramètre $allowUnsafe et le test isSafeFile) qu’à partir de joomla/filesystem 4.2.0, la version fournie avec Joomla 6.1.2.
  • Les versions effectivement fournies avec les publications Joomla que j’ai vérifiées : Joomla 4.4.14 fournit filesystem 2.0.2 (aucune vérification), Joomla 5.4.7 fournit 3.2.0 (aucune vérification), et Joomla 6.1.2 fournit 4.2.0 (vérification présente).

Un site Joomla 4 ou Joomla 5 entièrement corrigé exécutant iCagenda 4.0.0 à 4.0.7 est donc exposé, et c’est pourquoi cette page formule la condition Joomla comme « inférieur à 6.1.2 » plutôt que « Joomla 6 uniquement ». Rien dans la fiche CVE publiée, l’entrée NVD, ou le catalogue de la CISA ne limite ce problème à une version de Joomla en particulier ; la phrase de l’avis est le seul endroit où une telle limite apparaît.

Comment vérifier vos versions

Vous n’êtes pas obligé de me croire sur parole pour l’un ou l’autre de ces deux numéros, et il y en a deux à vérifier.

Votre version d’iCagenda, à partir du fichier manifeste (aucune connexion requise) : ouvrez

votredomaine.com/administrator/components/com_icagenda/icagenda.xml

et lisez son élément <version>. C’est l’un des deux fichiers que j’ai lus.

Votre version d’iCagenda, depuis la zone d’administration :

  1. Connectez-vous à votre administration Joomla (généralement à l’adresse votredomaine.com/administrator).
  2. Allez dans Système puis Gérer puis Extensions.
  3. Recherchez iCagenda et notez la version installée.

Faites attention à quel icagenda.xml vous lisez. Le paquet iCagenda inclut également un plugin de recherche intégré avec un manifeste du même nom, portant son propre numéro de version, sans rapport. Seul le chemin du composant ci-dessus vous indique ce que l’extension exécute réellement.

Votre version du noyau Joomla : dans l’administration, allez dans Système puis Informations système. Ou lisez /administrator/manifests/files/joomla.xml et relevez son élément <version>. C’est l’autre fichier que j’ai lu.

Il n’existe aucun moyen de déterminer la version d’iCagenda à partir du code source public de vos pages, et vous ne devriez pas essayer. Les ressources front-end de l’extension portent le hachage de médias global de Joomla plutôt qu’un numéro de version, et le seul nombre ayant la forme d’une version qui apparaît effectivement dans le code source de la page appartient au lot de ressources du module calendrier (un nombre faible, tel que 1.0.4), et n’a rien à voir avec le composant. Le fichier manifeste ou l’écran d’administration est la seule vérification fiable.

Appliquez ensuite la règle énoncée en haut de cette page : la ligne 4.0.x inférieure à 4.0.8 et un noyau inférieur à 6.1.2 signifie que vous êtes concerné.

Comment mettre à jour

La voie la plus sûre consiste à effectuer la mise à jour via Joomla lui-même, en réalisant d’abord une sauvegarde :

  1. Sauvegardez votre site (fichiers et base de données) avant d’apporter des modifications. La plupart des hébergeurs proposent des sauvegardes en un clic, ou utilisez une extension de sauvegarde Joomla.
  2. Dans l’administration Joomla, ouvrez Extensions puis Gérer puis Mettre à jour, et cliquez sur Rechercher les mises à jour. Si une mise à jour d’iCagenda est répertoriée, installez-la à partir d’ici.
  3. Si aucune mise à jour n’y apparaît, téléchargez la version actuelle directement auprès de l’éditeur, JoomliC, et installez-la via Extensions puis Installer.
  4. Quelle version installer : 4.0.8 est la version qui corrige ce problème, mais la version actuelle au moment de la rédaction est la 4.0.11, et les versions postérieures à 4.0.8 ajoutent une protection supplémentaire autour de la même fonctionnalité, notamment en bloquant l’exécution de code depuis le dossier média d’iCagenda. Passez à la 4.0.11 plutôt que de vous arrêter à 4.0.8. Sur l’ancienne ligne, passez à la 3.9.15 ou ultérieure.
  5. Autrement, la mise à jour du noyau Joomla vers la version 6.1.2 ou ultérieure referme également ce problème en particulier, mais elle ne remplace pas la mise à jour de l’extension : la vérification d’autorisation manquante se trouve dans iCagenda lui-même, et seule une mise à jour d’iCagenda corrige cela.
  6. Après la mise à jour, confirmez le nouveau numéro de version en suivant les étapes ci-dessus, et vérifiez que votre calendrier s’affiche toujours et que la soumission d’événements fonctionne toujours comme prévu.

Tant que vous y êtes, il vaut la peine de confirmer que Joomla lui-même et vos autres extensions sont à jour, car le même principe s’applique à tous.

Si vous utilisiez une version concernée

Comme cette faille a été exploitée avant qu’un correctif ne soit disponible, un site qui a utilisé une version concernée ne devrait pas présumer que la mise à jour suffit. La mise à jour referme la porte, mais elle ne vous dit pas si quelqu’un l’avait déjà franchie. Cela vaut la peine d’être vérifié calmement plutôt que de s’attendre au pire : la plupart des sites ne trouveront rien. Dans les propres mots de l’éditeur :

La mise à jour ferme le point d’entrée et protège la fonctionnalité de pièce jointe, mais ne nettoie pas un site déjà compromis. […] Conservez une copie de tout fichier suspect à titre de preuve, supprimez-les, changez vos mots de passe et identifiants Joomla, et auditez l’ensemble de votre site, pas seulement le dossier d’iCagenda.

Voici ce que vous (ou votre webmaster) pouvez rechercher sur votre propre site :

  • Des fichiers PHP sous images/icagenda/frontend/attachments/. Ce dossier ne devrait jamais contenir autre chose que des pièces jointes d’événements. Sur un hébergement Linux, la vérification est :

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Des événements anonymes non approuvés en attente dans votre file de modération, ce à quoi vous ne vous attendriez pas si vous n’avez jamais ouvert la soumission d’événements au public.
  • Des requêtes dans vos journaux d’accès provenant d’un scanner s’identifiant comme icagenda-batch/1.0.

À partir de la version 4.0.8, iCagenda vérifie également lui-même l’existence de signes de compromission et déclenche une alerte après la mise à jour s’il en trouve. L’éditeur reconnaît clairement que l’absence de cette alerte ne constitue pas une garantie ; il s’agit donc d’un signal utile plutôt que d’un certificat de bonne santé.

Si vous trouvez l’un de ces éléments, considérez le site comme compromis : conservez des copies des fichiers suspects à titre de preuve puis supprimez-les, changez tous vos identifiants (administration Joomla, base de données, FTP/SSH, panneau d’hébergement), examinez vos comptes utilisateurs Joomla et les groupes auxquels ils appartiennent, et auditez l’ensemble du site plutôt que le seul dossier d’iCagenda. Restaurer une sauvegarde antérieure au 15 juin 2026 est souvent plus sûr qu’un nettoyage sur place, car une porte dérobée laissée en place peut annuler le nettoyage. Si votre organisation dispose d’une équipe de sécurité informatique ou d’un CERT national, impliquez-la.

Je tiens à être clair : je n’ai pas vérifié votre site pour l’un quelconque de ces indicateurs, et je ne sais pas si votre site a été touché. Cette liste est là pour que vous puissiez vérifier par vous-même.

Je n’ai pas de webmaster / je suis bloqué

Si vous n’êtes pas la personne qui maintient le site, veuillez transférer cette page à la personne qui s’en charge (votre développeur web, agence ou hébergeur). Ils reconnaîtront rapidement les étapes ci-dessus.

Si vous maintenez le site vous-même et que vous êtes bloqué, je suis heureux de vous aider à vous orienter dans la bonne direction, sans frais. Contactez-moi en utilisant les coordonnées ci-dessous.

Contact

Evan Harris, chercheur en sécurité

Je prends contact concernant ce type de problème uniquement pour aider les exploitants à sécuriser leurs sites. Si vous préférez ne plus être contacté, faites-le-moi savoir et je le respecterai.

Références

Avis officiels et suivi

Éditeur (JoomliC)