I filed this issue so we have something to track: https://github.com/apache/helix/issues/1921
I'm attempting to get Log4J 2.16.x building and running properly locally. I will submit a PR if I can get it working. Thanks! On Tue, Dec 14, 2021 at 8:40 AM Brent <brentwritesc...@gmail.com> wrote: > Thanks Hunter, much appreciated! I will try to put together a patch with > what I've done for remediation elsewhere (good news is it's not much since > Helix still inherits Log4J 1.x). If you wouldn't mind, I might also file > an issue to consider upgrading to Log4J 2.16.x that was just pushed out ( > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4). That > one will require some more thought to make sure things don't break I > suspect. > > ~Brent > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <naren...@gmail.com> wrote: > >> This is being discussed. Feel free to post a patch if you're interested >> (but do let us know so there's no duplicate effort being made here). >> >> On Fri, Dec 10, 2021 at 1:33 PM Brent <brentwritesc...@gmail.com> wrote: >> >> > [Feel free to take this offline or out-of-band if this is an >> inappropriate >> > place to discuss this] >> > >> > Is there any hotfixing planned as a result of the Log4J zero day going >> > around? >> > >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/ >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 >> > >> > From what I can tell, Helix seems to be building with >> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14 >> which in >> > turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17 >> > >> > The exploit is more prevalent in the 2.x versions of Log4J, but there >> are >> > scenarios where 1.x is exploitable and it's been pointed out that 1.x is >> > also end of life and has other vulnerabilities. >> > >> > See: >> > >> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 >> > >> > Thanks! >> > >> > ~Brent >> > >> >
