Vulnerability researcher here.

It's really hard for vulnerabilities as simple as this one to stay under wraps. When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on December 6th/7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter.

The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2]

The same thing happens even with embargoes like the one you describe in place.

[1] https://github.com/apache/logging-log4j2/commit/d82b47c [2] https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome...

Embargoes have a pretty terrible track record going all the way back into the mid-1990s. They were a bad idea before reverse engineering patches became de rigueur; they're a much worse idea now that exploit developers are heavily tooled up to analyze patches. As soon as you publish a fix for a vulnerability, you've effectively published the vulnerability.

The number of consumers of Log4j would mean that theres not much difference, if any, between the partial disclosure and full public disclosure. Plus, whats to stop one of the partial disclosure recipients just leaking it to the rest of the world anyway?

Not a ton of benefit here, because drawing attention without having the patch fully ready means more eyeballs looking. More eyeballs means someone inevitably finds and exploits/publishes before it can be mitigated.

How do you decide who to trust? Those same sysadmins in the loop could exploit it on deployments at companies out of the loop.

If that happens, it might even be construed as a criminal conspiracy.

It's a bad idea because that would leak, and then you'd have bad actors exploiting a zero-day prior to day zero.