Security Advisory

CISA Adds Critical BeyondTrust Remote Support Flaw to Its KEV Catalog; BeyondTrust and Mandiant Confirm Zero-Day Exploitation by Suspected Nation-State Actor

October 17, 2026 · Cyber One Solutions Security Team

CISA added CVE-2026-102764 to its Known Exploited Vulnerabilities catalog on October 16, 2026, the day after BeyondTrust and Google's Mandiant disclosed that a suspected China-nexus espionage actor exploited the flaw as a zero-day against BeyondTrust's Remote Support appliance in late August 2026. Here is who is affected, what BeyondTrust and Mandiant recommend beyond patching, and what to check now.

On October 16, 2026, CISA added CVE-2026-102764 to its Known Exploited Vulnerabilities (KEV) catalog, with an October 19, 2026 due date. That is the catalog's own due date rather than a single deadline for every system: under Binding Operational Directive 26-04, federal civilian agencies set each affected asset's actual remediation timeline from its own exposure, and none of it binds private businesses. The flaw sits in BeyondTrust's Remote Support product, the remote-access appliance many IT help desks and managed service providers use to reach into and troubleshoot customer and employee machines, and this was not a theoretical disclosure. BeyondTrust and Google's Mandiant jointly confirmed that a suspected China-nexus espionage actor exploited this flaw as a zero-day, weeks before the public disclosure, against one BeyondTrust-hosted Remote Support instance and one self-hosted appliance. BeyondTrust's own advisory rates the issue 9.3 under CVSS v4.0, critical, and the National Institute of Standards and Technology's National Vulnerability Database separately scored it 9.8 under CVSS v3.1, also critical, according to BeyondTrust's security advisory BT26-05, BeyondTrust's incident writeup, Mandiant's technical analysis, and CISA's Known Exploited Vulnerabilities catalog.

What It Is

BeyondTrust's advisory describes CVE-2026-102764 as improper origin validation in an internal messaging component of Remote Support, tracked as CWE-290: the component did not adequately confirm where an incoming message actually came from, and Mandiant's investigation found that exploiting it leads to root-level control of the appliance, not just a limited file operation. Google Threat Intelligence Group (GTIG) and Mandiant attribute the exploitation, with moderate to high confidence, to the actor Mandiant now calls ARMORY CASTLE, formerly tracked as UNC5221 (CrowdStrike tracks the same cluster as WARP PANDA), a suspected China-nexus (PRC) espionage actor GTIG has previously tied to zero-day exploitation of Citrix NetScaler (CVE-2023-4966) and Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887, and CVE-2025-0282). According to BeyondTrust's incident writeup, the actor first exploited this flaw on August 29, 2026, nearly seven weeks before the October 15 public disclosure. BeyondTrust's own threat-hunting team found and contained the SaaS-hosted intrusion on September 28, and Mandiant's independent investigation of the self-hosted victim confirmed the same technique two days later. Mandiant's analysis documents the post-exploitation pattern: the actor plants a web shell, escalates to root-level control within minutes, installs persistence designed to survive a reboot, harvests credentials the appliance stores or brokers for other systems, and deletes the appliance's own logs before leaving. CISA's catalog entry separately flags this CVE for forensic triage under Binding Operational Directive 26-04. BeyondTrust states this actor has a documented history of moving from narrow, selective zero-day use to broad, opportunistic exploitation of every instance still unpatched once a flaw becomes public, and GTIG says it is possible that similar widespread exploitation will follow this disclosure too, which is the position an unpatched appliance is now in.

Who Is Affected

BeyondTrust's advisory lists all Remote Support versions through 26.2.3 as affected. BeyondTrust's internal testing has not found a way to exploit this specific flaw in Privileged Remote Access (PRA), a separate BeyondTrust product, but because PRA shares the underlying code, BeyondTrust released a patch for PRA out of caution and recommends self-hosted PRA customers apply it immediately as well. Do not assume this advisory is Remote-Support-only if your organization runs PRA. BeyondTrust shipped the BT26-05 patch on October 8, 2026, and applied it automatically to every Remote Support and PRA SaaS (cloud-hosted) tenant by October 9; BeyondTrust states no further action is needed for a SaaS appliance itself. Self-hosted customers should manually apply the patch if their appliance is not subscribed to automatic updates in the appliance interface; an appliance that is subscribed to automatic updates has likely already received it. Customers running a version older than 24.3.1 cannot apply the patch directly. BeyondTrust's advisory states they need to upgrade to a supported version first, and Mandiant notes that upgrading alone closes the vulnerability going forward but does not remediate any exposure that already occurred, so the steps below still apply to those appliances too.

What to Do Now

• Confirm whether your organization, your IT provider, or any vendor with access to your systems runs BeyondTrust Remote Support or Privileged Remote Access, and whether it is the SaaS product or a self-hosted appliance. BeyondTrust's SaaS patch covers the appliance itself; a self-hosted deployment needs the steps below.
• If you already have specific evidence a self-hosted appliance (Remote Support or PRA) was compromised, such as unexplained administrative changes or unusual session activity, do not patch, reboot, or change anything yet. Mandiant recommends preserving evidence first: for a virtual appliance, a memory snapshot and disk export before any change, since those changes can destroy the only evidence available; for B Series hardware, request forensic preservation through BeyondTrust Support instead, since you cannot take that snapshot yourself. Export logs to a SIEM or a separate system where you can, since Mandiant's investigation found the actor deletes the appliance's own logs. Then isolate it: block inbound traffic to its public address at your firewall rather than in the appliance's own interface, so its configuration stays intact for review; restrict its outbound traffic to BeyondTrust's own update and licensing endpoints; end active support sessions, and disable new sessions, Jump Clients, Jumpoints, and API accounts (disable rather than delete, so the audit trail survives), before proceeding to the rebuild and credential-rotation guidance below. If you use the SaaS product and have specific evidence of compromise, request forensic preservation and containment through BeyondTrust Support directly, since you do not control the appliance's own network or firewall.
• Otherwise, patch now, Mandiant's recommended default even for an appliance that was internet-exposed during the window described below, unless your organization's risk tolerance calls for treating that exposure itself as a suspected compromise and preserving evidence first, using the same steps above, before patching. Apply the BT26-05 patch on a self-hosted Remote Support appliance (or confirm it applied automatically), and apply the precautionary patch on a self-hosted PRA appliance. Mandiant frames this as a choice organizations make based on risk tolerance, evidence, and operational needs, with immediate patching as its own recommendation when there is no specific evidence of compromise.
• Even after patching, treat a Remote Support appliance as potentially compromised until your IT provider has reviewed it if either applies: it was reachable from the internet on a vulnerable version at any point since late August 2026, when BeyondTrust and Mandiant confirmed exploitation began, or it already has the specific evidence of compromise described above. To perform that review, compare the appliance's login configuration against a baseline from before the exposure window for user and role changes (particularly any Jump Item role raised to Administrator), group and session policies, API accounts, security providers, Jump Items and Jumpoints, and outbound event or syslog destinations, removing anything without a change record or a named owner; and review support session reports for the window, including file transfers, to establish which endpoints were accessed and what left them, since every endpoint touched is in scope for downstream hunting. Patching closes the flaw going forward but does not remove any persistence an attacker may have already installed. Mandiant recommends rebuilding an appliance with confirmed, suspected, or unknown compromise status (including when the review above is inconclusive, since the actor deletes logs that would otherwise clear it) from a clean, patched image rather than relying on the in-place patch alone, since that persistence is designed to survive a reboot or a configuration reset. Before rebuilding, isolate it the same way described above (block inbound traffic at your firewall, restrict outbound traffic to BeyondTrust's own endpoints, and end active support sessions) so persistence cannot act while you prepare the rebuild. For a rebuilt appliance, issue a new TLS certificate, and whether it was patched in place or rebuilt, redeploy Jump Clients, Jumpoints, and the representative console from it to invalidate existing enrollment tokens; if you restore a configuration backup, use one dated before the exposure window or review the restored configuration for unauthorized changes while the appliance stays isolated. BeyondTrust found no confirmed way to exploit this specific flaw in PRA, so the internet-exposure trigger above applies to Remote Support, not a self-hosted PRA appliance; a PRA appliance with its own separate evidence of compromise still follows the preservation and rebuild guidance above.
• After a self-hosted appliance that needed the compromise-assessment or rebuild step above is patched or rebuilt, not before, rotate the credentials it stored or brokered, in dependency order: appliance administrative credentials; login administrators and local users; API client secrets; security provider bind accounts and SAML signing keys; any Password Safe, Remote Support Vault, or PRA credentials it had access to; integration credentials such as SMTP, syslog, and ITSM connector secrets; and any credential typed into a support session during the exposure window. Rotating earlier exposes the new credentials to an attacker who still controls the appliance.
• If your organization only uses the Remote Support SaaS product, BeyondTrust states no action is needed for the appliance itself, but Mandiant's guidance states the same credential-and-configuration review applies to Remote Support SaaS tenants too: end active support sessions and invalidate existing tokens, review role and policy changes (particularly anything newly granted administrative access) and session reports for file transfers you cannot account for, and rotate the same categories of credentials described above that were exchanged or reachable during the exposure window. If you have specific evidence of compromise beyond ordinary exposure, follow the BeyondTrust Support preservation path described above before these steps. For a PRA SaaS tenant with no evidence of compromise, BeyondTrust states no further action is needed beyond the automatic patch already applied, consistent with finding no confirmed way to exploit this flaw in PRA at all; a PRA SaaS tenant with specific evidence of compromise from another source should still follow the BeyondTrust Support preservation path described above, since the absence of a confirmed exploit path through this CVE does not rule out a separate incident.
• Keep a dated record of when you checked your version, confirmed SaaS or self-hosted status, and applied the fix or completed the review above. If a customer, auditor, or insurer later asks how you handle an actively exploited vulnerability in vendor-managed remote-access tooling, that record is the answer.

Why This Belongs on Your Radar

Remote-support software occupies an unusually sensitive position in a business's technology stack. It exists specifically to let a help desk or an MSP reach into endpoints, often with elevated access, which is exactly why a suspected nation-state actor targeted it and why a flaw in the appliance itself carries more weight than a flaw in an ordinary line-of-business application. BeyondTrust and Mandiant currently know of only two compromised instances connected to this flaw, and BeyondTrust states it has not seen evidence of activity since August, so this is not evidence of widespread compromise today. What both organizations warn about is what typically happens next: this actor has a documented history of moving from quiet, selective zero-day use to broad, opportunistic scanning of every unpatched instance once a flaw becomes public, which is exactly the position CVE-2026-102764 is in as of this week. If your help desk, an internal IT team, or a managed service provider uses BeyondTrust Remote Support or Privileged Remote Access to support your organization, ask directly whether the instance is self-hosted and whether it is Remote Support or PRA: a self-hosted Remote Support instance needs the patch and the applicable compromise assessment and credential rotation above, not just the patch, while a self-hosted PRA instance with no separate evidence of compromise needs only BeyondTrust's precautionary patch.

For businesses subject to the FTC Safeguards Rule or the HIPAA Security Rule, the same obligations we have flagged for earlier advisories apply here. The FTC Safeguards Rule requires nonbanking financial institutions to test or monitor their information systems under 16 CFR 314.4(d)(2), which must include continuous monitoring or, absent effective continuous monitoring, annual penetration testing plus vulnerability assessments at least every six months and whenever a material change to operations or business arrangements occurs, though institutions maintaining customer information on fewer than 5,000 consumers are exempt from that paragraph. HHS Office for Civil Rights guidance is explicit that identifying and remediating known, actively exploited vulnerabilities falls within the ongoing risk analysis and risk management obligations at 45 CFR 164.308(a)(1)(ii)(A) and (B); a remote-support appliance that can reach systems storing or processing protected health information is squarely the kind of vendor-managed access point that guidance covers.

If your organization or your IT provider runs a self-hosted BeyondTrust Remote Support appliance, confirm its patch status this week and complete the applicable compromise assessment and credential rotation above; for a self-hosted PRA appliance with no evidence of compromise, BeyondTrust's precautionary patch is the applicable action, and with specific evidence of compromise, follow the preservation and rebuild guidance above instead; for a Remote Support SaaS tenant, complete the credential-and-configuration review above; and a PRA SaaS tenant with no evidence of compromise needs no further action beyond the automatic patch already applied, while one with specific evidence of compromise should follow the preservation path through BeyondTrust Support instead. Cyber One Solutions tracks CISA's Known Exploited Vulnerabilities catalog and vendor advisories as part of our managed cybersecurity service, and our managed IT service coordinates patching and vendor management for the technology in your environment, with the exact scope of what we manage defined in your service agreement. Our IT and security assessments can confirm your current exposure, including whether your organization or a vendor runs a self-hosted BeyondTrust appliance, as a standalone engagement.

Sources

• BeyondTrust Security Advisory BT26-05: Improper Origin Validation in an Internal Messaging Component
• BeyondTrust: ARMORY CASTLE and BT26-05, What Security Teams Need to Know
• Google Threat Intelligence Group / Mandiant: ARMORY CASTLE Exploits BeyondTrust Remote Support Zero-Day
• CISA: Known Exploited Vulnerabilities Catalog, CVE-2026-102764
• National Vulnerability Database: CVE-2026-102764 Detail
• CISA: Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 26-04 Implementation Guidance, Forensic Triage Requirements
• Federal Trade Commission: FTC Safeguards Rule, What Your Business Needs to Know
• HHS OCR: January 2026 Cybersecurity Newsletter