BKBK, while it's true that the broad concensus in the early days of the news about log4jshell (starting Dec 9) was indeed that "it affected only log4j 2.0-2.15, then 2.16, and finally fixed as of 2.17 as of now), subsequent CVEs identified a rather edge case scenario in even log4j 1.x files.
As such, folks are indeed finding that scanners (which look by file name) are tripping over the fact that CF2018 has this log4j-1.2.15.jar file in its cfusion/lib folder (or if running multiple instances, the [instancename]/lib folder).
About that, Matthew, note first that Adobe DID updat that jar, with update 13. If you were to compare the jars before and after (jars are just zips) you would see that they removed the vulnerable jmsappender.class and some others, as has bene recommended by the log4j project and community abotu the log4j 1.x vulnerability.
The problem is that too many scanners are looking ONLY at the NAME of the jar, not what is IN the jar. That's borderline criminal, really, because any bad guy (or software) could name the jars anything they want. A better scanner WOULD go that extra step and look IN any jar files to see IF they have known vulnerable class file names (that's still a "filename check", but at least it's not just a surface one).
Anyway, folks like Matthew are in a pickle because "they have what they have" and need to "do what they tools says to do". But to be clear, Matthew, no, that jar is NOT something you can replace. In fact, the update 13 DID implenent a log4j 2.16 jar, and then the technote from Adobe earlier this week now allows you to copy in log4j 2.17 jars (over the 3 log4j 2.16 jars)--and the technote even offers a zip with the files.
But after doing that, one STILL will have the log4j-1.2.15.jar. And you can't "just delete that" jar. If you do, CF will start but CF pages (and the CF admin) won't run. They rely on something in that jar (even though it CAN'T be any of the vulnerable bits as Adobe has removed those as of update 13). As I shared just now in the much larger forum thread here on log4j, one COULD rename that file. Java (and therefore CF) really don't care about the name of the file. But I realize that's not a satisfying solution.
But Matthew, I have offered for now what I understand to be the situation about that log4j-1.2.15.jar.
Now, about the log4j-1.2.17.jar, which is in that jetty lib that Matthew mentions (in both CF2018 and 2021 even after the updates of Dec 17), that is dismaying to notice. I see now that it was raised back on Dec 13 by FishDev, but it was NOT addressed in the update on Dec 17, nor have I seen it discussed in the technotes they've released before or since. (Well, one of them talks about removing vulnerable libraries from "3rd party applications", but technically the jetty embedded within CF is not a "3rd party" app.)
Anyway, I just want ahead and raised the question/concern, directing it to Adobe, as a new reply in that longer thread. Matthew, you may want to follow that aspect of the discussion there.
Until then, again you COULD do that removal of the vulnerable classes (by extracting the jar as a zip, removing the classes, and re-compressing the jar, as discussed in the technote). But really, Adobe should be fixing this for us, perhaps as a new technote with a new jar offered with those removed for us. That's what I've requested in that other thread.
AdChoices