Updated 2021-12-15

Dear customer,

A vulnerability affecting the Log4j module has been recently published allowing a “Remote Code Execution”. This vulnerability is particularly critical as it impacts a very large number of tools.
The systems affected by this vulnerability are:
Vulnerable systems :
An exhaustive list of products affected by this vulnerability is available via this link.
  • Apache Log4j versions 2.0 à 2.14.1
  • Apache Log4j versions 1.x (deprecated versions) if the JMS Appender component is configured to support JNDI (this is a very specific configuration)
  • Products using a vulnerable version of Apache Log4j
Solutions :
  • Upgrade log4j to version 2.15.0 where possible, or approach vendors whose product uses a vulnerable Log4J to get a patch.
  • Temporary protection measures are applicable while waiting for the patch:
    • For applications using versions 2.7.0 and later of the Log4J library it is possible to protect against any attack by modifying the format of the events to be logged with the syntax %m{nolookups} for data that would be provided by the user. This modification requires modifying the Log4J configuration file to produce a new version of the application. This requires the technical and functional validation steps to be carried out again before the deployment of this new version.
    • For applications using versions 2.10.0 and later of the Log4J library, it is also possible to protect against any attack by changing the formatMsgNoLookups configuration parameter to true, for example when launching the Java virtual machine with the option -Dlog4j2.formatMsgNoLookups=true. Another alternative is to remove the JndiLookup class in the classpath parameter to eliminate the main attack vector (researchers do not rule out the existence of another attack vector).
    • A tool was recently released that allows hot modification of JVMs without the need to restart the JVM, more information here. This tool allows the hot bypass of the vulnerability, it does not dispense with applying the configuration (mentioned below) in hard in the JVM configuration. So when your JVMs restart, they will definitely take the bypass configuration.


Actions taken by AntemetA:
  • IPS Signatures specific to this vulnerability have been blocked on AntemetA front-end IPS allowing perimeter protection of the AntemetA Cloud.
  • For AntemetA SOC customers, specific monitoring alerts for this vulnerability are in place.


Find the ANSSI bulletin on this link.

Sincerely yours,

Your AntemetA customer service.
Customer Area Access
+33 800 22 24 24

By continuing your browsing, you accept the deposit and use of cookies for the web site operation, visits statistics and social networks sharing. At any time you can change your setup by clicking on Cookies settings in the website footer.

I agree

Set your cookies

To ensure optimal navigation we use several cookies types. You can choose to disable them. These changes are valid only on the equipment and browser currently in use.


Allow deposit and reading of operating cookies to let me enjoy the website ergonomic, the language preferences and the browsing security.


Allow deposit and reading of statistics cookies to let AntemetA track website traffic and improve the service quality.

Social networks

Allow deposit and reading of social network cookies to let me share content on LinkedIn, Facebook, Twitter, Google + and YouTube.