Back to blog

BeyondTrust BT26-05: patch the appliance and investigate prior access

2 min read
BeyondTrust BT26-05: patch the appliance and investigate prior access

Sources checked: . FailSafe Research.

A newly published patch can address an intrusion that started earlier. Remote-support owners need both deployment evidence and an investigation decision for the pre-patch window.

What was disclosed in October

BeyondTrust’s BT26-05 advisory identifies CVE-2026-102764 in Remote Support, involving insufficient validation in an internal messaging component. Its response account describes zero-day exploitation in late August and coordinated disclosure in October. Mandiant’s incident analysis reports the related activity it investigated.

This is an October disclosure, not a claim that the initial attack began in October. Self-hosted owners should follow the vendor’s patch instructions and product-specific scope. The response distinguishes confirmed Remote Support exploitation from precautionary patching of shared code in Privileged Remote Access.

Remote support carries business-wide authority

Inventory appliances, hosted instances, operator accounts, connected endpoints and integration credentials. Determine which controls limit an operator’s session and which independently approve a sensitive action. Include recovery and emergency-access identities.

The assessment should ask what becomes reachable if the support layer is untrusted. A system that can administer many endpoints deserves more than a check that its public login requires MFA.

Keep patching and compromise assessment separate

Record the running version, patch state and rollout coverage. Preserve relevant logs and follow vendor or incident-response guidance for earlier access. A patch closing the entry route does not by itself prove that an attacker left no accounts, sessions or changes.

For active validation, reproduce the required security properties in an isolated authorized environment. Review origin and identity checks, role boundaries, session expiration and access to unrelated targets. Do not use public proof-of-concept code against a production appliance simply to obtain a screenshot.

What to request in a FailSafe engagement

FailSafe SWARM can test agreed application, identity and infrastructure paths with a defined evidence standard. Ask for the reachable privilege transition, the affected business capability and the specific retest that will demonstrate a fix.

For sensitive support or infrastructure workflows, private assessment hosting and inference can keep processing inside an approved boundary. Historical intrusion assessment still requires the incident team’s evidence and methods.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

The vendor and Mandiant describe late-August exploitation, disclosed publicly in October.

No. Confirm the deployed fix and separately investigate the earlier exposure window using appropriate evidence and vendor guidance.

Put this guidance to work

Discuss a scoped FailSafe SWARM assessment with reproduced findings, engineering handoff and remediation retesting. Containment and forensic investigation remain separate workstreams.

Test the boundary that matters