Log4shell - RCE with log4j

Good morning,

Foreman uses some java based programs.
Does Foreman use log4j with them?
Will be an update delivered soon for this problem?



1 Like

I might be wrong here, but it’s my understanding the log4j element is within Puppet side. Not so sure whether Foreman also uses for another aspect. I’m interested to know whether both service and clients are effected, hopefully just server.

I tried checking the PuppetLabs site, it seemed incredibly slow to access their ticketing system.

Well, as far as I understand it, the puppet-server uses Java and a Tomcat instance is started on my
Foreman server, which is a default-installation with Katello:

tomcat     1111 666  666 Dec 99 ?        66:66:66 /usr/lib/jvm/jre-11/bin/java -Xms1024m -Xmx4096m -Djava.security.auth.login.config=/usr/share/tomcat/conf/login.config -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start

From what I have found by now, Puppet is unaffected. (official statement regarding Puppet Enterprise Server)
Since this only covers Puppet Enterprise, I did a little digging. Puppet states in it’s documentation it uses the logpack library, that is based on/forked from log4j 1.X, which is unaffected by that vulnarybility (see log4j release anouncement of 2.15.0 for affected versions).
Concerning Candlepin (which is the Java application running in tomcat), from their official docs, they state they are also using logback as logging backend, so that should not be affected either.

This is of course just what I as a sysadmin found googling and reading docs, so do not consider this an official statement. Still I want to leave my findings here.


Addendum: RedHat Satellite as a downstream product of Foreman/Katello is also not declared affected as per official statement from RedHat. This should be another strong indicator that the Katello stack is unaffected, since Satellite deploys both Puppet and Candlepin, too.


Hey Everyone,

We have access to Redhat’s knowledge base and this is an article published about the vulnerability. FYI, Foreman 2.5 is considered Satellite 6.


  • log4j is a package that is required on Red Hat Satellite 6 server logging tomcat information.
  • Candlepin uses Tomcat which is an integral component of Red Hat Satellite 6.
  • This issue only affects log4j versions between 2.0 and 2.14.1.
  • Red Hat Satellite 6 has 2 Java components


Red Hat Satellite 6  includes a dependency that installs log4j-1.2.17-16.el7_4.noarch on the RHEL7 host running the Satellite stack.  Analysis indicates that the vulnerability in CVE-2021-44228 only applies to versions 2.X and higher. There currently isn't any  known instance of this current CVE in log4j-1.X. Additionally, The Candlepin application and the Tomcat configured for Red Hat Satellite 6, do not utilize JNDI which is the protocol that introduces the vulnerability.


Puppetlabs has confirmed that their application server is not effected by this CVE, 

Refer to https://puppet.com/blog/puppet-response-to-remote-code-execution-vulnerability-cve-2021-44228/

Just some more details here if anyone is curious:


This should probably be revisited, in light of CVE-2021-4104, remote code execution through log4j 1.2. It does require a non-default configuration.


Hey @jkalchik

We address this in the blog:

Additionally, a vulnerability of lesser impact Red Hat BZ#2031667 seems to affect log4j 1.x, but only if a JMS Appender has been configured, which, by default, Tomcat’s log4j.properties are not, so Candlepin/Tomcat is still not affected by this (since an attacker would need root access to configure the property file for that vulnerability to be exploitable).