>commit introduced from merging a user-provided patch. It went through the entire review process
As far as I understand, log4shell was effectively caused by "all features in a single jar" design. If log4j had multiple jar files, then the users could depend only on the features they use, so the impact of the CVE would be much less. At the same time, the patch of "allow jndi resolution" could land on its own jar, so it would impact a subset of the users only. Code review could catch the issue of adding too many features to the single jar. --- Here's the similar case in commons-lang: A recent CVE-2025-48924 relates to ClassUtils while commons-lang is often used for its StringUtils only. If commons-lang was modular like commons-stringutils, commons-classutils, and so on, then it would be much more secure for the end-users. Here's a question: what do you think of releasing commons-stringutils.jar with StringUtils and Strings clases only? Frankly, many projects use only StringUtils, yet they suffer from accidental CVEs in one of the classes they never use. Vladimir
