BeyondTrust Remote Support: first known exploit 29 August, advisory 47 days later, two victims stated

47 days from the first known exploitation to the advisory

BeyondTrust published advisory BT26-05 for CVE-2026-102764, a flaw in Remote Support, on 15 October 2026. The timeline in the blog it published alongside puts the first known exploitation on 29 August, so the advisory came 47 days later (derived). BeyondTrust says its own hunt found the hosted instance on 28 September, 30 days in (derived), and that a patch shipped on 8 October, 40 days in (derived). The advisory followed seven days after the patch (derived). Of the 47 days, 30 (64 per cent, derived) passed before the vendor's hunt found anything, 10 between that finding and the patch, and 7 between the patch and the advisory. CISA listed the flaw in its Known Exploited Vulnerabilities (KEV) catalogue the next day, 16 October, with a due date of 19 October, which is day 51 (derived).

That is the number a customer needs, and it is easy to misread. It is not the time any customer was exposed: exposure depends on version, deployment mode, network position and the day a customer patched. It is not a victim count: BeyondTrust says it is aware of two affected customers, while a Google Threat Intelligence Group analyst told CyberScoop that others may have been compromised before disclosure. And 29 August is the first exploitation BeyondTrust knows of, not a proven first attempt. The sections below set out what the record establishes, what it does not, and what each of the labels in the coverage hides.

This briefing reads the primary documents and uses the press only for what it adds. They were read on Saturday 17 October 2026 between about 11:07 and 11:35 BST: BeyondTrust's advisory, blog (last updated 16 October at 12:00 EDT, per the page), documentation release notes and support policy; the Google Threat Intelligence Group and Mandiant report of 15 October; the CVE record, the NVD record and CISA's catalogue entry, alert and directive; CrowdStrike's public report on the actor; and seven news reports. BeyondTrust's pages answer a plain command-line request with a block page, so they were read in an ordinary browser page; nothing was filled in or submitted and no challenge was completed. A BeyondTrust support article that the advisory and the release notes point to needs a customer login and was not read. Interest: BeyondTrust sells the product and wrote the timeline, and Google (through Mandiant and its Threat Intelligence Group) and CrowdStrike sell threat intelligence and incident response, so every account of the dates and of the actor comes from a party with a commercial interest in how it reads.

The dates, who states each, and where the sources disagree

Each date in the table is stated by the party named. The last column counts days from 29 August (derived). The catalogue lists three earlier BeyondTrust entries (derived), the most recent being CVE-2026-1731, added on 13 February 2026.

Dates read from BeyondTrust's blog, advisory and documentation, the CVE record, CISA's catalogue entry and Mandiant's report, on 17 October 2026. Day counts are derived.

Date (2026)	What happened	Stated by	Day
29 Aug	First known exploitation: one BeyondTrust-hosted Remote Support instance and one self-hosted appliance	BeyondTrust blog; Mandiant says late August	0
24 Sep	Remote Support 26.2.3 release note, the newest version the advisory lists as affected	BeyondTrust documentation	26
27 Sep	Another vendor's exploited zero-day becomes public and BeyondTrust starts hunts. BeyondTrust does not name that vendor	BeyondTrust blog	29
28 Sep	The hunt finds the hosted instance, which is contained within 27 minutes of first detection. The entry point is reproduced about seven hours later	BeyondTrust blog	30
29 Sep	CVE ID reserved	CVE record	31
30 Sep	Mandiant shares findings from the self-hosted customer. The fix is validated on a test build	BeyondTrust blog	32
8 Oct	Patch released to SaaS and self-hosted customers	BeyondTrust blog	40
9 Oct	Patch applied to all Remote Support SaaS customers "as of" this date. Release notes for Remote Support and Privileged Remote Access say a security patch has been rolled out	BeyondTrust advisory and documentation	41
15 Oct	Advisory BT26-05, the CVE record (published about 21:30 BST), BeyondTrust's blog and Mandiant's report	BeyondTrust, CVE record, Google	47
16 Oct	CISA adds the CVE to the KEV catalogue and issues an alert. Due date 19 October, forensic triage required	CISA	48
19 Oct	KEV due date, three days after listing	CISA	51

The SaaS patch date. BeyondTrust's own pages carry both dates. The blog says the patch was released on 8 October and that hosted instances of Remote Support and Privileged Remote Access were patched automatically. The advisory says that as of 9 October the patch had been applied to all Remote Support SaaS customers, and the documentation notes are dated 9 October. One reading fits both: released 8 October, applied everywhere by 9 October. BleepingComputer, CyberScoop and Infosecurity Magazine report 8 October for SaaS; Google and The Hacker News give 9 October for SaaS, SecurityWeek quotes the advisory's 9 October while saying the fix shipped on 8 October, and Dark Reading says the patch was available on 9 October. This briefing follows BeyondTrust's pages: 8 October for release, 9 October for completion. The gap to the advisory is then seven days from release and six from completion (derived). For a SaaS customer that gap cost nothing, because BeyondTrust applied the patch. For a self-hosted customer not on automatic updates it was the whole window: the first public advisory came on 15 October, seven days after release (what the login-only article said earlier is not known), and CISA's due date falls 11 days after release (derived).

"Since August". BleepingComputer's headline and SecurityWeek's opening sentence say the flaw was exploited since August. BeyondTrust's blog says the actor exploited it on 29 August against two customers, and that BeyondTrust has "not seen evidence of adversary activity since August". The record supports one exploitation date and no later activity seen by the vendor. It does not support a campaign running from August to October, and it cannot exclude activity BeyondTrust cannot see. That is why Google's analyst did not rule out further victims.

One victim or two. The Hacker News describes the 29 August exploitation as against a single self-hosted appliance. BeyondTrust's blog, as read on 17 October, says one hosted instance and one self-hosted appliance. The page shows a last-updated time of 16 October at 12:00 EDT and no earlier copy could be retrieved, so whether the wording changed after publication is not known.

Stated and not stated, row by row

"Not stated" means not found in the sources listed, read in full. It does not mean the information does not exist. BeyondTrust says it is withholding the technical details of the flaw while self-hosted appliances are patched, so some of the gaps below are deliberate.

What the primary sources state about CVE-2026-102764, and what they do not. Read on 17 October 2026.

The question	Stated	Not stated
How many victims?	BeyondTrust: "only aware of the two impacted customers", one hosted instance and one self-hosted appliance. Google's analyst: only a small number of organisations are known.	Any count after 29 August. Any other hosted tenant. Names. A BeyondTrust spokesperson declined to tell CyberScoop how many customers are compromised.
Was a SaaS customer hit before the patch?	Yes, one: a hosted Remote Support instance, exploited 29 August and contained 28 September. BeyondTrust says its sensors fired in real time but automated triage "closed those alerts as false positives".	Whether the customer was told, or when. What the actor reached beyond the instance. Whether any other tenant was touched.
Which versions?	Remote Support 26.2.3 or earlier. The BT26-05-RS patch covers 24.3.1 to 26.2.3. Older versions must upgrade first (advisory and CISA).	Which versions the actor attacked. How many releases lie in the patched range: the documentation index shows ten items. Any fixed version number, because the patch keeps the version.
Is Privileged Remote Access exploitable?	BeyondTrust's testing found no way to exploit it, but it "shares the affected code", so a patch was released and hosted instances were patched.	Any PRA fixed version. PRA in the advisory, CVE record or KEV entry: all three list Remote Support only. An exploit, or proof there is none.
Is self-hosted patching automatic?	Only if the instance is subscribed to automatic updates; otherwise manual (advisory). BeyondTrust's documentation says non-disruptive critical patches install as soon as eligible, and disruptive ones in a maintenance window if enabled.	Which kind this patch is. How many appliances had applied it by 15 October.
Does the patch close the class?	BeyondTrust says variant analysis uncovered additional paths, that fixes were added, and that every supported version was retested.	The root cause (withheld). Independent testing. Any patch for versions older than 24.3.1: there is none.
What did the actor do after access?	A web shell, root control of the appliance host, a read of stored secrets, startup persistence, log deletion, administrator-session abuse to reach downstream systems, file transfer of documents and a tunnelling tool (Mandiant).	How many downstream systems. What left them beyond "software inventories". Any other tool, flaw or intrusion by the actor in the same period.
Was AI used?	BeyondTrust's working assessment is that the actor keeps a model of target products in an AI context to develop exploit chains, based on product knowledge and speed.	Forensic proof: BeyondTrust says it has none. Mandiant's report, as read, does not make the claim.
Who is the actor?	A suspected PRC-nexus espionage actor: Armory Castle, formerly UNC5221, at Google. BeyondTrust assesses this with moderate to high confidence on tradecraft, and says CrowdStrike tracks the cluster as Warp Panda.	A CrowdStrike report on this flaw: none found. Its December 2025 Warp Panda report predates the flaw and does not mention BeyondTrust. Targeting beyond the sectors listed.
Is it exploited now?	CISA says actors are "actively exploiting" it and lists it in KEV, with ransomware use "Unknown". Google warns that widespread exploitation may follow disclosure.	Any count of attempts after 15 October. The Record says other firms confirmed exploitation, through a post this briefing could not read.

What the actor did once inside, at defender level

Mandiant's report describes what happened on a compromised appliance. This briefing keeps to the shape of it, names no tool and reproduces none of the indicators or detection rules Mandiant publishes. Defenders who need them should take them from Mandiant's own report.

• Foothold. After exploiting the flaw, the actor placed a script on the appliance's web server about 11 minutes after the first malicious request Mandiant saw, and worked through it as a primary foothold.
• Root. It moved from the web service account to root control of the appliance host. In Mandiant's words that gave "access to every credential the appliance stored or brokered" and the ability to modify files that survive reboot and configuration reset.
• Secrets. It tried several ways to read the appliance's own secrets store, then removed the record of the attempt.
• Persistence. It added a startup step that kept administrative rights for the service account through reboots and configuration resets.
• Logs. It deleted host, web server and application logs, repeatedly.
• The product's own features. It logged in to the application's administration portal with an Administrator account's credentials, raised that account's Jump Item and team permissions from No Access to Administrator, opened remote support sessions to internal endpoints, and used the file transfer service to pull documents useful for reconnaissance, such as software inventories, from a user's desktop. How it obtained the Administrator credentials is not stated; reading the stored secrets is the obvious route, and that is inference.
• Tunnel. It ran a custom tunnelling tool through the appliance and changed the appliance's own web-routing configuration so the tool could be reached from the internet.
• Cover. BeyondTrust says the operator connected through commercial VPN exits and compromised home and small-office routers, and rotates infrastructure and tooling for every victim.

Two points follow for a defender. First, the flaw is described as file operations on the appliance. The harm came from the sequence that followed, which used the appliance's own authority over other systems. Second, Mandiant says "Customers cannot audit the appliance host file system", and that evidence of exploitation sat in log files on an encrypted partition. The actor deleted logs on the appliance throughout, and BeyondTrust says "off-box copies are often the only record left". The records that matter are the ones sent elsewhere before the intrusion.

Nine labels, and what each hides

A label is not a measurement and not a control. Nine appear in the coverage or the documents, each read against the primary sources.

Labels in the story, who uses them, and what the record shows.

The label	Where it appears	What the record shows
"Zero-day"	BeyondTrust's blog; BleepingComputer's headline	No patch existed when exploitation began on 29 August. One existed 40 days later (derived). The label is silent on the six or seven days after that, when a fix existed and no advisory did: no longer a zero-day, not yet a known flaw.
"Authentication bypass", "unauthenticated", "unprivileged"	CISA's alert and KEV name; Google; BleepingComputer	BeyondTrust's advisory says "Improper Origin Validation in an Internal Messaging Component" and "a remote attacker". The phrase "authentication bypass" is the CVE record's weakness label (CWE-290, "Authentication bypass by spoofing"). None of the three words is in the vendor's advisory text. The scores assume no privileges: the vendor's vector and NVD's both say privileges required none.
"File operations"	The advisory, the CVE record and KEV	Mandiant: the exploitation results in the "arbitrary upload of files", and the report describes host-level control and every stored credential after the follow-on steps. The description names the first step. The harm is the sequence.
"China-nexus", "suspected"	BeyondTrust; Mandiant; every report	BeyondTrust assesses it with moderate to high confidence, on tradecraft, and says the actor rotates infrastructure for every victim. One cluster has two names: Armory Castle (formerly UNC5221) at Google, Warp Panda at CrowdStrike, per BeyondTrust. The label forecasts behaviour, mass exploitation after disclosure, and prescribes no control.
"Patched for SaaS"	BleepingComputer; CISA ("already been patched")	One hosted instance was exploited on 29 August and contained on 28 September, before the patch. Mandiant says the credential and configuration steps still apply to SaaS tenants. A patched service can still hold secrets an actor read earlier.
"Abundance of caution"	BeyondTrust's blog, on Privileged Remote Access	PRA "shares the affected code", testing found no way to exploit it, and a patch was released anyway. The advisory, CVE record and KEV entry list Remote Support only, and the PRA release note says only that a security patch has been rolled out. A caution is not a fixed-version table.
"26.2.3 or earlier"	The advisory	The fix is a patch to the same version number: "BT26-05-RS patch for (v24.3.1 - v26.2.3)". BeyondTrust's own terminology, in a September notice, says a patch leaves the version number unchanged. An inventory that records only the version shows the same value before and after the fix.
"Automatic updates"	The advisory: self-hosted customers patch manually "if their instance is not subscribed to automatic updates"	BeyondTrust documents two settings: non-disruptive critical patches install as soon as eligible, disruptive ones only in a maintenance window, if that is enabled. Which this patch is has not been stated.
"Contained within 27 minutes"	BeyondTrust's blog	27 minutes from the hunt's finding, which came 30 days after first exploitation (derived): 0.06 per cent of those 30 days. The alerts from the intrusion had already been closed as false positives by automated triage, on BeyondTrust's own account.

The two release notes of 9 October say "A security patch has been rolled out. For more information, see the KB article.", and the article behind them needs a customer login. The NCSC's update-by-default guidance warns that vendors may "silently" update some vulnerabilities without public acknowledgement. Here the update was noted as a security patch, but with no CVE and no severity, six days before the advisory. This site covered a different remote-access vendor whose changelog logged a fix only as a crash fix, with no CVE and no advisory at all.

Method is separate from accusation. BeyondTrust's blog is candid on a point vendors often leave out: it says its triage tool closed its own alerts, and it says what it is changing. A vendor that publishes its own detection failure has given customers something to act on. The gap is in what is not yet reported, above all the victim count and the PRA position.

The UK: four clocks for one flaw, and where each guide stops

No NCSC publication on this CVE was in the NCSC's publication feed at about 11:30 BST on 17 October 2026. UK organisations are therefore working from general guidance. The CISA directive is a US instrument and is used here as a yardstick. All quotations are short and exact, from pages read on 17 October.

UK guidance as read on 17 October 2026, with CISA's directive for comparison, and where each stops.

Instrument	What it says	Where it stops
NCSC, Responding to active exploitation of vulnerabilities (version 2.1, 1 May 2026)	A table of CISA KEV listing, internet exposure, automation and total control. When all four are yes: install the update immediately, within 24 hours, with an assured Cyber Incident Response (CIR) provider. Isolate and replace with a new, up-to-date system if possible. Lists "remote access products" among the categories most often mass-exploited and invites replacing them.	Starts at KEV listing. The NCSC notes KEV reports only exploitation that has already occurred. It does not say how to investigate an appliance whose host the customer cannot audit.
NCSC, Policy: update by default (published 12 February 2024, reviewed 1 May 2026)	Internet-facing services updated within 5 days, operating system and applications within 7, internal systems within 14. If an internet-facing service is exploited, "investigate your exposure and check for signs of compromise before applying any update".	Business-as-usual timescales. They run from an update, not an advisory, and an update with no advisory is the case here.
Cyber Essentials, Requirements for IT Infrastructure v3.3 (April 2026)	Updates within 14 days of release where the vendor calls the fix critical or high risk, the CVSS v3 score is 7 or more, or the vendor gives no details. "Externally managed services (such as remote administration)" are in scope, and so are accounts used by an MSP. Unsupported software must be removed or taken out of scope.	The clock runs from release, not from the advisory. It requires no check for compromise. Remote Support below 24.3.1 gets no patch.
NCSC, Making forensic observability the norm for network devices (29 July 2026)	Defenders "should be able to investigate compromise using trustworthy information provided by the system". Buyers are asked to push for forensic capability as standard.	Written about firewalls, VPN gateways and network appliances. It does not name remote-support appliances.
NCSC, Choosing a managed service provider (24 November 2025) and Using MSPs to administer your cloud services (10 January 2023)	Patch critical or high-risk issues within 14 days, write incident notification and liability into the contract, check how the MSP's access is secured, and treat "a third attack surface".	Neither names remote-support platforms or asks an MSP whether its own remote tooling was on an exploited list. The first is for small organisations; the second concerns cloud administration.
ICO, Personal data breaches: a guide	Report to the ICO within 72 hours of becoming aware, where feasible, and in phases if needed. A processor must tell the controller "without undue delay" once aware. Document a decision not to report.	Applies only if personal data was affected. When awareness begins for an unconfirmed appliance compromise is left to the controller; the ICO points to guidelines this briefing did not read.
CISA, BOD 26-04 and the KEV entry	Due date 19 October, three days after listing, with forensic triage. The implementation guidance says to collect all required evidence before patching, "as patching may jeopardize the availability of artifacts".	Binds US federal civilian agencies only; CISA encourages others to follow it.

Four published clocks for one patched appliance. Starts and ends are derived readings; each depends on the reading stated.

Clock	Length	Starts	Ends for this flaw
NCSC update by default, internet-facing	5 days	Update published, 8 October	13 October, two days before the advisory
NCSC active exploitation, all four factors yes	Under 24 hours plus a CIR provider	KEV listing, 16 October	17 October, 18:15 BST
CISA BOD 26-04, forensic triage class	3 days	KEV listing, 16 October	19 October, federal agencies only
Cyber Essentials v3.3	14 days	Release, 8 or 9 October	22 or 23 October

The reading for this flaw is inference from published values. CISA's own enrichment of the CVE record, entered on 16 October, says exploitation is active, that it is automatable, and that technical impact is total. With the KEV listing, those cover three of the NCSC's four columns. The fourth, internet accessibility, is a property of each deployment, though an appliance has to be reachable by the customers and Jump Clients it serves, which is inference. The NCSC's row for that combination is immediate action, within 24 hours, with an incident response provider. The 24 hours from the catalogue release (17:15 UTC on 16 October) end at 18:15 BST on 17 October, the day this is written (derived). On that reading an internet-reachable appliance that is not yet patched is at the end of the NCSC's window today, while the Cyber Essentials clock has days left. The four clocks disagree because they answer different questions: how fast to patch, how fast to respond to exploitation, and how long a baseline certificate tolerates. None says what to do first when the patch exists, the advisory does not, and the evidence is on the machine the attacker controls.

Where Cyber Essentials and the ICO meet this flaw is the managed service. An organisation whose service desk uses a self-hosted appliance, or a supplier's, has the appliance's accounts in scope and a possible processor relationship for any personal data that crossed it. Whether the NIS Regulations 2018 or the Cyber Security and Resilience Bill apply depends on the sector and was not assessed for this briefing.

What to do, in the order worth doing

The order is by dependency, not importance: inventory before version, version before exposure, evidence before patch, patch before rotation. Three lists follow, for a service-desk owner, a managed service provider and a CISO. Each step is from BeyondTrust, Mandiant, CISA or the NCSC as cited above, at defender level.

What could not be verified

• The support articles. BeyondTrust's advisory and its two release notes point to two articles, one for Remote Support and one for Privileged Remote Access. Both returned a customer login page and were not read; no attempt was made to get round it.
• Victim count and timing. Two customers, one hosted and one self-hosted, are BeyondTrust's figure. When each customer was told is not stated, and a spokesperson declined to say how many are compromised.
• Whether the blog changed. It was last updated on 16 October at 12:00 EDT. No earlier copy was retrievable, so any change since 15 October is not known.
• PRA. BeyondTrust says its internal testing "has not identified any way" to exploit Privileged Remote Access. That is the absence of a finding, not proof, and its fixed version is not stated.
• Whether the patch is disruptive. BeyondTrust's two update settings are documented, but which one applies to this patch is not stated.
• CrowdStrike. No CrowdStrike report on this flaw was found. The Warp Panda link rests on BeyondTrust's blog, and CrowdStrike's December 2025 report was read only to confirm that it predates the flaw.
• Other firms confirming exploitation. The Record links a social media post that was not read.
• Exposure counts. BleepingComputer cites Shadowserver for over 1,400 exposed BeyondTrust remote support instances. The chart was opened but no value was read. Dark Reading cites around 11,000 earlier in 2026 from a different study of a different flaw. The two are not reconciled.
• The other vendor. BeyondTrust does not name the vendor whose exploited zero-day became public on 27 September. CyberScoop says the timing matches a Citrix NetScaler disclosure; BeyondTrust did not say whether the two are linked.
• Clock readings. That the NCSC and Cyber Essentials timescales run from a release, and which release, is this briefing's reading of the pages, and is labelled as such.
• Not read. The Article 29 Working Party guidance the ICO cites, the NIS Regulations 2018, Mandiant's earlier reports on the actor, and any indicators or detection rules, which are deliberately not reproduced.
• Time-stamped. Sources were read between 11:07 and 11:35 BST on 17 October 2026. A KEV due date, an advisory, a blog or a victim count could change within hours.

The question that exposes the gap

If an attacker had root on your remote-support appliance on 29 August, which record would tell you so today, and does it live anywhere the attacker could not delete it?

Key facts