When the security device becomes the way in

Two reports at the end of September 2026 read like one story: devices meant to guard the perimeter became the route inside. They are separate incidents, and the sources do not link them.

The first involves the crypto exchange Bitget. According to BleepingComputer, on 24 September 2026 an attacker, as Mandiant established, gained privileged access to two third-party security appliances. They used a zero-day, a vulnerability for which no patch yet existed. On one appliance they left a web shell, a small script that gives remote control of a server, and from there reached the server that runs the wallets. Roughly $387.5 million was stolen. Bitget said the cause was a zero-day in third-party security products, which The Hacker News also reports. The vendor has not been named, so we will not guess.

A few details matter in practice. SlowMist, the second firm that investigated, found the earliest signs of malicious activity in the logs dating from 31 August, well before the theft. According to SlowMist, the attacker ran a command that read an environment variable holding the database password. And, per The Hacker News, on 25 September the attacker logged into one appliance's management platform using an internal employee's identity. The money was taken from hot and warm wallets (the ones connected to the network and used for payouts).

The second story is Citrix NetScaler. On 27 September 2026 Citrix published an advisory covering eight vulnerabilities in NetScaler ADC (a device that distributes traffic to applications) and NetScaler Gateway (a remote access gateway, including VPN). SecurityWeek describes two of them, CVE-2026-88771 and CVE-2026-88772, as zero-days; both score 9.5 on the CVSS scale. A CISA bulletin says attackers are actively exploiting them globally, and both were added to the Known Exploited Vulnerabilities (KEV) catalogue. US federal agencies were given until 30 September 2026 to act.

Not a coincidence, a pattern

According to VulnCheck, 28.96% of the vulnerabilities in its KEV catalogue for 2025 were exploited on or before the day the CVE was published. A CVE is the public identifier of a vulnerability. In other words, there is often no patch yet and the attack is already under way. Network edge devices, meaning firewalls, VPNs and proxies, top the list of targets.

The conclusion needs no drama. A perimeter device is an asset like any server: it has vulnerabilities, accounts, logs and an owner. We have simply got used to thinking of it as protection rather than attack surface. Here are seven steps that correct that.

The first three steps: see, manage, listen

Step one: an inventory of perimeter devices. List every firewall, VPN gateway, load balancer and proxy: model, version, owner, management address, end of support date. Without an inventory you learn about a vulnerable NetScaler from the news rather than from your own list, and you cannot be sure whether you run one at all.

Step two: a separate management channel with MFA. MFA is multi-factor authentication, a second proof of identity beyond the password. Administration of the devices should not be reachable from the same internet they protect. You need a dedicated management network, access through a hardened jump host, and MFA for every administrator. If an employee's credentials open the management platform, as described in the Bitget case, the second factor becomes the last barrier.

Step three: device logs in monitoring. Such devices usually do not run EDR (endpoint detection and response, an agent that watches for suspicious behaviour on a server or laptop), so they will not report a compromise themselves. Send the logs to central monitoring and alert on configuration changes, new accounts, unusual logins and unknown files. The question is not whether the logs exist. It is who reads them, and when.

The other four: time, boundaries, secrets, money

Step four: a patch deadline for the perimeter, measured in hours. Weeks may still be acceptable for ordinary servers, but not for a perimeter with known exploitation: Citrix published its advisory on 27 September and US agencies were given until 30 September. Put a specific number of hours in your policy for critical perimeter vulnerabilities that are already being exploited, and decide who may take a service offline when no patch exists. A useful priority signal is whether the vulnerability is in the KEV catalogue.

Step five: segmentation between the perimeter and critical systems. Assume the device is compromised and ask what it can see. There should be no direct route from the perimeter to databases, payment servers or wallets. At Bitget, according to Mandiant, the attacker moved from the appliances to the wallet server. Describe permitted traffic between zones explicitly and close the rest.

Step six: no secrets in environment variables. Every process, and anyone who reaches the server, can read them. According to SlowMist, the database password was read exactly this way. Keep passwords and keys in a secrets vault, issue short-lived ones, restrict access per service, and rotate after any suspicion.

Step seven: dual control on large financial operations. If an attacker reaches the payment system, the last barrier is process. Operations above a threshold should be approved by a second person or an independent system, and new beneficiary addresses or limit changes should get a separate check. We do not claim this would have stopped Bitget: how its wallets are arranged has not been described publicly.

The red team scenario: "the perimeter is already breached"

A red team (a team that imitates real attackers) can start not by looking for a vulnerability but from an assumption: an outsider is already on a perimeter device. Then the team checks whether they can reach the management network, find secrets, and get to critical systems and payment processes. Above all, it checks whether anyone notices, and how quickly. This scenario tests steps two to seven together rather than as separate settings. See the Red Team Assessment page for the format.

A penetration test complements it from the other side by looking for vulnerabilities and misconfigurations in the perimeter itself: see penetration testing. A review of system and infrastructure security helps tidy up device settings, roles and logging. Financial institutions in the EU may also look at TIBER-EU, a threat-led testing format.

Where to start

With the inventory: the other steps are guesswork without it. If you would like to check your perimeter against this list, let's talk about your case.