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 >
