Apache Log4j 2, the most widely used Java logging library, included a feature called JNDI lookup. When a log message contained the pattern ${jndi:ldap://host/path}, Log4j would initiate an outbound LDAP request to the specified host and potentially load and execute a Java class returned by the server. This was a “feature” designed for configuration lookups — but it evaluated any string in any log message.
The implication: any value that reached a Log4j log statement and contained ${jndi:...} would trigger an outbound connection — and potentially remote code execution. The source of the value did not matter: user input, HTTP headers, database values, or third-party API responses.
Log4Shell was primarily exploited through direct user-controlled input (HTTP headers, request parameters). But the API10 variant — delivery through third-party API responses — was also a real attack path. Applications that validated and sanitized user input still logged third-party data without review. The assumption: “this data came from our geolocation provider, it’s just a city name.” That assumption is the vulnerability.