I see no reason to assume that configuration would be the only (or dominant) source of unchecked interpolation inputs. Might be a common use case, but certainly

I see no reason to assume that configuration would be the only (or dominant) source of unchecked interpolation inputs. Might be a common use case, but certainly not exclusive. The big issue is that many projects, perhaps deep in the transitive dependency stack, use the library, likely just for some trivial missing convenience methods on the standard lib String (and in the StringUtils of commons-lang/lang3), and once it's on the classpath it will get used by every intern who ever committed something to the code. Most dependors will likely not use interpolation at all so the impact is much lower than in the log4j incident, but a lot of things will need to be checked and/or updated. Commons text is much less ubiquitous than commons lang, but that might just put it in the perfect position for a sneaky transitive presence. According to the sentence before the of about untrusted configurations, "untrusted" configuration includes the default: unless your configuration is explicitly hardened, any call to the string interpolator with unsanitized content is an open door. (the open question is wether calls to the string interpolator exist)