The Silent Patch Problem: Why Patched Isn't Disclosed

A silent patch is a fix for a security flaw that ships without a CVE, without a published advisory, and without notice to the person who reported it. To a defender, a silent patch is indistinguishable from no fix at all: you cannot cite it, verify it, or tell whether the version you are running contains it. A complete disclosure is not just merged code. It is a patched build with a named version, a CVE identifier, a published advisory, notification to the reporter, and public credit. Skip those and “patched” is a private claim, not a security outcome.

Most vulnerability disclosure programs (VDPs) treat the merged pull request as the finish line. It is the halfway point. The report-and-reward half, intake, triage, reward, gets all the attention and all the tooling. The fix-and-disclose half, the part that starts after the code is fixed, is where diligent programs quietly fail. This is that story, told through the cleanest recent example of it going wrong.

The Cursor fix nobody could verify

In July 2026, coverage of a Cursor vulnerability split on a question that should never be ambiguous: was it patched or not?

Here is what happened. On December 15, 2025, AI security firm Mindgard reported a Windows code-execution flaw in the Cursor IDE to [email protected]. The mechanism is nasty in its simplicity: a malicious git.exe planted in the root of a cloned repository gets auto-executed the moment the project is opened. Cursor runs git rev-parse --show-toplevel, and because the Windows search order checks the working directory before system paths, the attacker’s binary runs instead of the real Git, at the developer’s privileges, with no prompt. Mindgard confirmed it vulnerable through Cursor 3.2.16, tested April 30, 2026.

Then the report went quiet. Per Mindgard’s timeline, update requests in February, March, and April 2026 went unanswered. On June 1, 2026, Mindgard signaled it would publish. It did so on July 14, 2026, a full technical write-up, 213 days after the initial report.

Only then did a Cursor spokesperson tell Dark Reading the company had “addressed the issue on July 13, 2026” and would contact Mindgard. But that claimed fix named no patched version, shipped no published advisory, and carried no CVE. The Hacker News reviewed Cursor’s published security advisories and found no entry for the issue as of July 15. Cursor 3.11 had shipped on July 10, before the claimed July 13 fix, so the last public build anyone could point to did not contain it.

That is why serious outlets reported the bug as still unpatched even after the vendor said it was fixed. Both things were “true” because the fix existed only as an unverifiable assertion. A patch nobody can cite, confirm, or attribute to a version is, operationally, not a patch. That contradiction is the entire lesson.

What is a silent patch?

A silent patch is a fix that closes a security-relevant flaw but is never framed as security: no CVE, often no advisory, sometimes buried inside an unrelated release. The code changes; the world is never told what it changed or why. A complete disclosure, by contrast, has five parts:

1. A patched build with a named version. “Fixed in 3.12.0,” not “fixed.”
2. A CVE identifier, so the flaw has a stable, searchable name.
3. A published advisory describing the vulnerability, affected versions, and mitigation.
4. Notification to the reporter that the fix shipped.
5. Public credit to the researcher who found it.

Miss any of these and users cannot answer the only question that matters to them: am I safe, and in which version?

Why vendors do it, innocent reasons and self-interested ones

The reasons range across a spectrum. At the innocent end: a maintainer never realized a bug had a security dimension, or a tiny team has no process to request a CVE and write an advisory. At the self-interested end: reluctance to publicly admit the flaw existed, fear of the optics, or a hope that quietly fixing it makes the problem disappear.

The intent does not change the outcome. Whether the silence comes from an overwhelmed maintainer or a nervous PR team, the defender downstream gets the same thing: a fix they cannot see.

Why a silent patch helps attackers, not you

A silent patch does not protect users. It hands attackers an advantage over them. This is the counterintuitive part, and it is worth stating plainly.

As Rapid7’s Tod Beardsley put it, “when you silently patch, you are communicating vulnerability details, exclusively, to skilled, criminal attackers.” Here is the asymmetry. When a fix lands in a public codebase, motivated attackers diff the patched and unpatched builds, reconstruct the flaw from the change, and weaponize it, often within days. That work is well within the reach of any competent adversary reading commit history with intent.

Defenders do not do this. They do not reverse-engineer every quiet commit in every dependency. They rely on advisories to tell them what changed and whether it matters. So a silent patch draws a bright line: the flaw becomes fully visible to the small population willing to hunt for it, and stays invisible to the large population that would have patched if only someone had told them. The people who update on schedule, who read advisories, who do everything right, are precisely the ones left exposed, while the attackers are the ones “notified.”

Silence does not buy security through obscurity. It buys the attacker a head start.

The half of the lifecycle everyone forgets

Most teams model the disclosure lifecycle as: report → triage → fix. The complete model has three more steps welded to the end: → CVE → advisory → notify. That tail is not a courtesy. Standards codify it.

ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling) define the vendor’s obligations, and a published advisory is explicitly one of them: a description of the vulnerability, the affected versions, and the mitigation, ideally in the machine-readable CSAF 2.0 format so scanners and downstream teams can consume it automatically. In coordinated disclosure, the advisory publishes alongside or shortly after the fix. Never is not an option the standard contemplates.

There are also clocks, and they measure the whole path to public disclosure, not just the merge:

These are the industry’s accepted fairness windows. Judged against any of them, a report acknowledged in December and still lacking an advisory or CVE the following July is not “in progress.” It is late by every published benchmark that exists.

A CVE is not optional, and vendors assign their own

The most common excuse for a missing CVE, that assigning one is hard or gatekept, does not survive contact with how the system actually works. CVE IDs are assigned by CVE Numbering Authorities (CNAs), and many vendors are their own CNA. Where a vendor is not, third-party CNAs, CERTs, and platforms like HackerOne can assign on their behalf. Being a vendor is no barrier to getting a CVE; it is often the easiest path to one.

Cursor’s own record proves the point. Other 2026 Cursor vulnerabilities did get CVEs and advisories, Check Point’s MCP-trust-bypass RCE, Cato Networks’ “DuneSlide” zero-click prompt-injection RCEs, and OS-level RCE flaws covered by SecurityWeek. The machinery existed and worked. It simply was never pointed at the git.exe report. That makes the silence a process gap, not a capability gap, a choice about which reports get the full treatment and which get quietly dropped.

“Patched but undisclosed” is an SLA breach, not a closed ticket

Here is the reframe that changes how you run a program. Most VDPs have a terminal status that means “we fixed it”: resolved, fix_verified, closed, paid. A report reaches it the moment the patch merges, and the ticket disappears from the board.

That status is a lie of omission. A report that is fixed but has no CVE, no advisory, and no researcher notification is not done. It is in breach, of the researcher’s work, of the users’ right to know they are exposed, and of the standards that define what disclosure means. The Cursor report was, in the vendor’s own telling, “addressed” on July 13. It was also, simultaneously, in breach on all three counts. Both were true because “addressed” and “disclosed” are different states, and only one of them was tracked.

The blast radius makes the cost concrete. Cursor has more than 1 million daily active users, more than 1 million paying subscribers, and 50,000-plus companies using it. Every one of them spent the disclosure gap unable to answer “am I safe, and in which version?” because the answer was never published. A silent patch scales its harm to the size of the user base it silences.

Treat “patched but undisclosed” the way you already treat a missed acknowledgment SLA: as a breach that lights up red, not a ticket that quietly closes.

A buildable disclosure checklist

The white space no incident coverage fills is the operational one: how do you make a silent patch impossible to file as done in your own program? Here is the checklist. It is deliberately buildable on the same rails that already track intake and triage.

1. Add a disclosed terminal status. A report is not finished at fix_verified; it must pass through disclosed. Make it gate closure the same way resolved does today. No disclosure, no done.
2. Trigger a CVE request on fix_verified. The transition into “fixed” should automatically prompt or open a CVE request, to your vendor CNA or a third-party CNA, and store the assigned ID on the report. No ID, no closure.
3. Attach an advisory template and publication step. Reuse your public security policy surface to publish an advisory, affected versions, mitigation, and credit, shaped for CSAF so machines can read it. The template turns “write an advisory” from a blank page into a form.
4. Put a disclosure clock on it. Add a disclosure SLA, “advisory published within N days of fix_verified”, and route it through the same at-risk and breached machinery you already use for acknowledgment. Past N days becomes a breach on the board, paged to on-call, not an invisible closed ticket.
5. Bundle credit and notification. Tie the advisory’s researcher credit to your hall-of-fame and reputation path, and fire a “your report is now public” message through your existing researcher-comms ledger. The loop closes with the person who opened it.

Run that, and a report physically cannot reach “done” while it is a silent patch. The status board enforces disclosure the way it already enforces triage.

How Kit keeps a silent patch off the board

Kit’s CSIRT vertical already runs the report-and-reward half of a VDP on SLA rails, and that is exactly the substrate the disclosure half needs. To be clear about what is shipped versus what this article is proposing: the acknowledgment and per-severity resolution SLAs, the at-risk and breached status machinery, on-call escalation, auditable status transitions, downstream compliance sync, and the hall-of-fame credit path are all live features. Kit had nothing to do with the Cursor bug, and no tool prevents a vendor from writing bad code.

What Kit’s architecture does provide is the substrate that makes a silent patch structurally hard to hide:

• SLA clocks with at-risk and breached states, already applied to acknowledgment and per-severity resolution targets. The same clock mechanism is what a disclosure SLA runs on: “advisory published within N days” flows through the identical breached path.
• On-call escalation so a slipping clock pages a human instead of aging silently, the difference between the Cursor report sitting unanswered for months and a breach that surfaces.
• Auditable status transitions per report, so adding a disclosed state that gates closure is an extension of the existing lifecycle, not a new system.
• Downstream compliance sync and a hall-of-fame credit path, so an advisory’s researcher credit and the “you’re now public” notification ride rails that already exist.

A silent patch is, structurally, an SLA breach that no current tool measures. Kit already measures SLA breaches. Pointing that same discipline at disclosure is the move, and it belongs on the same board that tracks acknowledgment and triage.

The takeaway: disclosure is a status transition, not a merge

A vulnerability disclosure program is not finished when the patch ships. “Patched but undisclosed” is a breach of the report, of the researcher’s work and the users’ right to know, and it should light up red on the same board that tracks acknowledgment and triage.

The Cursor story is not a one-off scandal. It is the default failure mode of every program whose lifecycle quietly ends at “merged.” The fix is not more diligence about fixing, those teams already fix diligently. It is treating the CVE, the advisory, the notification, and the credit as required status transitions a report must pass through before it can be called done.

If you are standing up the intake side, start with how to set up a vulnerability disclosure program. For what happens when the relationship breaks before the fix, see when researchers go public and our take on bug bounty payout SLAs and fairness. And if you sell into Europe, the EU Cyber Resilience Act’s mandatory disclosure obligations turn the advisory step from best practice into law. This is the closing chapter of all of them: the report is not done until it is disclosed.