Coordinated, Until It Isn't

A few weeks ago an independent researcher named Jakob Wolffhechel — operating as Moksha — published 89 vulnerabilities in XAPI, the management stack underneath Citrix XenServer and XCP-ng. He published all 89 on the same day, with no embargo, with detection content released openly to anyone with operational responsibility, and with the corresponding nineteen patches deliberately withheld from Citrix.

The first wave of reactions has been the predictable two camps: finally, somebody pushed back, and this is irresponsible, full stop. Both takes are bad, in opposite directions, for the same reason. They treat Moksha's decision as a single thing — one binary call that you either applaud or condemn — when it is in fact at least four separate decisions, each with its own equity calculation. If you're going to have an opinion on this, you have to do the decomposition.

I want to do that decomposition here. Not because I think Moksha needs a defender, and not because I think the next bad-faith vendor needs another stick, but because the conditions that produced this disclosure are not unique to XAPI, are not unique to Citrix, and are not getting better.

The asymmetry at the heart of disclosure

I've been thinking about this problem for more than a decade and the part of the conversation that almost never gets said plainly is this: the researcher is the only party in the room who can actually be punished.

The vendor cannot, in practice, be sued by the researcher (before the lawyers freak out here, yes - A researcher absolutely can sue a vendor, but as anyone who has been involved in litigation will quickly tell you, lawsuits almost always turn into a war of attrition, and the deepest pockets using last the longest). The vendor cannot be arrested by the researcher. The vendor cannot have a CVE assigned against its will, because in many cases the vendor is the CNA for its own products. The vendor cannot be doxed, fired, deported, or bankrupted by the researcher. The researcher can experience all of those things at the vendor's hands, or at the hands of a regulator the vendor is aligned with, or at the hands of a customer who has been told the researcher is the problem.

This is not a moral claim about who is good and who is bad. It is a structural claim about where the leverage sits. Coordinated disclosure as we currently practice it is a system in which one party carries almost all the legal risk, all the reputational risk, all the time cost, and all the silencing pressure, and the other party carries effectively none until they decide to actually engage with the vulnerability submission itself. That system runs, when it runs at all, on researcher goodwill. Researchers absorbing risk that vendors don't, in exchange for what is supposed to be a fair process, is the substrate underneath every disclosure norm we have.

When the fair process stops being fair, the goodwill runs out. That is the thing that is happening here. It is also the thing that is happening across our field, slowly, in dozens of places at once, with every researcher who quietly decides this isn't worth it anymore and walks away from a finding without ever telling anyone they had it. Moksha is conspicuous because he is loud. The much larger phenomenon is silent.

Citrix is not unique here, by the way. Citrix is typical. The bounty exclusion of XenServer, the downgrading of CVE-2024-8068 and CVE-2024-8069 against public technical pushback, the structural conflict of interest of acting as your own CNA — those are documented behaviors, but they are not exotic ones. There are at least a dozen vendors I could list with similar records, and I suspect anyone who has done much vendor-side disclosure work could double the list.

That's the frame. Now the four decisions.

The four decisions inside one decision

Moksha's "drop" is actually four choices stacked on top of each other:

1. Going public at all
2. Going public with no embargo period
3. Refusing to share patches with Citrix specifically
4. The "shittrix" branding around the whole thing

Each of these has a different defensibility, a different set of beneficiaries, a different set of costs, and a different precedent. If you collapse them into a single yes-or-no, you get a hot take. If you keep them separate, you can actually think about what happened.

Decision one: going public

This one is easy. Going public after vendor channels have demonstrably failed is not an aberration; it is the safety valve that makes the rest of the system work. It has twenty-five years of established precedent, it is recognized by every credible disclosure norms document including ISO/IEC 29147 and CERT/CC's policy, and the alternative — a world in which researchers who hit vendor stonewalls have no recourse — is a world in which vendor stonewalls become the dominant equilibrium. Public disclosure is what disciplines vendors who would otherwise have no incentive to ship. Take it away and the entire model collapses.

So, on the question of whether Moksha was justified in going public at all, given the vendor record he documented: yes. Not interesting. Move on.

Decision two: Day-0, no embargo

This one is contested but it sits inside the field's existing norms, even if it sits at the loud edge of them.

The case for Day-0 here is that the vendor's prior behavior — the bounty exclusion, the severity downgrades, the CNA conflict, the unanswered MITRE filings — is exactly the kind of pattern that the loud edge of the norm exists to address. If a vendor demonstrates that it will use embargo time to minimize the severity of the disclosure, then giving the vendor embargo time is helping the vendor blunt the disclosure, not helping customers patch or mitigate their risk.

The case against Day-0 here is that fifteen days from MITRE filing to release is, in practice, not very long. MITRE's queue regularly runs longer than that without anything sinister happening, and a CISA pre-notification — which has been a viable escalation when a vendor's CNA is the conflicted party — does not appear to have been part of the timeline. There were paths that could have been tried.

The fifteen-day window is real and it is a weakness in Moksha's stated rationale. But Day-0, in this context, with this vendor, with this pattern, is not novel. The Overton window of disclosure norms has a published edge and a quieter edge, and what Moksha did sits within both. We can argue about whether he should have waited another month. We cannot honestly argue that what he did was outside the field's existing range of defensible response.

I land on: defensible, with a note that the timeline should have included CISA. Not the load-bearing decision. Move on.

Decision three: refusing to share patches with Citrix

This is the load-bearing one. It is also the one that is genuinely new, and the one this whole post is really about.

Moksha developed the patches. Nineteen upstream OCaml patches, roughly two hundred lines, addressing RBAC enforcement and input validation across the writable map fields that anchor the entire 89-vuln set. He kept them private. He offered them conditionally to Vates, the maintainer of XCP-ng, with the explicit constraint that they not be shared with Citrix through any coordination framework. Vates didn't respond before publication.

The argument behind this move — and Moksha articulates it directly — is that Cloud Software Group has a documented record of using patch information to minimize the severity of a disclosure. If a vendor will weaponize the patch into a low-severity CVE assignment, providing the patch to that vendor undermines the disclosure itself. The point of disclosure is to inform customers about risk. The point of withholding the patch from a vendor that will downgrade the risk in its public communications is to preserve the disclosure's signal.

I want to steelman this for a minute, because I think it deserves it. The CVE-2024-8068/8069 downgrade is not a hypothetical. It happened, it was technically wrong, and the public pushback at the time did not move the needle. CSG controls CVE assignment for Citrix products, controls the severity scoring, and controls the customer-facing communication. A researcher who hands a patch into that pipeline is handing leverage to a vendor that has already shown it will use that leverage to minimize, not maximize, customer awareness. From inside that frame, refusing to provide the patch is internally consistent with the goal of "make customers actually understand what they have running."

That's the steelman. Now the harder part.

The cost of withholding the patch falls on customers. Specifically: Citrix XenServer customers who patch through Citrix's official channel — which is most of them — now wait for a fix that the researcher has built and is deliberately preventing the vendor from shipping. Vates and XCP-ng users may eventually benefit through that channel, but Citrix XenServer customers cannot. Detection is published openly, which is the right call, but detection is not patching. Knowing your XenServer host is exploitable does not, by itself, fix it.

Customers in this scenario are bystanders. They did not stonewall the researcher. They did not downgrade the prior CVEs. They are downstream of a fight between a researcher and a vendor, and the chosen tactic in that fight has the effect of leaving them on the public-disclosure side of the line without a patch on the other side. That is a real cost, and the people who sympathize with Moksha's position should not pretend it isn't.

Here is the part that should make us all uncomfortable. Moksha's decision will be cited, and it will be cited two ways. It will be cited by the next good-faith researcher facing a vendor behavingsimilarly, as evidence that there are escalation paths beyond the broken coordinated channel — that is a legitimate use of the precedent. And it will be cited by the next bad-faith vendor making the case to roll back researcher safe-harbor protections — see, researchers can and will withhold remediation as a tactic, we need stronger protections from them — and that is a cynical use of the precedent. Both citations are predictable. We do not get to wish away the second one because we like the first one.

I land on: the most coherent argument and the most uncomfortable consequence are both present in the same decision, and they don't cancel out.

Decision four: the branding

I love a good troll as much as the next Netizen, and the "shittrix" framing is satisfying. It is also the part most likely to undercut the technical seriousness of the work in audiences that would otherwise be allies — regulators, general counsel, CISO board reporting, exactly the people who shape whether researchers get treated as a legitimate party in a future regulatory frame. Vulnerability marketing is a whole weird and wonderful world that we won't dive into here, but suffice to say that branding decisions like this one as almost always a double-edged sword.

The technical work is rigorous. Eighty-nine advisories, machine-readable JSON, CVSS scoring, root-cause grouping, semantic identifiers — this is not "spray random POCs at the vendor." It is a systematic audit of a single bug class across an object model. The branding is a separate choice, and the branding is performative. Take it or leave it. I'd leave it. But it isn't the story, and people who make it the story are letting the vendor off the hook for the underlying behaviors that produced the disclosure.

Honest cost accounting

I'm not going to pretend the math is clean.

The defenders who get detection content with no NDA are better off than they were the day before. That is real. The retro-hunt window — go look at the audit log for the last ninety days using the published patterns — is a valuable thing the disclosure enables and would not have existed under embargo.

The customers waiting for a Citrix-shipped patch are worse off than they would have been under a coordinated timeline that produced one. That is also real, and the "assume compromise has already occurred" framing — operationally correct given the sixteen-to-twenty-year exposure window — does not dissolve the marginal harm of dropping the playbook publicly on Wednesday for an attacker who didn't have it on Tuesday.

The researcher community is — depending on which researcher you ask — either better off, because the asymmetry got named, or worse off, because the next vendor will use this as ammunition. I think both of those are true at once, and the net direction depends on what we do next.

That last part is the actual question.

What would actually fix this

The asymmetry can't be patched by asking researchers to be more patient. It is structural and it needs structural fixes. For example, cryptographic disclosure commitments that don't depend on the researcher staying alive, unsued, unbankrupted, and uncoerced. Vendor accountability scoring that is actually scored, by a body that is not the vendor. CVE pipeline reform that does not let conflicted CNAs grade their own products. None of these are my ideas; people in this field have been talking about them for years, and I have a longer essay coming on the substrate of them. But the short version is: we have to stop running disclosure on goodwill that the system actively penalizes, because eventually the goodwill runs out and we get this.

What should make us uncomfortable

The thing to be uncomfortable about is not what Moksha did. It is the fact that the conditions that made his choice rational are getting more common, not less, and we have not built the infrastructure to make a different choice viable.

If the response from the field is to attack the researcher rather than attack the structure that produced the researcher's decision, we will see this disclosure pattern repeated, badly, by people with less discipline than Moksha. The next case won't be eighty-nine carefully-categorized advisories with detection released openly to defenders without NDA. It will be worse. It will be worse because the people who would have done it Moksha's way will have already concluded, watching how this one gets received, that there isn't any version of this that protects them either.

Coordinated disclosure works, when it works, because the researcher chooses it. The day it stops being a rational choice for the researcher is the day it stops working. We are not very far from that day, and the only honest response to the Moksha case is to stop pretending we are.