Progress Software just confirmed what ShareFile customers suspected for days: the outage that locked people out of their Storage Zones Controller wasn’t scheduled maintenance or a bad deploy. It was a zero-day, actively exploited, and the fix only shipped after the damage was already spreading. If you run a cybersecurity program built around defending your own perimeter, this is the story that should bother you, because none of it involved your perimeter at all.

The same week, four npm packages under the AsyncAPI namespace turned out to be shipping a multi-stage botnet loader. Different vector, same lesson: the software you didn’t write and the vendor you didn’t choose to audit this quarter can still hand an attacker a door into your environment. You just won’t find out until they’re already inside.

A Fix Shipped. The Outage Already Cost You Days.

Here’s the timeline that matters: Progress pulled ShareFile Storage Zones Controller access down, restored it in stages, and only now has confirmed the root cause was a genuine zero-day, not an abundance of caution. That’s days of employees unable to move files through a system your business depends on for client deliverables, contracts, or regulated data transfers.

None of that downtime shows up in your own vulnerability scans. Your patch management dashboard was green the entire time. Your firewall logs looked normal. The outage happened because a vendor’s software had a flaw, and your business absorbed the consequence anyway.

Successful exploitation of this month’s most severe Patch Tuesday flaw, a Dynamics NAV and Business Central deserialization bug, requires no authentication and no user interaction at all, according to Microsoft’s own advisory.

That quote isn’t about ShareFile. It’s from the same week’s record 622-patch release, and it’s there for a reason: the industry keeps discovering that “no interaction required” and “vendor-side” flaws are where the real exposure lives now. Your threat detection stack is tuned to catch lateral movement and suspicious logins. It was never built to catch a vendor’s internal bug before that vendor tells you about it.

Four Compromised Packages Turned Trust Into A Backdoor

The AsyncAPI incident is smaller in blast radius but more instructive. Researchers at OX Security, SafeDep, Socket, and StepSecurity all independently flagged four packages, @asyncapi/generator-helpers, @asyncapi/generator-components, @asyncapi/generator, and two versions of @asyncapi/specs, distributing a multi-stage botnet loader through the normal npm install path.

Nobody clicked a phishing link. Nobody misconfigured a server. A developer ran npm install the same way they do a dozen times a day, and the dependency tree did the rest.

This is the pattern that keeps repeating across supply chain incidents this year: the compromise doesn’t need to be sophisticated because the trust model does all the work for the attacker. Once a package is inside your lockfile, it inherits every permission your build process has. CI credentials, deployment tokens, internal network access, all of it becomes reachable from four lines in a package.json nobody reviewed line by line.

Multi-stage loaders are specifically built to survive that first install. The initial payload is small and unremarkable. It downloads the next stage later, often after the package has already been approved, cached, and mirrored across your organization’s internal registries. By the time detection catches up, the loader has had time to establish persistence and start pulling in whatever the second stage was built to do, in this case, recruiting the host into a botnet.

Your Cybersecurity Stack Ends Where The Vendor’s Begins

Both incidents point at the same blind spot: defense in depth usually stops at your own infrastructure. Extending it to vendors and dependencies takes deliberate, unglamorous work, but it’s the only thing that actually closes the gap.

Start here, and treat this as an ongoing program, not a one-time audit:

• Inventory every third-party service with write access to your data, ShareFile, file transfer tools, SaaS integrations, and assign each one an owner responsible for tracking its advisories.
• Pin dependency versions and review diffs on any update to build or generator tooling before it merges, especially packages with maintainer or publish access changes.
• Segment vendor-managed file transfer and storage systems onto their own network zone so a vendor-side compromise can’t pivot directly into production systems.
• Feed outbound connection monitoring and threat detection rules with indicators from supply chain disclosures, not just your own incident history, so a botnet loader calling home gets flagged fast.
• Bake a vendor-outage clause into your incident response plan: who gets notified, what manual fallback exists, and how you verify a vendor’s “all clear” before trusting it.

None of this replaces the basics. Security hardening on your own endpoints, brute-force lockouts on exposed admin panels, and tools like ipban or IPBan Pro filtering abusive login attempts still matter, and they’re cheap insurance against the noise attackers throw at every open port around the clock. But those controls protect the perimeter you own. They do nothing for the zero-day sitting inside a vendor’s Storage Zones Controller or the botnet loader riding in through a dependency tree three layers deep.

The uncomfortable truth is that your risk register probably has a line item for “our servers get breached” and nothing for “our file-sharing vendor gets breached and we’re offline for a week.” Fix that gap before the next Progress Software or AsyncAPI shows up in your logs instead of someone else’s advisory.

Sources

• Progress Confirms Zero-Day Vulnerability Behind ShareFile Disruption
• Compromised AsyncAPI npm Packages Deliver Multi-Stage Botnet Malware
• Microsoft’s July 2026 Patch Tuesday Addresses 569 CVEs