The neat thing about the log4j thing was even a cursory explanation of the vulnerability made anyone with a passing familiarity with security say, "Why the fuck would that even be a feature?!"
Basically it involved parsing JNDI stuff which involved grabbing remote code (but that was a niche feature of JNDI in the Dev's defense). Basically, you may think it is just something like variable substitution but can involve much crazier stuff.
Edit: and for more context, JNDI is typically a thing for getting a database connection stored on the application server. The idea being you just ask for "customer database" and don't have to define the connection in the code. The server has it defined elsewhere. So in each environment it works the same. Basically glorified and standardized config file type of thing.
As a non-java company developer at the time, I think our biggest challenge was explaining to everyone that Log4j didn't affect us. It took a non-zero amount of effort because a lot of customers panicked. To be fair, it was also an industry where confidentiality is important.
Lol, yeah for us we didn't own any of the code that used it but depended on server software made internally that did. At the time we managed our own hosts, so it was a long week of deployments.
Oh man. I missed it by like a month. I graduated with my bachelors in December, and started in January. I was hearing horror stories from my new coworkers about how people had to cancel vacations to get stuff patched asap
That one was so annoying because you had to be using the log server to have any issues. If your network was locked down, the log server was disabled, or if you happened to be using a version that was from before the log server was added, then there were no issues. But clients just heard "log4j" and thought it was unsafe.