Si vous avez reçu un courriel de ma part vous renvoyant vers cette page, c’est que votre site web semble exécuter une version de powermail (l’extension de formulaires pour TYPO3 par in2code, paquet Composer in2code/powermail, qui se trouve dans vos fichiers sous typo3conf/ext/powermail/ ou, sur une installation Composer, sous vendor/in2code/powermail/) qui se situe dans la plage de versions affectées par un problème de sécurité connu. Cette page explique en quoi consiste le problème, comment déterminer s’il s’applique à votre site, vers quelle version mettre à jour, et comment vérifier si quelqu’un l’a déjà utilisé contre vous.

Avant toute chose, le fait le plus important au sujet de cet avis : une version dans la plage affectée ne signifie pas, à elle seule, que votre site est exposé. Le problème décrit ci-dessous n’entre en jeu que sur les formulaires qui ont un champ marqué comme le nom de l’expéditeur, et je ne peux pas voir de l’extérieur comment vos formulaires sont configurés :

  • Le problème n’atteint qu’un formulaire powermail qui possède au moins un champ dont la case « Ce champ contient le nom de l’expéditeur » (en anglais : “This field contains the Name of the sender”, dans l’onglet Étendu du champ, dans le backend TYPO3) est cochée. Si aucun de vos formulaires n’utilise ce marquage, cela ne vous concerne pas, même sur une version affectée.
  • Cela dit, ce marquage est courant. Le champ standard Nom de l’assistant de formulaires le définit généralement, et l’avis de l’éditeur lui-même qualifie cette configuration de « courante et proche de la configuration par défaut ». Veuillez donc vérifier plutôt que supposer.

Je peux lire votre version de powermail depuis un fichier public, mais je ne peux pas lire les réglages de vos formulaires ; cet avis est donc un avertissement préventif plutôt qu’un constat confirmé concernant votre site.

Le problème est CVE-2026-77136 (avis TYPO3 TYPO3-EXT-SA-2026-022), une injection de gabarits côté serveur sans authentification dans le traitement du courrier de l’extension. Il affecte toutes les versions de powermail antérieures à 10.9.3, toutes les versions 11.x et 12.x antérieures à 12.6.1 et toutes les versions 13.x antérieures à 13.2.1. Il est corrigé dans 10.9.3, 12.6.1 et 13.2.1, toutes publiées le 25 août 2026, une pour chaque ligne TYPO3. Aucune version n’est assez ancienne pour ne pas être affectée : la faiblesse fait partie de la conception d’origine de l’extension, ce n’est pas quelque chose arrivé dans une version ultérieure.

Un mot sur l’urgence, car ceci est un avis conditionnel. Si aucun de vos formulaires n’a de champ marqué comme le nom de l’expéditeur, la mise à jour relève de la maintenance ordinaire. Si l’un d’eux en a un, veuillez traiter la mise à jour comme une priorité : l’avis de l’éditeur indique que ce problème est activement exploité, et dans cette configuration un visiteur sans aucun compte peut faire évaluer par votre serveur du code de gabarit de son choix, ce qui peut divulguer votre configuration, vos variables d’environnement et votre code source et, selon l’installation, mener à une exécution de code à distance.

Il s’agit d’une faille d’extension, pas d’une faille du cœur de TYPO3. Un TYPO3 parfaitement à jour ne vous protège pas si l’extension powermail elle-même est sur une version affectée.

Ce message est-il légitime ?

Oui. C’est un avis de divulgation responsable, de bonne foi, émanant d’un chercheur en sécurité indépendant. Je ne vous demande pas d’argent, de mots de passe ni d’accès à votre site, et je n’ai pas tenté de m’y introduire, de soumettre l’un de vos formulaires ni de lui envoyer quoi que ce soit.

Tout ce que j’ai fait, c’est consulter des fichiers publiquement visibles que votre site sert à chaque visiteur (de la même manière que votre page d’accueil est publique) et noter la version que les ressources propres de l’extension permettent d’identifier. Je n’ai spécifiquement pas soumis de formulaire, je n’ai envoyé de syntaxe de gabarit nulle part, et je ne me suis pas approché du traitement du courrier de l’extension. Rien dans cette vérification ne touche vos données, votre backend ni aucune partie privée de votre site (plus de détails sous Ce que j’ai fait et n’ai pas fait ci-dessous).

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

Pourquoi cela compte

Powermail construit les formulaires de contact et de demande d’un très grand nombre de sites TYPO3. Quand un visiteur soumet un formulaire, l’extension envoie un courriel au destinataire configuré du site, et elle renseigne le nom de l’expéditeur de ce courriel à partir des champs du formulaire que le rédacteur a marqués comme contenant le nom de l’expéditeur.

Powermail permet aux rédacteurs d’écrire de petits fragments du langage de gabarits Fluid de TYPO3 dans certains réglages du courrier, par exemple pour qu’un objet puisse afficher “Message from {firstname}”. C’est une fonctionnalité délibérée pour des valeurs saisies par un rédacteur. Dans les versions affectées, le nom de l’expéditeur assemblé à partir de la saisie du visiteur lui-même était remis au même moteur de gabarits, comme si un rédacteur l’avait écrit. Un visiteur pouvait donc taper de la syntaxe Fluid dans le champ du nom d’un formulaire public, et le serveur l’évaluait en construisant le courriel du destinataire.

Il en découle deux choses, qui tirent dans des directions opposées. La première est que cela ne compte que là où un champ de formulaire porte réellement le marquage du nom de l’expéditeur ; un site dont les formulaires n’utilisent pas un tel champ n’est pas atteignable par ce problème. La seconde est que là où le marquage est défini, aucun compte, aucun mot de passe et aucune coopération de quiconque ne sont nécessaires : le formulaire est ouvert au public par conception, et la seule chose que l’attaquant doit faire est de le soumettre. L’éditeur classe le problème comme critique (un score CVSS 4.0 de 9.5), et son avis indique qu’il est activement exploité.

Je décris cela au niveau dont un propriétaire de site a besoin pour agir, et pas au-delà. Je ne publie pas les détails qui permettraient à quelqu’un de le reproduire, et je vous demanderais de ne pas l’essayer contre votre propre site ni celui de quiconque. Vérifier vos champs de formulaire et votre version, comme décrit ci-dessous, vous dit tout ce qu’il faut pour décider quoi faire.

Si mon courriel a cité ce problème, cela signifie que la version identifiée par les ressources de votre site se situe dans la plage affectée. Je n’ai pas testé si votre site en particulier est exploitable, et je ne peux pas voir comment vos formulaires sont construits. Tout ce que j’ai observé, c’est la version.

Suis-je concerné ?

Deux questions en décident, dans cet ordre.

Premièrement : un champ de formulaire porte-t-il le marquage du nom de l’expéditeur ?

C’est la question décisive, et vous seul pouvez y répondre. Vérifier vos propres formulaires est parfaitement sûr et constitue tout l’objet de cette page.

  1. Connectez-vous au backend TYPO3 et ouvrez la page (ou le dossier) qui contient vos formulaires powermail. Chaque formulaire est un enregistrement avec une ou plusieurs pages, et chaque page contient les champs.
  2. Ouvrez chaque enregistrement de champ et cherchez, dans son onglet Étendu, la case « Ce champ contient le nom de l’expéditeur ». Elle est le plus souvent cochée sur le champ où les visiteurs saisissent leur nom.
  3. Si aucun champ d’aucun de vos formulaires n’a cette case cochée, ce problème n’atteint pas votre site, même sur une version affectée, bien que la mise à jour reste utile au titre de la maintenance ordinaire.
  4. Si n’importe quel champ l’a cochée, le problème vous concerne et vous devriez mettre à jour rapidement (voir Comment mettre à jour). Si vous ne pouvez pas mettre à jour tout de suite, décochez cette case sur chaque champ qui la porte : c’est la mesure d’atténuation recommandée par l’éditeur lui-même et elle ferme le problème à elle seule. Le coût est que le nom de l’expéditeur ne sera plus renseigné dans les courriels envoyés par le formulaire, jusqu’à ce que vous mettiez à jour et la cochiez de nouveau.

Veuillez ne pas essayer de reproduire le problème contre votre propre site ni celui de quiconque ; vous n’en avez pas besoin pour répondre à la question ci-dessus.

Deuxièmement : quelle version utilisez-vous ?

Vous n’avez pas à me croire sur parole. Notez qu’il n’existe pas de fichier de version public pour une extension TYPO3 comme il en existe, par exemple, pour une extension WordPress ; les lectures fiables se font donc toutes depuis l’intérieur de votre installation :

Depuis le backend TYPO3 (source de référence) : allez dans Outils d’administration puis Extensions. La liste des extensions installées montre la version de chacune ; trouvez powermail. (Sur une installation basée sur Composer, la liste est en lecture seule, mais elle montre tout de même la version installée.)

Depuis la ligne de commande, sur une installation Composer : exécutez composer show in2code/powermail dans le répertoire de votre projet. La ligne versions est la version installée.

Depuis les fichiers : ouvrez ext_emconf.php dans le dossier de l’extension (typo3conf/ext/powermail/ sur une installation classique, vendor/in2code/powermail/ sur une installation Composer) et cherchez l’entrée 'version' près du début.

Appliquez ensuite cette règle, en notant que les versions se comparent numériquement, pas alphabétiquement (10.9.2 est plus récente que 10.8.2, et 13.2.1 est plus récente que 13.2.0) :

  • 13.0.0 à 13.2.0 : potentiellement affecté, sous réserve de la question du marquage ci-dessus. Mettez à jour vers 13.2.1 ou plus récent.
  • 11.0.0 à 12.6.0 : potentiellement affecté, sous réserve de la question du marquage ci-dessus. Mettez à jour vers 12.6.1 ou plus récent. Cela inclut toutes les versions 11.x : il n’y a pas de correctif séparé pour la 11.x, et 12.6.1 fonctionne sur les mêmes versions de TYPO3 (12.2 à 12.5) que la 11.x ; c’est donc une simple mise à jour d’extension sans montée de version de TYPO3.
  • 10.9.2 et tout ce qui est plus ancien : potentiellement affecté, sous réserve de la question du marquage ci-dessus. Si vous êtes en 9.x ou 10.x (TYPO3 11.5), mettez à jour vers 10.9.3 ou plus récent. Si vous êtes en 7.x ou 8.x (TYPO3 8.7 à 10.4), voyez le paragraphe suivant.
  • 13.2.1, 12.6.1 ou 10.9.3 et plus récentes au sein de leur ligne : déjà corrigé en ce qui concerne ce problème.

Si vous êtes sur powermail 7.x ou 8.x, il n’existe pas de version corrigée qui fonctionne sur votre version de TYPO3 : 10.9.3 exige TYPO3 11.5. Pour ces sites, l’instruction de l’éditeur est la mesure d’atténuation ci-dessus, décocher « Ce champ contient le nom de l’expéditeur » sur chaque champ qui la porte, et planifier une montée de version de TYPO3 vers une ligne prise en charge, où une version corrigée de powermail est disponible. Les versions de TYPO3 sur lesquelles tournent ces générations sont elles-mêmes hors support depuis longtemps, ce qui est une seconde raison de planifier cette étape.

Une vérification qui ne fonctionne pas, ne vous y fiez donc pas. Si vous regardez le code source de votre page, vous verrez les ressources de l’extension avec un long nombre accolé, par exemple .../JavaScript/Powermail/Form.min.js?1785752971 (ou incorporé dans le nom du fichier comme Form.min.1785752971.js). Ce nombre est un horodatage de fichier que TYPO3 ajoute pour l’invalidation de cache, pas une version, et vous ne pouvez pas en lire une version à l’œil nu. Il se trouve que c’est ce que ma vérification a utilisé, d’une manière que j’explique plus bas, mais les lectures ci-dessus sont celles auxquelles se fier.

Comment mettre à jour

Les versions corrigées sont publiées sur le TYPO3 Extension Repository (TER), sur Packagist et sur GitHub ; il s’agit donc d’une mise à jour d’extension normale. Sauvegardez d’abord, puis mettez à jour via le mécanisme correspondant au mode d’installation de votre site :

  1. Sauvegardez votre site (fichiers et base de données) avant tout changement. La plupart des hébergeurs proposent des sauvegardes en un clic.
  2. Installation Composer (la plupart des sites en TYPO3 12 et 13, et beaucoup en 11) : dans le répertoire de votre projet, exécutez la mise à jour de l’exigence pour votre ligne, par exemple composer require "in2code/powermail:^13.2.1" sur TYPO3 13, "in2code/powermail:^12.6.1" sur TYPO3 12, ou "in2code/powermail:^10.9.3" sur TYPO3 11.5. Exécutez ensuite vos étapes habituelles d’après mise à jour (vendor/bin/typo3 extension:setup sur TYPO3 12 et 13, ou l’équivalent utilisé par votre déploiement) et videz les caches.
  3. Installation classique (sans Composer) : dans le backend TYPO3, allez dans Outils d’administration puis Extensions, basculez la liste déroulante sur Obtenir des extensions, cherchez powermail et mettez-le à jour vers la version corrigée de votre ligne. Si votre site ne peut pas atteindre le TER, l’avis de l’éditeur donne des liens directs vers les archives des versions (voir Références) ; téléversez l’archive via Extensions puis le bouton de téléversement. Videz les caches ensuite.
  4. Après la mise à jour, confirmez la nouvelle version (13.2.1, 12.6.1 ou 10.9.3, selon votre ligne) avec les étapes ci-dessus, et soumettez l’un de vos propres formulaires à titre de test pour vérifier que les courriels arrivent toujours normalement.

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

Après la mise à jour : cela a-t-il déjà été utilisé contre vous ?

La mise à jour ferme le problème et, pour beaucoup de sites, c’est là toute la tâche. Cette page est un avis préventif, pas un rapport d’incident : je n’ai aucune visibilité sur ce qui a pu se produire sur votre site, et je n’ai pas regardé.

Mais parce que l’éditeur signale que ce problème a été exploité dans la nature, un suivi vaut la peine, et il est conditionné à la même question du marquage. Si votre site avait un formulaire avec un champ de nom d’expéditeur pendant qu’une version affectée était en service, alors il était possible que quelqu’un exécute du code de gabarit sur votre serveur via ce formulaire, et la mise à jour n’annule rien de ce qui a déjà pu être lu. L’avis de l’éditeur donne une autovérification simple, et elle ne coûte rien :

  • Examinez les noms d’expéditeur que vos formulaires ont reçus. Vérifiez les courriels que vos formulaires vous ont envoyés, et les soumissions stockées dans le backend TYPO3 (le module Mails propre à powermail) ou dans la table de base de données tx_powermail_domain_model_mail, à la recherche de noms d’expéditeur contenant de la syntaxe Fluid comme f:, v: ou {namespace. Le nom d’un vrai visiteur ne ressemble jamais à cela.
  • Si vous en trouvez, la consigne de l’éditeur est de traiter le système comme potentiellement compromis. Comme ce problème peut exposer la configuration et les variables d’environnement, la réponse raisonnable dans ce cas est de renouveler les secrets que votre site détient : le mot de passe de la base de données, l’encryptionKey de TYPO3, le mot de passe de l’Install Tool, et toute clé d’API ou tout identifiant stocké dans votre configuration ou votre environnement. Passez en revue vos utilisateurs du backend à la recherche de comptes que vous ne reconnaissez pas, cherchez des fichiers inattendus sur le serveur, et si votre organisation dispose d’une équipe de sécurité informatique ou d’un CERT national, associez-les.
  • Si vous n’en trouvez aucun, et surtout si aucun champ ne portait le marquage au départ, la mise à jour seule suffit.

Pour être clair sur le cadre : ceci est une autovérification, pas une déclaration que votre site a été attaqué. Cet avis repose sur une empreinte de version, pas sur une quelconque preuve d’incident.

Ce que j’ai fait et n’ai pas fait

Pour être parfaitement transparent sur la vérification derrière mon courriel : je n’ai lu que des fichiers que votre site sert déjà à chaque visiteur, en l’occurrence votre page d’accueil et les adresses des ressources powermail qui y sont inscrites. Je n’ai pas accédé à votre backend TYPO3, à votre base de données, à la configuration de vos formulaires ni à aucune partie privée du site.

En particulier, je n’ai jamais soumis l’un de vos formulaires et n’ai jamais envoyé de syntaxe de gabarit à votre site ni à celui de quiconque. Rien n’a été soumis, testé ou exploité. Cela pèse davantage ici que sur la plupart de ces pages, car une soumission de formulaire est exactement l’action que ce problème concerne ; « je n’y ai pas touché » constitue donc toute la différence entre une divulgation et une intrusion.

Comment la version a été identifiée, puisqu’une extension TYPO3 ne publie aucun fichier de version : TYPO3 accole à l’URL de chaque ressource l’heure de sa dernière modification, comme dans Form.min.js?1785752971. Sur un site installé avec Composer, cette heure est le moment où la version a été publiée, car Composer la préserve en dépaquetant le paquet ; le nombre identifie donc la version exactement : chaque version de powermail a le sien. J’ai comparé le nombre servi par votre site aux heures de publication connues et je ne vous ai écrit qu’en cas de correspondance exacte. Tout le reste, qui est ce que sert typiquement un site installé via le gestionnaire d’extensions ou déployé par copie de fichiers, se lit comme « inconnu », et je n’ai pas écrit du tout à ces sites.

Cette méthode a un angle mort connu, et elle pèche par excès de prudence. Les correctifs ne changent que le code PHP de l’extension, pas ses ressources publiques. Donc si votre site a été corrigé en remplaçant seulement le code (un correctif manuel à chaud plutôt qu’une mise à jour complète), ses ressources portent encore l’horodatage de l’ancienne version et il se lit comme une version affectée alors qu’il est protégé. Si vous avez déjà remédié au problème par d’autres moyens, aucune action n’est nécessaire, et je vous prie d’excuser le dérangement.

Je m’abstiens aussi délibérément de publier les détails qui aideraient quelqu’un à exploiter ce problème. La description ci-dessus s’arrête au niveau dont un propriétaire de site a besoin, et je ne mets en lien aucun code de démonstration.

Ceci est une observation fondée sur la version : les ressources de votre site identifient une version dans la plage affectée. Ce n’est pas une affirmation que votre site était exploitable au moment de ma vérification. Comme le problème dépend d’un réglage de champ de formulaire que je ne peux pas voir, un site dans cette plage peut fort bien ne pas être exposé du tout, et un site dans cette plage peut être protégé par ailleurs par d’autres moyens, comme un pare-feu applicatif web.

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

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

Si vous entretenez le site vous-même et que vous êtes bloqué, je serai heureux de vous orienter dans la bonne direction, sans frais. Contactez-moi via 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 / extension