| > Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. They've been doing a poor job of communicating. Considering the attention this issue is getting, they should have a prominent notice on their project page[0] about it like the one Logback[1] has telling people that they are not affected. Furthermore, even their post about the issue[2] still fails to clarify many details like * are people using newer JDK versions safe, like one commenter in this very thread assumed[3] ? * does it only affect the format string and not parameters as many [falsely] claimed when the news started making the rounds ? * what should people trying to block exploitation on a firewall level look for ? > for a feature we all dislike yet needed to keep due to backward compatibility concerns. They have not recognized the security risk posed by what is effectively an expression language interacting with user-submitted data. Java projects used in server-side templating like OGNL, JSP and JSF implementations, Spring keep having security vulnerabilities with this even after 20+ years. It is an effectively impossible task to get this 100% secure. The ridicule Log4j is getting serves a purpose beyond fun: it lets people know that the project's maintainers are not up to the task and another logging library should be used instead, as there might be more issue still undiscovered or added in the future. [0] https://archive.ph/ZhjWO [1] https://archive.fo/QkzIy [2] https://archive.fo/NvjKP [3] https://archive.fo/5cNtw |
Again the risk is real when the server use un-sanitized client data.