Silent Software Patches Protect Hackers, Not Users
When companies fix security flaws without telling anyone, the people paid to defend your data are flying blind. A new Broadcom programme for its Spring software framework shows exactly how that plays out.
Key points
- Silent patches, meaning security fixes shipped with no public explanation of the flaw they correct, consistently leave defenders worse off than attackers.
- Anyone with basic reverse-engineering tools can compare an old and new program file to spot what changed, and AI tools have made that skill far easier to acquire.
- Broadcom, which owns the widely used Spring Framework through its VMware/Tanzu division, announced in June 2026 a paid programme giving subscribers early access to security-only patch releases ahead of the public.
- During any window between private release and public release, well-funded criminal groups or foreign government hackers can study a flaw that most defenders don't yet know exists.
- Tod Beardsley, VP of Security Research at runZero and a former section chief at CISA (the US government's Cybersecurity and Infrastructure Security Agency), argues that full, simultaneous disclosure to everyone is almost always the right call.
When a software company quietly fixes a security flaw without announcing it, the instinct sounds reasonable. If you don't explain what the patch corrects, you deny criminals a roadmap.
It doesn't work that way.
Why does a silent patch actually help attackers?
Hiding the details only works if the patch itself reveals nothing. It doesn't. A patch changes the software's underlying code, and anyone with freely available tools can compare old and new versions to reconstruct exactly what the flaw was. That process, called patch diffing, used to require serious skill. AI tools have made it far more accessible.
The people who actually do that reverse-engineering are, in practice, the ones with the time and budget to do so: skilled criminal groups and well-resourced government hackers. Security teams at hospitals or small businesses, the people deciding which patches to apply tonight and which can wait, are reading changelog notes. When those notes say nothing, those defenders have nothing to act on.
As Beardsley put it in analysis first published by SecurityWeek, a silent patch doesn't limit knowledge of a vulnerability. It limits disclosed truth to the pool of people specifically motivated to reverse-engineer the product, and that skews toward attackers. Future engineers at the same vendor are also left in the dark and may reintroduce the same bug later.
What is Broadcom doing, and why does it matter?
Broadcom now owns VMware, and through VMware's Tanzu division it controls the Spring Framework, a platform underpinning countless business web applications. In June 2026, Broadcom announced that paying customers receive validated, security-only patch releases through a private "Spring Enterprise Repository" before the open-source community gets them. Our coverage on 24 August 2026 of the 91 flaws fixed in Spring noted that over 200 vulnerabilities had already been patched in the framework that year alone, which makes the size of this exposure window more than academic.
Broadcom says public CVEs (Common Vulnerabilities and Exposures, the standard numbered catalogue of known flaws) will still be issued for every supported Spring version. But the patches arrive for paying subscribers first.
That lag is the problem. The open-source Spring user base is enormous. During any gap between private and public release, anyone who can buy a subscription gets advance notice of a documented flaw in software that millions of organisations run. Beardsley's point is blunt: the main difference between a casual criminal and a nation-state attacker is budget.
| Stage | Who has the information |
|---|---|
| Broadcom patches internally | Broadcom engineers only |
| Patch released to paid subscribers | Paying customers (and anyone who buys access) |
| CVE and advisory published publicly | Everyone, including defenders |
| Open-source patch released | Full community |
When is delayed disclosure actually acceptable?
There are narrow exceptions. A company running entirely cloud-hosted software, where customers never download anything and updates happen automatically, can reasonably patch its own systems first and announce afterwards. The window is short and the customer has no decision to make. Products with tiny, tightly managed user bases where automatic updates reach nearly everyone within hours present little real risk from a brief delay.
Weeks-long delays for large ecosystems like Spring fit neither case.
Should you worry about the apps your organisation runs?
If your organisation uses Spring-based applications, ask your software vendor directly whether they subscribe to the Spring Enterprise Repository and, if so, how quickly they apply security-only releases. IT teams managing patch queues should treat any Spring update as potentially security-relevant even when release notes are vague, and should monitor Broadcom's public CVE feeds closely.
The core principle holds regardless of vendor: a patch that ships without an explanation is still a signal that something changed for a reason. The question is whether your team finds out before an attacker does.
