IMPORTANT: Please see the latest announcement here.
SailPoint has fully mitigated the Log4J RCE vulnerability (CVE-2021-44228) in all impacted products.
We are aware of the recently-identified Log4J DoS vulnerability (CVE-2021-45046) that is also applicable to the impacted products. While this new DoS vulnerability has a low severity (CVSS score of 3.7 per NVD), we are actively working on addressing this vulnerability by upgrading to Log4J 2.16.0 and expect product releases that include the updated library to be available in the coming days.
We will be issuing further communications once this issue has been addressed. No action is needed at this time.
IdentityIQ 8.0 and later (and all patch levels for those versions) is susceptible to the log4j RCE vulnerability. IdentityIQ 7.3 and earlier is likely susceptible only if customers have configured the use of a JMSAppender (this is not configured out of the box and not a likely configuration). Our immediate mitigation strategy is to provide a blog post that indicates we are vulnerable and provides information on configuring the Java system property to remove the vulnerability. Our mid-term mitigation strategy (within 30 days per our Product Vulnerability Management policy) will be to deliver an updated log4j library that will permanently mitigate the issue.
The instance of Elasticsearch in FAM is susceptible to this vulnerability. Public documentation indicates that the version of log4j in that environment cannot have the vulnerability mitigated with a system property, so the library will need to be updated. We are working on determining the best way for that to happen (whether we can do it in official packaging or whether it will have to be done manually by the customer). It is not clear at this time how much user-defined input (including data from managed systems like file names or file content) can make it into Elasticsearch logging based on where this component is in the stack.
As an aside, our testing has shown that the information indicating later versions of the JDK prevent this vulnerability from occurring have not proven to be true. Public discussion about this vulnerability is still pretty raw, so not everything you read on the internet is true. Who’da thunk it.