What Happened
Progress Software discovered a zero-day vulnerability in ShareFile Storage Zone Controllers and made an unusual decision: release patches immediately but delay the CVE publication for two weeks. The company shipped versions 5.12.5 and 6.0.2, urged customers to update, and confirmed no known breaches. The CVE identifier is reserved but unpublished.
This isn't typical. Normally, a zero-day in production leads to either immediate patch-and-publish or a coordinated disclosure with a set timeline. Progress chose a different route: patch now, disclose details later.
Timeline
Day 0: Progress identifies zero-day in Storage Zone Controllers
Day 0+hours: Emergency patches released (5.12.5 and 6.0.2)
Day 0+hours: Customer notification begins, no CVE details published
Day 0+hours: CVE identifier reserved
Day 14 (planned): Full CVE publication
The two-week gap is significant. Progress provided a patching window before attackers could access the technical details that come with a public CVE.
Which Controls Failed or Were Missing
Vulnerability Management Process
The zero-day indicates a gap in secure development practices, but the organizational decision-making process is more intriguing. Someone decided on a 14-day delay without a clear framework. Was this based on telemetry showing patch adoption rates, customer segmentation data, or just a gut feeling?
Patch Deployment Infrastructure
Progress is assuming most customers can patch within two weeks. This is a big assumption, as Storage Zone Controllers are in customer data centers, not SaaS environments. You can't force updates. You're relying on your notification reaching the right people and them having available change windows.
Incident Response Communication
Progress confirmed "no known breaches," but what about customers who don't patch by Day 14? The CVE publication becomes a countdown for attackers to reverse-engineer the vulnerability and scan for unpatched systems.
What the Standards Require
ISO/IEC 27001:2022 Control 5.24 (Information Security Incident Management Planning and Preparation)
You need documented procedures for vulnerability disclosure. Your process should define:
- Who approves disclosure timing
- What criteria trigger immediate vs. delayed publication
- How you measure patch adoption before going public
Progress's two-week delay should fit a documented policy, not an ad-hoc decision.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation)
The control requires you to "disseminate flaw remediation information to organization-defined personnel or roles." It doesn't specify timing. Your policy needs to answer: do you tell customers before or after you have a patch? Do you publish CVE details before or after reaching a patch adoption threshold?
PCI DSS v4.0.1 Requirement 6.3.1
If ShareFile processes cardholder data, you're required to "identify and address security vulnerabilities and maintain up-to-date information about security vulnerabilities." The two-week CVE delay doesn't directly violate this, but it creates a window where your vulnerability database is incomplete.
SOC 2 Type II CC7.2 (System Monitoring)
Your incident response process needs to include "communication of information about security breaches, incidents, and other matters of significance." Is a zero-day with no known exploitation significant enough to require customer notification before you have a patch? Progress said yes, but the delayed CVE means customers can't independently verify the risk.
Lessons and Action Items for Your Team
1. Document your disclosure timeline before you need it
Write down how long you'll wait between patch release and CVE publication. Base it on data: how long does it take 80% of your customers to apply critical patches? If you don't know, start measuring now. Your policy might be "we publish the CVE when patch adoption hits 75% or after 7 days, whichever comes first."
2. Build a patch adoption dashboard
You can't make informed disclosure decisions without telemetry. Track which customers are running which versions in real time. When a zero-day hits, you need to know: how many instances are vulnerable? How many have patched in the last 24 hours? 48 hours? Without this data, you're guessing.
3. Test your emergency patch process
Progress released patches within hours. Can you do that? Run a drill: simulate a zero-day in your most complex component and measure time-to-patch. Include everything: build, test, sign, publish, notify customers, track adoption. If it takes you five days, your disclosure policy needs to account for that.
4. Define "no known breaches" rigorously
Progress said no breaches occurred. What does that mean? No customer reports? No anomalies in logs? No evidence in your SIEM? Document what evidence you'd need to confidently make that claim. If you're relying on customer self-reporting, that's not evidence; it's absence of evidence.
5. Align your CVE reservation process with your disclosure policy
Progress reserved a CVE but didn't publish details. That's allowed, but it creates confusion. Security teams see a reserved CVE with no information and don't know how to prioritize it. Your policy should specify: when do we reserve the CVE (immediately? after patch release?) and when do we populate it with technical details?
6. Prepare your customers for delayed disclosure
If you're going to hold CVE details, tell customers why and give them a specific publication date. "We're delaying publication for two weeks to give you time to patch" is a reasonable message. "We'll publish when we're ready" isn't. Set expectations.
The Progress ShareFile incident tests disclosure strategy. The two-week CVE delay might protect customers or give attackers a head start. You won't know until Day 14. What you can control: having a documented process so you're not making these decisions under pressure with incomplete information.
