A Remote Code Execution (RCE) vulnerability was discovered in the popular Java logging library, Log4j. It is tracked via CVE-2021-44228 and is known as Log4Shell. This is a serious vulnerability that affects many software products and online services.
Apache Flink 1.11+ is affected by both vulnerabilities. Apache Flink 1.10 and earlier versions are not affected by this vulnerability.
All Ververica Platform components besides Apache Flink are unaffected as they are using Logback instead of Log4j. In the context of Log4Shell, a related - less severe - vulnerability has also been identified in Logback. This vulnerability requires writing access to the Logback configuration file, which should not be the case in typical Ververica Platform deployments.
Following the emergency releases of Apache Flink which upgraded Log4j to 2.16.0, we have just released new versions of our distribution of Apache Flink for Flink 1.10 to Flink 1.14:
In contrast to Apache Flink 1.10, Ververica’s distribution of Apache Flink 1.10 is affected by Log4Shell because it is already using Log4j2 whereas upstream Apache Flink 1.10 is still using Log4j1.
In addition, we have released Ververica Platform 2.5.3 and Ververica Platform 2.6.1 which reference the updated Flink images in their configuration and — just in case — include an upgraded version of Logback.
We recommend trong>any users of Ververica Platform 2.5 and Ververica Platform 2.6 to upgrade as soon as possible.
We also recommend any user of Ververica Platform to upgrade all of their Deployments to use the newly released versions of Apache Flink regardless of which version of Ververica Platform they are using. Please check this documentation on how to add new Flink images to the Ververica Platform configuration. Please check the release notes of Ververica Platform 2.5.3 and Ververica Platform 2.6.1 as well as the respective documentation for a complete list of available images.
We’ve identified all internal, internet-facing services that were using Log4j2 and implemented upgrades, and recommended mitigation measures.
We are working with our sub-processors to ensure they remediate any vulnerabilities in their environments. These sub-processors are primarily related to customer incident response (Zendesk, Pagerduty).
In case of questions please get in touch or reach out to your account manager.