> It wasn't even a problem with the most popular logging framework at the time.

I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.

Was it actually though? I worked at an MSP at the time and our tools were just flagging the mere existence of the library. It either wasn't being used or wasn't exposed in any meaningful way. Oh a dev happens to have it installed on his laptop? Who cares.

	▲	kgeist 2 hours ago \| parent [-]
		I remember our infosec person instructing us to verify we don't use log4j in our system written in PHP. Well, we didn't :)

▲

bunderbunder 3 hours ago | parent | prev [-]

My employer at the time didn’t use log4j, but we were still plenty vulnerable. All sorts of open source packages we used had a transitive dependency on it.

	▲	stickfigure an hour ago \| parent [-]
		Very few opensource packages actually used log4j directly. Libraries generally use some sort of shim like commons-logging or slf4j so they can log into whatever your application chooses as a long sink. Merely declaring a transitive dependency didn't mean that the code was executing nor did it mean that user input was actually being logged through those libraries. Log4j v2 (the vulnerable version) just wasn't that common at the time. Most everyone had moved on to Logback, and Log4j v1 (not vulnerable) was still more popular than v2.