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 <[email protected]> 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 <[email protected]> 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 > > >
