What is the BeyondTrust vulnerability?

CVE-2026-102764, an authentication bypass in BeyondTrust Remote Support 26.2.3 and earlier that lets unauthenticated remote attackers perform file operations on unpatched appliances. It was exploited as a zero-day from late August 2026 and disclosed on 16 October. SaaS customers were patched on 8 October; self-hosted appliances must be patched manually if automatic updates are off. Mandiant advises treating any exposed, vulnerable appliance as potentially compromised until reviewed.

Why do VPN and remote access appliances keep getting hacked?

Because they must listen on the internet to do their job, they are complex, and they hold the keys to everything behind them. Ivanti Connect Secure, Palo Alto PAN-OS management interfaces, Fortinet and BeyondTrust appliances have all been exploited repeatedly. Every exposed appliance is a target for anyone who finds the next flaw.

What is the safest way to give remote access to systems?

Don't put an access appliance or management interface on the public internet at all. Use an identity-based private network (a mesh VPN or zero-trust access service) where nothing listens publicly for admin access, require strong sign-in with your identity provider, give each person access only to what they need, and keep the access policy in code with review.

What should I do if I run BeyondTrust, Ivanti or Palo Alto appliances?

Patch now, and check whether management interfaces are reachable from the internet. If a vulnerable appliance was exposed during the exploitation window, assume compromise: review logs, rotate credentials it held, and check for web shells. Then plan to take management access off the internet entirely.

Remote Access Security: Lessons From the October 2026 Zero-Days

Q: Is the BeyondTrust zero-day linked to the US Treasury breach?

No, that was an earlier, separate campaign. Silk Typhoon breached 17 BeyondTrust Remote Support SaaS instances, including the US Treasury Department's, using older vulnerabilities and a stolen API key. The October 2026 zero-day is attributed to a different China-nexus actor tracked as Armory Castle, also known as UNC5221.

A cracked security appliance with its door ajar at a castle gate on the edge of the network, while on the right servers with no outward doors connect to laptops through private underground tunnels

In one week of October 2026, three remote-access products made the news for the same reason. BeyondTrust disclosed a Remote Support zero-day exploited since late August. Ivanti's Connect Secure VPN had a zero-day exploited since 1 October and added to CISA's exploited list. Palo Alto patched a flaw in its firewalls' management interface that gives root to an attacker with credentials and network access. The pattern is the lesson: the appliance that guards access has to sit on the internet to work, so it is the first thing attackers hit. Patching each one is necessary and never enough, because the next flaw is already being looked for. The durable fix is architectural: nothing that grants admin access should be reachable from the internet at all. Below: what happened, why it keeps happening, the alternative, and what we run ourselves, including the gap.

What happened this month

BeyondTrust Remote Support, CVE-2026-102764. An authentication bypass that lets unauthenticated attackers perform file operations on unpatched appliances, Remote Support 26.2.3 and earlier. Exploited as a zero-day since late August and attributed to a China-nexus actor tracked as Armory Castle (UNC5221), who used a web shell, wiped logs and escalated to root. SaaS customers were patched on 8 October. Self-hosted appliances must be patched manually if automatic updates are off. Shadowserver tracks over 1,400 exposed Remote Support instances, and Mandiant advises treating any exposed vulnerable appliance as compromised until reviewed (BleepingComputer).

It is not BeyondTrust's first time. In an earlier campaign, Silk Typhoon breached 17 Remote Support SaaS instances, including the US Treasury Department's, using older vulnerabilities and a stolen API key.

Ivanti Connect Secure, CVE-2026-104935. Remote code execution in Ivanti's VPN, exploited as a zero-day since at least 1 October and added to CISA's Known Exploited Vulnerabilities catalog on 13 October (BleepingComputer).

Palo Alto PAN-OS, CVE-2026-0322. A flaw in the management interface of PA-Series and VM-Series firewalls and Panorama that lets an authenticated attacker with network access run code as root. Palo Alto reported "very limited exploitation" when it published fixes on 14 October (SecurityWeek).

Why it keeps happening

Remote-access appliances are the perfect target:

They listen on the internet, by design, so anyone can probe them.
They are complex, with web interfaces, authentication flows and legacy protocols, so flaws keep appearing.
They hold the keys. Get past one and you are inside, often with an administrator's view of everything.
Management interfaces get exposed by accident, because it is convenient to log in from anywhere.

Each patch closes one flaw. The exposure stays.

The alternative: nothing listening for admin access

The model that removes the target looks like this:

Management interfaces are never on the internet. Firewalls, databases, admin panels, hypervisors, back-offices: reachable only from a private network.
Access goes through an identity-based private network, a mesh VPN or zero-trust access service, where devices connect out and nothing waits for inbound admin connections on a public address.
People sign in with your identity provider, with multi-factor authentication, and lose access when they leave.
Each person reaches only what they need. Engineers on the systems they run, a supplier on the one server they maintain, nobody on everything.
The access policy lives in code, reviewed and applied automatically, so nobody "temporarily" opens a port and forgets it.
Vendor access is time-boxed and logged, not a permanent account.

This doesn't replace patching. It means the next zero-day in an access product finds nothing to attack from the outside.

What we run, honestly

For the software we build and host, as described on our security page:

No administration on the internet. Admin tools and database access are reachable only from our private Tailscale network, never from the internet.
No public IP addresses on our cluster's nodes. Public applications sit behind Google's load balancer, with Cloud Armor rules filtering abusive traffic before it reaches them.
The network policy lives in a repository and is applied by CI, not edited by hand.
Credentials in Vault and Google Secret Manager, never in code.

The gap: our private network keeps administration off the internet, but it doesn't yet restrict each person to specific services. We say so on the security page too. It is the next step, and point 4 above is the reason.

This is the same lesson as the French supermarket fridge hack, where refrigeration controllers with admin interfaces on the internet were taken over in hundreds of stores.

Remote Access Security After BeyondTrust and Ivanti: Keep the Door Off the Internet

In one week, a BeyondTrust remote support zero-day exploited since August, an Ivanti VPN zero-day, and a Palo Alto firewall flaw in its management interface. The pattern is the same each time: the appliance that guards access sits on the internet. Here is the alternative, and what we run.