Tridion Sites is not affected by this vulnerability.
• Tridion Content Delivery
does not use log4j core, it uses logback instead, which is
not vulnerable to this attack.
We do include the log4j-api JAR in our services, but this is not the file that has the vulnerability. Security scans may still flag the log4j-api due to the version. To mitigate this, the log4j-api version in Content Delivery services can be safely updated to the most recent version (2.17 or later).
https://logging.apache.org/log4j/2.x/download.htmlOne exception is the Deployer service in
SDL Web 8/8.1. The log4j-core library is included but it not actually implemented. This can be safely removed from Deployer services that have it present. Security scans may also still pick up log4j-api due to its version though it is not vulnerable. This jar file can also be updated to the most recent version (2.16 or later).
https://logging.apache.org/log4j/2.x/download.html• Tridion Content Manager search (SOLR)
does use log4j core, but it is a very old version (
1.x) which is also
not vulnerable. The log4j 1.x implementation in Content Manager search does *not* use the JMS Appender and thus the customization that can lead to a vulnerable position is not in place.
See KB article
How to remediate a reported log4j vulnerability in the CM server Solr library?https://logging.apache.org/log4j/2.x/log4j-appserver/index.html.
•
DD4T/DXA – these do not include log4j 2 core by default.
For all other RWS products see: https://gateway.sdl.com/communityknowledge?articleName=000017712However, customers should confirm that any custom web applications built against these frameworks do not use the affected libraries.
