Three advisories published within two days of each other this week turn on the same fact: who can reach a management interface. I think that control is under-invested in most security programs, and I would start there before the next advisory arrives.
What the three advisories share
Barracuda’s advisory says “successful exploitation requires an attacker to have access to the administrative interface of an affected product,” and it covers six products. Zyxel’s advisory for CVE-2026-107441 describes an attacker who is “LAN-based, unauthenticated.” SonicWall’s advisory for end-of-life GMS describes an unauthenticated attacker “with network access” to GMS 9.5.2 and earlier, and lists no fix and no workaround because the product is end of life.
The details differ. The Barracuda flaws need administrative-interface access, the Zyxel flaw needs a path on the local network and the SonicWall file read needs only a route to the service. In every case the first requirement an attacker has to meet is reach to a management service, which is a property of how the network is built and says nothing about the code.
The vendor advice points the same way
Barracuda’s guidance is direct: it recommends “restricting access to administrative interfaces to trusted internal networks” and using network access controls to limit exposure. The company adds that organizations whose interfaces are not publicly reachable “are less exposed to this attack path,” which is a vendor telling customers that the network position of the management page changes the risk. I take it at its word.
My position goes a step further. A management interface should answer only from a dedicated management network or a jump host, with its own authentication and its own logs. Every switch, gateway, archiver and management server with a web admin page belongs on that list. When a product reaches end of life, as GMS has, the same restriction is the only control left, because the SonicWall advisory lists the workaround as “None.”
The strongest objection
The best argument against this is that segmentation does little once an attacker is inside. Zyxel describes a LAN-based attacker, and on a flat office network every laptop, printer and guest device sits on that LAN. An intruder who lands on any of them can already see the switch. Remote offices and cloud-managed gear add another complaint, since a locked-down management network can break the way a vendor expects to reach the device.
Both points are fair, and they are why the answer is a management network instead of a firewall rule on one device. Moving administration to a small set of hosts shrinks “the LAN” from every desk and guest device to a handful of administrator machines. Those machines can carry multi-factor authentication, endpoint monitoring and a session log that nothing else on the network has. Remote offices reach the management network through the same jump host. The cost is a few days of cabling and rules per site, which is small next to an emergency change window.
Patching stays on the list
Narrowing reach buys time and leaves the flaw in place. The Zyxel case shows why a patch record alone is a weak signal: Binarly reports that an exploit still worked on all ten GS1900 builds that carried the June fix for a different CVE. A device on the management network with an unpatched flaw is a smaller problem than one on the user network, and it is still a problem.
The two controls cover different failures. Patching removes a known flaw. A management network limits who can try an unknown one, including a flaw in a product that will never receive a fix. A program with only one of them is exposed to the failure the other covers.
What I would do this week
- List every device and appliance with a web or API administration page, and record the networks that can reach each one.
- Scan your own external address ranges for those admin pages, and close any that answer from the internet.
- Create a management VLAN or jump host, and move administration of the Barracuda, Zyxel and SonicWall devices on your list to it first.
- Log every login and failed login on those interfaces, and alert on a login from any host outside the jump host.
- Give each end-of-life product a retirement date and an owner, and keep it on the management network until it is gone.
None of this requires a new product. It requires a network diagram and the discipline to act on it, and the three advisories from this week are a good prompt to produce both.
Source: Barracuda, advisory on CVE-2026-116606 and CVE-2026-111560; SonicWall PSIRT, SNWLID-2026-0019; Zyxel, advisory for CVE-2026-107441
