You are clearly not involved in patching.

Simply already patched. Company sizes and number of attack surfaces vary. 22 hours is plenty of time for an input string filter on a centrally controlled endpoint and a dependency increment with the right CI pipeline.

Consider the possible ways for a string to be injected into any of the following:

  Apache Solr
  Apache Druid
  Apache Flink
  ElasticSearch
  Flume
  Apache Dubbo
  Logstash
  Kafka

If you've got any of them, they're likely exploitable too.

That list comes from: https://unit42.paloaltonetworks.com/apache-log4j-vulnerabili...

The attack surface is quite a bit larger than many realize. I recently had a conversation with a person who wasn't at a Java shop so wasn't worried... until he said "oh, wait, ElasticSearch is vulnerable too?"

You'll even see it in things like the connector between CouchBase and ElasticSearch ( https://forums.couchbase.com/t/ann-elasticsearch-connector-4... ).

Lets see...

Nope. Nope. Nope. Nope. Nope. Nope. Nope.

aaaand...

Nope. Plans for it, but not yet in production.

Oh and before anyone starts, not in transitive dependencies either. Just good old bare metal EC2 instances without vendor lock in.

Kafka is still on log4j1. It's only vulnerable if you're using a JMSAppender.

Kafka is not vulnerable for this particular exploit but hdfs kafka connect plugin is.

Unfortunately, patching vulns can't be put off for Monday.