SURIQ
Self-hosted operators ran an open door for roughly six weeks and only found out this week. A China-nexus espionage group has been exploiting a critical authentication-bypass flaw in BeyondTrust Remote Support as a zero-day since late August, while the software vendor quietly patched its cloud customers in early October and told everyone else to patch by hand. The appliance teams install to control remote access became the way in. Tracked as CVE-2026-102764 and rated CVSS 9.3, it was added to CISA's Known Exploited Vulnerabilities catalog on October 16, with a federal patch deadline of October 19.
The flaw sits in how an internal messaging component validates where a message came from. BeyondTrust describes it as a failure to adequately check the origin of received messages, which in the wrong conditions lets a remote attacker with no credentials act on files on the box. From there, the intruders flipped SUID permissions to reach root. Mandiant and Google Threat Intelligence Group attribute the activity to a group they track as Armory Castle, also known as UNC5221 and, in CrowdStrike's naming, Warp Panda, active since late 2023.
Who is exposed, and who already got the fix
The vulnerable range runs from self-hosted build 24.3.1 up to and including 26.2.3; anything below 24.3.1 needs a full upgrade, not a point patch, before the fix lands. BeyondTrust says the same messaging weakness reaches its Privileged Remote Access product and advises self-hosted PRA customers to apply the update immediately, a point echoed in the Canadian Centre for Cyber Security advisory. Shadowserver counted more than 1,400 exposed instances reachable on the internet; how many were actually compromised is not public.
The split that matters: all Remote Support SaaS customers were patched in early October, before public disclosure, so cloud tenants never had to act. Self-hosted operators learned of the problem only when the advisory and the KEV listing landed on October 15 and 16, and they carry the entire remediation burden themselves. The people who chose to run their own box took both the longer zero-day exposure and the manual patch.
The window was open for six weeks
Mandiant puts the earliest known exploitation at August 29, 2026, when one self-hosted appliance was hit. Attention widened on September 27, when exploitation of another security-device vendor was disclosed. BeyondTrust patched SaaS in early October, published the self-hosted advisory on October 15, and CISA listed the CVE on October 16 with a three-day deadline. Read against the dates, this is not a race from patch to exploit. The exploitation came first, quietly, and the patch chased it by six weeks.
What the intruders did once inside
This is a defender's map, not a recipe. Mandiant's account of the post-exploitation work reads like a tour of everything a remote-support box is trusted with. Root came first, through the SUID change. Two custom tools followed: a PHP web shell the researchers named SAWFLY, for hands-on access over encrypted channels, and a small SOCKS5 proxy called BARECLAW for relaying traffic. The group then pulled stored secrets straight from the appliance's credential store, reworked its configuration templates, and walked the saved Jump Item entries to reach managed endpoints. To keep a foothold reachable, they edited HAProxy so it faced the internet, then cleared the logs behind them.
That last step is the one defenders should sit with. A remote-support appliance holds standing credentials and a list of everything it can reach. Compromise it and an attacker inherits a pre-built map of your internal fleet, which is exactly why Jump Item enumeration appears in the post-exploitation notes.
A patch closes the door; it does not evict a guest
If a self-hosted appliance was internet-facing before October, patching stops new exploitation but says nothing about whether someone is already inside. The actor wiped logs and rewrote HAProxy, so the appliance's own telemetry is the least trustworthy place to look. The durable signals come from outside the box: unexpected outbound tunnels and SOCKS5 traffic, new SUID-root binaries, web-root files that changed when no one deployed, and credentials from the appliance turning up in logins elsewhere.
This is where file-integrity monitoring on the appliance host and a managed detection service earn their place. We run file integrity monitoring that flags new SUID binaries and modified config the moment they appear, with analysts mapping the activity to MITRE ATT&CK rather than leaving it in a log nobody reads. For an appliance you suspect was reached before the patch, treat it as an incident response case, not a routine update, and credential rotation is part of that. Among the flaw classes our triage desk logged over the past 90 days, authentication and account-takeover bugs rank third, behind cross-site scripting and command injection, so origin-validation failures like this one are not an outlier.
Appliance OS, not just the app:
- New SUID-root binaries created since late August (privilege escalation)
find / -perm -4000 -type f -newermt "2026-08-20" 2>/dev/null
- PHP web shell artifacts under the appliance web root (SAWFLY)
recently modified/unknown .php files, interactive one-liners
- Unexpected outbound SOCKS5 / long-lived TCP tunnels (BARECLAW)
egress to new IPs on non-standard ports from the appliance
- HAProxy config edited to expose an internet-facing tunnel
- Gaps or truncation in the appliance's own access and audit logs
ATT&CK mapping for the hunt:
T1190 exploit public-facing application (initial access)
T1505.003 server web shell (SAWFLY)
T1548.001 setuid/setgid privilege escalation
T1572 protocol tunneling (BARECLAW SOCKS5)
T1070 indicator removal / log deletionThe same bug class hit the perimeter twice this week
CVE-2026-102764 did not arrive alone. In the same stretch, CISA added Ivanti Connect Secure CVE-2026-104935, described as an authentication bypass by spoofing that lets an unauthenticated attacker run commands, alongside path-traversal and code-injection flaws in Fortinet, Cisco, and Palo Alto gear. Two of this week's KEV additions, BeyondTrust and Ivanti, share the same root idea: a device trusted a message or request whose origin it never properly checked. We wrote in July about BeyondTrust's own AI finding pre-auth bypasses in the same product line, and more broadly about how the appliances bought to be safer keep turning into the week's worst bugs. The group behind this campaign has a history here too; Mandiant has previously tied UNC5221 to Ivanti edge-device zero-day exploitation. The pattern is not coincidence. Internet-facing security appliances are concentrated, high-value targets, and origin-validation shortcuts in their internal plumbing keep paying off for attackers.
Patch the self-hosted box, then hunt the six-week window
Three things, in order. Update self-hosted Remote Support and Privileged Remote Access to a fixed build now; the October 19 federal deadline is a floor, not a target, and installs below 24.3.1 need a full upgrade first. Then assume exposure if the box was reachable before October and run the hunt in the block above, from outside the appliance, not from its logs. Finally, rotate every credential the appliance stored or could reach, because a remote-support tool's whole job is holding keys to other systems. If you manage detection yourself, the signatures that matter are tunnel egress and new SUID binaries; a managed detection setup should already be watching for both.