ESET published research on 17 September 2026 describing SparroWocky, a modular backdoor deployed against government entities in eight Latin American countries. The sentence worth stopping on is not about the malware: ESET says the operators gained access to targets' networks by exploiting publicly reachable Exchange servers.
No CVE accompanies that sentence. ESET names no vulnerability for this campaign, so the exploit is not the fact on record here. What is on record is that the servers were reachable.
What actually happened
ESET attributes the activity to the China-aligned group it calls FamousSparrow, with high confidence.
| Element | Detail, per ESET |
|---|---|
| Initial access | Exploitation of publicly reachable Exchange servers |
| Vulnerability | None named |
| Payload | SparroWocky, a modular backdoor written in C |
| Capabilities | Command execution, file operations, screenshots, TCP proxying |
| Persistence | DLL side-loading, through Windows services or Registry Run keys |
| Timeline | Focus shifted to Latin America July 2025, first SparroWocky deployment August 2025 |
| Targets | Government entities in Argentina, Ecuador, Guatemala, Honduras, Panama, Peru, Puerto Rico and Venezuela |
ESET reports that roughly 90 percent of the group's targets from mid-2025 into the first half of 2026 were in the region, a narrowing from earlier global activity, and singles out Panamanian port authorities involved in disputes with Chinese companies. No victim count is published.
The naming belongs apart from the technical findings. Several outlets covering the research on 17 September, The Register among them, ran the campaign under the name Salt Typhoon. ESET says that in the absence of technical indicators it tracks the two separately, and that Trend Micro's link between FamousSparrow and Earth Estries is not fully understood. A backdoor sample is an artifact. A group name is a conclusion drawn from artifacts, and the published sources do not agree on this one.
The gap: no flaw has been named, and the first step happened anyway
Most posts here can point at a CVE, a CVSS vector and a patch date. This one cannot. Patch prioritization needs something to prioritize, signature-based inspection needs a known pattern, and an exploitation alert needs a known request shape. Every one of those is a good control waiting on a detail that has not been published.
Identity controls sit in a similar position. If the access came from exploitation rather than from a valid credential, which is what ESET's wording indicates, then multi-factor authentication and conditional access in front of the mailboxes were never asked to decide anything. They are not weak. They are positioned after a decision the server had already made.
A server that answers only trusted origins is not a publicly reachable server, and publicly reachable is the only precondition anybody has been able to confirm.
What would have had to be true
Ask the narrow question. What would have had to be true for the first step to fail while nobody knew which vulnerability was being used?
The server would have had to not answer the operators' network. That is an ordinary rule, available on whatever firewall sits in front of an on-premises Exchange deployment, and writing it does not require knowing what the request contained.
Exchange is the awkward case for this argument, and it is worth saying so plainly. Part of it genuinely must answer everybody, because mail transport accepts connections from mail servers all over the world. The web surfaces are a different population, reached by employees, which is a knowable set of people even though it is not a static set of addresses. ESET does not say which surface the operators used, so that distinction is where the claim has to stop.
For the surfaces staff use, the reason source restriction is rare is the usual one. The list decays from the moment it is written. Someone works from home, a colleague travels, a broadband provider reassigns an address overnight. An address left in too long is silent, while a missing one is a support ticket before lunch, so the range gets widened until it is no longer a control, or it never gets written.
Where Veribound would have fitted
Veribound is an intelligence layer, and the customer's own equipment does the enforcing. Agents on staff devices continuously attest that each device is still the one the organization trusted. A trust-scoring engine turns those attestations into a per-device decision. What reaches the network is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. Those origins are kept current in the address groups and network objects the organization's own firewall policy already references.
Applied to an on-premises Exchange deployment:
- A scan finds no sign-in surface, so the server does not reach a target list built from whatever answered.
- The vulnerability is untouched, whatever it turns out to be, and a fix is still the answer once one exists. It has to be delivered from somewhere first.
- Authentication and conditional access keep running, unchanged, now meeting only people the organization trusts.
- The list stays current on its own, which is the part that was failing, and it changes when somebody changes network.
What this would not have done. It would not have removed a backdoor, undone DLL side-loading persistence, or reversed access already established, all of which follow the foothold rather than precede it. It would not have helped against an operator working from a device and network already trusted, and on an internal segment an attacker holding an existing foothold satisfies the same precondition an external one does. It does not apply to mail transport, which answers strangers by design, and ESET has not said whether mail transport or a web surface was the path. It also does not apply where mail is vendor-hosted, because there the organization does not operate the control in front of the service. This is an on-premises argument.
The claim is narrower than the campaign, and the narrow one is the one worth making. ESET did not name a vulnerability, and did not need to in order to describe how the operators got in. Neither does anybody wanting to change it.
Source: Beware the SparroWock: The backdoor that bites, the commands that catch, ESET Research, 17 September 2026.