Every so often a vendor decides the smart move is to fix a vulnerability quietly. No advisory, no CVE, no explanation, just the vaguest handwave in a changelog. The logic sounds reasonable on its face: if you don’t explain what a patch does, you avoid handing attackers a roadmap to the root cause. Why publicize your bugs?
Here’s why: patches aren’t secrets once they ship. A vendor can skip the CVE, skip the advisory, skip the outreach, but the binary still changes on disk, and anyone with a debugger and a disassembler can diff old and new and figure out what moved. That’s not a hypothetical skill, and lately, the barrier to entry into sophisticated exploit dev just got a lot lower thanks to our LLM friends.
Silent patches do not keep vulnerabilities secret. They just keep the details secret from everyone except the people already capable of weaponizing them. Consider who that leaves out. Penetration testers, who you’re paying to demonstrate risk and threats. Vulnerability management and detection engineers building signatures into products you buy for protection. Journalists, academics, and policymakers trying to explain risk to important decision makers. Most importantly, the IT administrators triaging a nearly endless mountain of patches who need some signal for severity and exploitability to decide what gets applied tonight and what waits for the next maintenance window. Almost none of these people are reverse engineering your binary to find out if they should care. They have limited time and attention.
Let’s flip the original justification around. Silent patching does not limit knowledge of a vulnerability to a small pool of people. It limits disclosed truth to a small pool of people specifically motivated to reverse-engineer your product, which, in practice, skews toward the attackers with the skill and incentive to do it. Everyone trying to defend your users is left behind, triaging with incomplete data. As a bonus, that includes your own future product engineers, who might reintroduce the same bug because everyone kept it secret the first time around.
Where a delay is actually defensible
I’ll concede a case for something short of full, instant disclosure, but it’s narrower than most vendors want it to be. Say your product is hosted, SaaS-delivered, and the user has essentially no patching decision to make. No downtime to schedule, no changelog to consult. A brief embargo while you patch your own fleet isn’t hiding anything meaningful, it’s an operational detail. The same goes for products with small, tightly controlled userbases where auto-update means nearly everyone is patched within hours regardless of announcement timing. In both cases, the IT administrator triaging a patch queue hardly matters; they’re getting patched for free, so withholding details for a few days to a couple weeks isn’t putting customers at much risk.