ArcGIS Enterprise Log4j Vulnerability (CVE-2021-44228) Patch or Mitigation?

Jump to solution
12-11-2021 09:13 AM
New Contributor III

Good afternoon, is there any patches in the works or potential mitigation steps for the latest java log4j vulnerability (CVE-2021-44228)?  I know that GeoEvent server uses log4j and can assume some other enterprise server's or portal potentially do as well.  Any help would be appreciated in resolving this zero-day.


Carl Flint, GISP
162 Replies
New Contributor

This suggestion is workaround not a solution. 
ArcGIS and Apache Log4j Vulnerabilities (


0 Kudos
Occasional Contributor III

The issue here is that the ESRI platform is using a lot of tools/components from other groups (ElasticSearch) that have this as a nested dependency. So they are in the place to wait for that component to be patched/upgraded to then upgrade their versions.

This is a much bigger issue than anyone really sees in this scramble.

Occasional Contributor II

The latest blog posts provides Log4Shell mitigation scripts that are strongly recommended.

Occasional Contributor

I just ran these scripts in our Dev environment and all worked moving on to our other environments. Huge thanks to @RandallWilliams  and the rest of the dev and security teams for making these scripts available so quickly!

New Contributor III

Quick question regarding the python 3 requirement we are running twin 10.6.1 servers I can see the directory specified for python 3 in the article do we need to actually run the executable to install python or is it already installed? When we do the CMD I can tell we call the exe just wanting to making sure we didn't need to run it separately beforehand.

Sorry if this seems a silly question



0 Kudos
Occasional Contributor

Hey Tom, 


 Python 3.x is already installed with ArcGIS Server and the executable resides in that directory. So, all you are doing in command prompt is pointing the python executable in that location, to the python script file you downloaded, and providing a command for the script(--list or --delete) for example (assuming you have CD'd to the same folder/directory where Esri's script resides): 


List the .jar files:

"C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\bin\Python\envs\arcgispro-py3\python.exe"  --list  "c:\Program Files\ArcGIS\Server" 


Delete the offending code in the identified .jar files: 

"C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\bin\Python\envs\arcgispro-py3\python.exe"  --delete "C:\Program Files\ArcGIS\Server"



I hope this helps!




Example of the list command being run via the script: 



New Contributor III

Hey Rex 

Thanks for confirming thought was the case just wanted to make sure 🙂


Thanks for the helpful comments and images above as well 🙂




Esri Regular Contributor

Thanks @RexRobichaux and others! No-sleep Randall is still trying to keep up. 

I'm sure inquiring minds and IT departments want to know and are asking:

"WAIT WAIT WAIT - the version numbers on those files have NOT CHANGED! WHERE'S MY LOG4J 2.16 ERMAGERD!!""

Here's the deal:

A. check out Apache's statement:

Log4j 2.x mitigation: Implement one of the mitigation techniques below.

  • Java 8 (or later) users should upgrade to release 2.16.0.
  • Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
  • Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For expediency, we have elected to take the third option. It eliminates the source of the vuln - which is the fact that JNDILookup was enabled by default. The fix Apache provided in Log4J 2.15 was to make this an OPTIONAL tool. We have eliminated this class altogether. 

Like I mentioned in an earlier reply, we'd dearly love to just upgrade Log4j and make everyone's vuln scanners test clean. That's just not realistic this early in the game. 

Think about this in term of other vendor patches - a Microsoft patch for any give issue might go through multiple iterations before an issue is fully fixed. It's easily possible that even if we could patches for all upstream vendors aligned, Apache will release Log4J 2.17 to fix a whole different but similar issue. None of us have time to chase that. So we've provided what we can provide NOW based on the Log4J docs to mitigate this issue and help make you safe while this continues to shake out.

This won't be the last issue to shake the internet - that's the only thing I can promise without any doubt. 



New Contributor

The bash script for linux throws error,

-bash: ./ /bin/bash^M: bad interpreter: No such file or directory

works when edited with "sed -i -e 's/\r$//'". 

Esri Regular Contributor

@MullaiManickavalli Yes, we're aware. There's a windows linebreaks issue in the file, It should be fixed very soon. Good catch and fix.