A zero day exploit has been found which affects the latest version of jamf.
This exploit affects the java logger log4j, which is used by Jamf. If you are hosting an onpremise version, take a look at the JSSAccess.log to check for anomalies.
If you are running Windows server and IIS you can also check your IIS logs for lines that contain 'jndi'. They will be located in a directory similar to this: C:\inetpub\logs\LogFiles\W3SVC1\
Also, the default path to the JSSAccess.log on Windows Server is C:\program files\jss\logs\JSSAccess.log
@mvanstone Hi. In your JSSAccess.log you would want to look for unusual account names, or possibly failures. Look for anything that seems out of the ordinary. If you run IIS I highly recommend you search your IIS logs for the string 'jndi'. The string containing jndi will most likely be the attack string.
I have applied the patch from Jamf and can confirm that JNDI code from the log is no longer triggered.
log4j2.formatMsgNoLookups: true is no longer necessary if you are on 10.34.1.
If you want to test it yourself, generate a domain at http://www.dnslog.cn/ and build a jndi command with the domain and try to log in to your jss with the jndi string. If you are still vulnerable, your dns records should be visible on the page where you generated the domain.