I mean, it's clearly a bug if you intend the feature to do one thing but it actually allows remote code exploitation. There may be a debate over whether to attribute more fault to the design (or really, the very existence) of the feature or its implementation, but either way, it boils down to a bug. And the general class of bug of format string vulnerabilities was certainly well-known in 2000, popping up with things like printf() in C and SQL injection attacks, among other places, though I agree we take a different approach to security today than we did then.

@ZachLipton The feature does EXACTLY what it was designed to do. It's disingenuous to suggest the programmer that implemented this made some sort of error.

@ZachLipton: The requested feature (essentially) was remote code execution. The idea that the developer promised one thing and delivered another is simply false.

@GregoryCurrie The idea that people using the library would log text entered by anonymous people should have been contemplated, shouldn't it? It seems to me like any person making a library like this should at least make people aware that the library can execute arbitrary code depending on what's logged with default settings... Maybe a warning like "Oh yeah, anything you write to the log can cause a lookup that can execute arbitrary code, so be careful what you log..."

... why are you mentionoing 2000? Log4j 2.0-alpha1 was released on 2012 , sure it's quite a few years ago but it is closer to us than to 2000 and it was also after the advent of big social media, AWS etc. IMHO the real bug here is that the substitution was done also on user provided parameters while it should have been allowed only on the template. This would be the same as SQL prepared statements which prevent SQL injection: you trust the query template but not the parameters. I don't know why with logging they decided it shouldn't be this way... we already knew it was bad with SQL...

@JasonGoemaat Of course it should have been contemplated that a log line would contain a mix of system supplied and user supplied data. I would argue that even with big bold warnings everywhere, the feature is still horribly dangerous. The idea that you can download and run arbitrary code if the log line contains a certain sequence of characters is absolutely bonkers.

@GACy20 I absolutely agree with you that any developer worth their salt should absolutely know about this problem, because this type of defect is very well understood. In some ways, the fact that developer delivered exactly what they intended to do is incredibly worrying. The developer in question is now "CloudBees' senior security engineer", so make of that what you will.

Also, code must be modified to trigger this (as it needs to be in the logging format string, not the logged data). If you can alter code on a system, you can also execute remote code.

@ThorbjørnRavnAndersen the full stupidity is that unlike SQL injection, this can be triggered by parameter strings. No need to modify code.

@ojs Parameter strings? Thought it had to be in the logger format string, not the parameters substituted.

@ThorbjørnRavnAndersen No. Log4shell is exploitable through the contents of the log message. Not the format string, the message content. See e.g. here: "In order to exploit this flaw you need: 1) A remotely accessible endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send arbitrary data, 2) A log statement in the endpoint that logs the attacker controlled data." That's it. And that's why this is such a big deal; exploitation is trivial.