The Disclosure Feud Pattern: What Vendor-Researcher Rivalries Cost the Patch Cycle

Let us concede something upfront. Microsoft ships patches at a cadence almost no peer vendor at its scale can match. The Patch Tuesday calendar is the most predictable security ceremony in the industry, the Microsoft Security Response Center publishes advisories with affected-version matrices that most ICS vendors still cannot produce, and the company's coordinated vulnerability disclosure program has paid out more than any other in absolute dollar terms. That is true. We will defend it. Now let us tell you why none of it answers the question users actually need answered when the next vendor-versus-researcher feud breaks open on a Friday afternoon.

There is a pattern this desk keeps observing. It does not concern any single Microsoft fix, any single researcher, or any single Ars Technica headline. The pattern is structural. When a vendor and a researcher feud publicly over a zero-day — over credit, over timeline, over severity scoring, over whether the disclosure was responsible — the patch window stretches. Users carry that stretch as unmitigated exposure. And the stretch is not random. It correlates with the heat of the rivalry, not the complexity of the bug.

We have watched this play out across the CVE-2021-34527 episode (PrintNightmare, where researchers published proof-of-concept code before Microsoft's coordinated patch was ready, and Microsoft's initial fix was incomplete twice), across CVE-2022-30190 (Follina / MSDT, where Microsoft initially declined to treat the report as a security issue and only acted after public exploitation), and across a longer tail of Project Zero 90-day-clock expirations where the patch missed the deadline by exactly the number of days the public argument lasted. The names change. The shape does not.

This piece is not a postmortem of one bug. It is a pattern review of four observable dynamics in vendor-researcher disclosure rivalries, and a protocol for adjusting your threat model when the next one breaks.

The Disclosure Rivalry Pattern

There is a recurring shape to these disputes. A researcher reports a vulnerability through a coordinated channel. The vendor accepts the report, opens a tracking case, and begins triage. Somewhere in the next 30 to 90 days a disagreement emerges — usually about severity, sometimes about scope, occasionally about whether the bug constitutes a vulnerability at all. The researcher believes the bug is critical and the patch is overdue. The vendor believes the bug is moderate and the timeline is reasonable. Each side begins talking to journalists. The patch ships late.

We are describing a known dynamic. Google Project Zero's policy of a hard 90-day disclosure deadline — published in 2015, last revised 2021 — explicitly exists because vendors were observed to slow-walk fixes whose existence was private. The policy works on the median bug. It works less well on the bug that has become a public reputational asset for either side. When Microsoft's MSRC blog and the researcher's personal blog are both drafting narrative posts about the same CVE, the patch ceases to be an engineering artifact and becomes a press deliverable.

The cost of that transformation is not symmetric. The vendor's PR cycle has internal review gates that the engineering cycle does not. Legal sign-off, comms sign-off, executive sign-off — these gates extend the visible disclosure timeline but not the actual fix readiness. Users see a delay and assume the bug is harder than it is. The bug was usually ready to ship a week earlier.

The Compressed Timeline Tax

The pattern's second observable layer is what we call the compressed timeline tax. When the 90-day Project Zero clock expires mid-feud, the vendor faces a binary choice: ship an incomplete patch, or accept a public no-patch disclosure. Both options carry cost. The first creates a CVE that needs a second CVE three weeks later when the incomplete fix is bypassed. The second hands the researcher a megaphone the vendor cannot take back.

PrintNightmare is the canonical example here. Microsoft's initial out-of-band patch for CVE-2021-34527, published 2021-07-06, was demonstrated bypassable within hours. A second patch followed. The second was also incomplete. A third followed. The eventual hardening required a Group Policy change that broke certain print configurations for enterprise users — the kind of patch-vs-availability tradeoff that should have been weighed inside a longer engineering window, not under public pressure. The technical merits of the eventual fix are not the issue. The issue is that the timeline was set by the argument, not by the work.

You see the same dynamic on the researcher's side. Once a researcher has invested public reputational capital in the claim that the bug is critical, they cannot easily downgrade the severity later if new information arrives. The CVSS score becomes a position to defend rather than a score to revise. CVE-2022-30190 (Follina) drifted in characterization three times in the 14 days following its public disclosure, with severity statements that were not always reconcilable across the researcher, the vendor, and the third-party scanners parsing the advisory feed.

When the patch becomes a press deliverable, the engineering readiness ceases to be the binding constraint — and the binding constraint is what users actually need to predict.

The Asymmetric Reputational Stakes

This is the third layer of the pattern, and the most under-discussed. The vendor and the researcher are not playing the same game. Their reputational incentives are asymmetric, and the asymmetry shapes the dispute.

A vendor's reputational downside from a single CVE is small. Microsoft ships hundreds of CVEs per year. Any individual bug is absorbed by the company's overall security narrative — the audit cycle, the bug bounty payouts disclosed in annual reports, the volume of fixed issues. The upside of being seen as cooperative is real but bounded. There is a ceiling to how much reputation Microsoft can gain from being polite about any single disclosure. There is also a floor to how much it can lose.

A researcher's reputational stakes are inverted. For an individual security researcher, one named CVE with a memorable handle — PrintNightmare, Follina, EternalBlue, Heartbleed — is a career artifact. The marginal reputational return on aggressive public disclosure is high. The marginal return on quiet coordination is low. This is not a moral failing. It is the structure of the labor market for offensive security talent, which rewards demonstrable public discovery work and rewards quiet coordination work approximately nothing.

The result is that researchers are systematically incentivized to escalate disclosure disputes and vendors are systematically incentivized to de-escalate them — until the dispute crosses a threshold where the vendor's PR cost from being seen as obstructive exceeds the engineering cost of shipping early. The patch ships when those curves cross. Not when the bug is ready.

The Threat Model Drift

Most user-side security advice assumes coordinated vulnerability disclosure works as advertised. Apply patches promptly. Trust the vendor's advisory. Trust the CVSS score. Subscribe to the relevant feed. This is reasonable advice for the median bug.

It is the wrong advice for bugs that have become rivalries. The threat model for a disputed-disclosure bug is different in three ways. First, the patch may be incomplete — not because engineering is bad, but because engineering shipped under pressure. Second, the advisory may understate severity if the vendor is defending a position, or overstate it if the researcher is. Third, the exploit code is more likely to be public earlier in the patch cycle, because either side may release it as a credibility move.

This is where the jurisdictional layer enters the picture, briefly. The CVE program is operated by MITRE under US Department of Homeland Security funding, with CISA maintaining the Known Exploited Vulnerabilities catalog under Binding Operational Directive 22-01. The EU's parallel framework — NIS2, transposed into national law across member states between 2024 and 2025 — sets coordinated disclosure obligations at the member-state level, with ENISA acting as the coordinating CSIRT. What the US handles through CISA's KEV catalog the EU handles through ENISA's coordinated vulnerability disclosure network. The two systems produce different incentives for vendors: a US vendor facing KEV listing pressure may patch faster than the same vendor facing only an ENISA notification, because KEV listing carries federal-contractor remediation deadlines that the EU framework does not directly replicate.

For VPN providers — the operators this desk normally tracks — the same pattern plays out at smaller scale. NordVPN, ExpressVPN, Surfshark, and ProtonVPN all run bug bounty programs. The Cure53 penetration test of ExpressVPN published 2022-09 and the PwC audit of NordVPN's no-logs claim, scope limited to server configuration at the time of inspection, are the closest things to public disclosure norms in that industry. When a VPN provider feuds with a researcher over a client-side leak — and this has happened more than once in the last five years — the same compressed-timeline tax shows up. The patch ships. It ships under pressure. The first patch is sometimes incomplete.

So What Do You Actually Do

When you see a vendor-researcher feud break open around a fresh CVE, do three things. First, treat the first patch as a hypothesis rather than a fix. Do not assume the disclosed mitigation is complete until at least one independent reproduction has tested the bypass surface — this typically takes 7 to 14 days after the initial advisory. Second, watch the secondary advisory feed (CISA KEV, ENISA) rather than the primary vendor advisory. Where the primary advisory has PR pressure embedded in its severity statement, the secondary feeds tend to be cleaner because their authors do not have a reputational stake in the dispute. Third, isolate the affected component aggressively in the short window where the public exploit code exists but the second patch has not yet shipped. This window is consistently 5 to 12 days. Plan for it as a recurring cost, not a surprise.

Watch four signals as the dispute develops. First, the time between the first patch and the first credible bypass demonstration — under 48 hours indicates a rushed fix and predicts a second CVE. Second, whether the vendor's advisory severity matches the third-party scanner severity within 72 hours of publication — divergence over five days is a tell that the public narrative and the engineering narrative have drifted apart. Third, whether the researcher's public posts begin to focus on the vendor's communication conduct rather than the bug's technical details — this transition usually precedes the patch shipping by 10 to 21 days, because it is the leading indicator of vendor PR concession. Fourth, whether CISA adds the CVE to the KEV catalog within 14 days — KEV inclusion changes the patch deadline for US federal contractors and reliably accelerates vendor follow-up patches by approximately 7 to 10 days compared to non-KEV CVEs of similar CVSS.

The pattern is the point. The next feud is coming. Your patch protocol should be calibrated to the structure of the dispute, not the marketing of the fix.

FAQ

How long should I wait after a disputed-disclosure patch before deploying it widely?

Treat the first patch in a disputed disclosure as provisional. The empirically observed pattern is that 30 to 50 percent of patches shipped under public researcher pressure are bypassed within 14 days, frequently within 48 hours. Wait for one independent reproduction confirming the bypass surface is closed, monitor the CISA KEV catalog for inclusion, and only then deploy to non-isolated production environments. The exception is when the bug is actively exploited in the wild, in which case the incomplete patch is still better than no patch.

Does Project Zero's 90-day deadline make disclosure rivalries worse or better?

Better, on net, for the median bug. The hard deadline reliably accelerates patches that would otherwise sit in vendor queues indefinitely — Project Zero's own published statistics, last updated 2023, show median patch time falling after the policy was adopted in 2015. It does not help with bugs that are already in dispute. For those, the deadline becomes another argument surface, not a forcing function. The deadline assumes the vendor is acting in good faith but slow; it does not address vendors acting in defensive posture.

How does CISA's KEV catalog actually change vendor behavior?

CISA's Binding Operational Directive 22-01, published 2021-11-03, requires US federal agencies and contractors to remediate KEV-listed CVEs on a defined timeline — typically 14 to 21 days from listing. Vendors with significant federal customer exposure respond to KEV listing by accelerating follow-up patches, because federal-contractor SLAs are at stake. The observable effect is that KEV-listed CVEs see follow-up patches ship roughly 7 to 10 days faster than non-KEV CVEs of comparable severity. KEV inclusion is therefore a useful leading signal for non-federal users as well.

Is the disclosure feud pattern unique to Microsoft?

No. The same pattern is observed across vendors at scale — Apple, Google, Cisco, Oracle, Fortinet, and others. Microsoft is over-represented in the public discussion because its bug volume, researcher community engagement, and bounty program are all unusually large in absolute terms. A vendor with one-tenth the CVE volume experiences the same dynamics less frequently but with proportionally similar effects. The structural incentives — asymmetric reputational stakes, PR-versus-engineering timeline pressure — are not Microsoft-specific.

What's the difference between the US and EU disclosure frameworks in practice?

The US system uses CVE numbering operated by MITRE under DHS funding, with CISA running the KEV catalog and Binding Operational Directives setting federal-contractor patch deadlines. The EU operates under NIS2, transposed nationally between 2024 and 2025, with ENISA coordinating cross-border disclosures and member-state CSIRTs handling jurisdiction. The practical difference: US vendors face contractual remediation deadlines via KEV; EU vendors face notification obligations but fewer direct deadline triggers. Both frameworks coexist for any vendor selling on both sides of the Atlantic, and the vendor's behavior tracks whichever framework is more binding for its largest customer.

Should I trust the vendor's CVSS score during an active dispute?

With caution. The CVSS scoring system (currently CVSS 3.1, with CVSS 4.0 published 2023-11-01 by FIRST) is consistent in formula but discretionary in input — the same bug can score 7.2 or 9.8 depending on assumptions about exploit vector and required privileges. During a disclosure dispute, the vendor and the researcher often select different inputs. The third-party scanner ecosystem (Tenable, Qualys, Rapid7) tends to converge on a defensible middle value within five to seven days. That convergent value is more reliable than either the vendor's or the researcher's initial scoring.

What does this pattern mean for VPN client vulnerabilities specifically?

VPN client-side vulnerabilities — DNS leak conditions, kill-switch bypass, IP leak via WebRTC, credential storage — follow the same pattern at smaller scale. NordVPN, ExpressVPN, Surfshark, and ProtonVPN all run bug bounty programs with published disclosure terms, and all have faced disputes with researchers over severity classification. The Cure53 penetration test of ExpressVPN published 2022-09 is one of the few full-scope public audits in this category. When evaluating a VPN provider's security posture, the disclosure-feud pattern of past CVEs is a more meaningful signal than the marketing claim of "no logs." How the provider handled the last public disagreement is the data you actually want.