It isn't. We're starting the release cycle for 2.2.1 with Log4j 2.16.0 in a few hours. Thank you for update.
On Fri, Dec 17, 2021 at 11:17 AM Cristian Zamfir <[email protected]> wrote: > > Hi, is the lower priority for CVE-2021-45046 still accurate in light of this? > https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased > > On Thu, Dec 16, 2021 at 6:22 PM Tim Allison <[email protected]> wrote: >> >> The recently publicized CVE-2021-44228 in log4j2 allows for >> unauthenticated remote code execution and has the highest severity >> ranking possible. This is a very serious vulnerability. In the >> following, we report on our findings and mitigations for the Apache >> Tika project. >> >> Apache Tika Version 2.x >> Tika 2.x versions 2.0.0-BETA through and including 2.1.0 all use >> vulnerable versions of log4j2[1]. We have not put the effort into a >> proof of concept to prove that it is vulnerable, but we believe it >> would be fairly trivial. On Monday, December 13 we upgraded to log4j >> 2.15.0 in our main branch and began the release process for Tika >> 2.2.0. We expect to release Tika 2.2.0 later today. >> >> After we began the release process and after the reports of >> CVE-2021-45046, Konstantin Gribov, a Tika PMC member, reviewed our >> codebase and determined that risks within our codebase are >> negligible[2]. Nevertheless, we plan to release an upgrade that >> includes log4j2 2.16.0 in early January, 2022. >> >> Apache Tika versions 1.x >> All currently released versions of 1.x rely on the older log4j 1.x >> versions which are not vulnerable to CVE-2021-44228. However, given >> that log4j 1.x does have a lower severity CVE (CVE-2019-17571) against >> it and given that it hit end of life in August 2015, we decided to >> make some breaking changes in Tika's 1.x branch and upgrade to log4j2 >> 2.16.0 in the next release (1.28). We have started the release process >> for 1.28 today. >> >> Please note: >> >> 1. This is a fast moving and dynamic set of vulnerabilities. We will >> continue to review new findings and will make updates as appropriate. >> >> 2. As a PMC, we have set September 30, 2022 as the EOL for the Tika >> 1.x branch. We will continue to make security upgrades and releases >> for the 1.x branch until then. We do not plan to backport new features >> to the 1.x branch. We encourage 1.x users to migrate to 2.x as soon >> as possible [3]. >> >> 3. Parsing untrusted files with non-verified parsers is always >> dangerous. This is a challenge not limited to Apache Tika and its >> dependencies. We highly encourage as much containment as possible >> around file parsing generally. See our wiki on the robustness of Tika >> and what we're doing to improve its robustness [4]. >> >> >> Please let us know if you have any questions. >> >> Sincerely, >> Tim >> >> >> 16 December 2021, 1715 UTC >> >> [1] In Tika 2.0.0-ALPHA we used the older log4j 1.x which is not >> vulnerable to CVE-2021-44228. >> >> [2] >> https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460168#comment-17460168 >> >> [3] https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0 >> >> [4] >> https://cwiki.apache.org/confluence/display/TIKA/The+Robustness+of+Apache+Tika
