Active threat · 2 Nov 2026
If you run self-hosted BeyondTrust Remote Support, apply BT26-05-RS today, and don't stop there: the patch closes the hole but removes nothing an attacker already left behind. The flaw was exploited for weeks before a patch existed, and Mandiant says an appliance reachable from the internet on a vulnerable version "should be treated as potentially compromised until it has been reviewed". Your exposure window runs from 29 August to the day you patched, and since 30 October the exploit chain is public.
BeyondTrust disclosed the flaw on 15 October. CISA added it to the Known Exploited Vulnerabilities catalog on 16 October with a three-day federal deadline and a forensic triage requirement. Two compromises were known at that point, both dated 29 August: one BeyondTrust-hosted instance and one self-hosted appliance. Mandiant found the zero-day during an incident response engagement and attributes the activity to ARMORY CASTLE, a suspected PRC-nexus espionage actor formerly tracked as UNC5221.
What changed last week: Rapid7's analysis of 30 October explains the bug end to end, and pull request #22083 adds it to Metasploit. When we checked on 2 November the pull request was still open and unmerged, and Rapid7 had tested only version 24.1.2. The write-up is detailed enough to reproduce anyway. Mandiant had already warned of widespread opportunistic exploitation after disclosure. Shadowserver counted more than 1,400 exposed Remote Support instances in October, with no figures on how many were patched.
The bug itself is an origin check that trusts the wrong thing. Remote Support's internal message router rejects network messages claiming its real router ID, but not a reserved local alias. A guest session, which the public customer portal hands out without credentials, can forge that alias and reach the native file-transfer service. From there, Rapid7 wrote a PHP file into the web root and ran it as the site user.
The blast radius is the real issue, because this appliance brokers privileged access to internal systems. In the case Mandiant investigated, the attacker went from webshell to a SUID root shell, ran bt-secrets against the vault, added boot persistence, wiped logs, then signed in to /login with a compromised Administrator account. Jump Item and Team permissions were raised from "No Access" to "Administrator", and documents left through the product's own file transfer. Mandiant says this gave the attacker access to "every credential the appliance stored or brokered".
CISA already lists three earlier Remote Support flaws as exploited: CVE-2024-12356, CVE-2024-12686 and CVE-2026-1731. Treat this box like an identity system, not a helpdesk tool.
/appliance interface, even if automatic updates are on.Not sure what you run? Search your asset list and external scans, try stack check, and ask your MSPs: a supplier's support appliance can reach into your network too.
If the appliance is still unpatched, or anything below turns up, treat it as suspect. Mandiant's advice: snapshot virtual appliances with memory and export the disk "before any change or reboot", block inbound traffic at the firewall rather than in /appliance, and disable rather than delete so the audit trail survives. Then apply BT26-05-RS from /appliance and confirm it shows as installed.
The published indicators describe one espionage intrusion, and the Metasploit traces look different, so check for both. Use logs from your SIEM, reverse proxy or WAF as well as the appliance, because this actor deleted local logs.
Espionage artefacts (Mandiant): mangoapi.php (SAWFLY webshell), ingredi_ws (BARECLAW tunneler), /usr/bin/dbus-authd, /home/bomgar/sbin/post_boot.d/zz-root-persist, and a /uidchanarge route in /ns/config/haproxy.conf. Mandiant's post has the hashes and YARA rules. BeyondTrust offers a further hunting package through its trust portal.
Exploit-chain traces (Rapid7): POST /api/start_session followed by requests to unfamiliar paths, a 200 then 404s on the same path, and .php requests returning 404 while the extensionless path returns 200. The uploaded PHP file deletes itself, so a clean web root proves nothing. These entries are normal on their own, so correlate them with file changes and outbound connections.
For a first pass over exported proxy or access logs:
# Known Mandiant paths: any hit is an incident
grep -E 'uidchanarge|mangoapi|app_84304470' access.log
# Exploit pattern: review what follows each hit, from 29 August on
grep -n -A5 'POST /api/start_session' access.logThen review inside the product, against a baseline from before 29 August:
user_changed events that raise a Jump Item or Team role, and user_added, api_account or security_provider events without a change ticket./login successes from residential broadband or commercial VPN addresses, and admin logins outside business hours.No hits is not a clean result: BeyondTrust warns that an absence of known indicators does not prove an appliance is clean.
If compromise is confirmed or you can't rule it out, Mandiant's advice is "rebuild rather than clean": redeploy from a clean, fully patched image. The persistence it found was built to survive reboots.
Only then rotate credentials. Mandiant is explicit that rotating earlier "exposes the new credentials to an attacker who still controls the appliance". Include admin and API accounts and everything the appliance stored or brokered.
Finally, widen the scope. "Every endpoint touched is in scope for downstream hunting," Mandiant says, so list the systems reached through sessions and Jump Items in the window and hunt there too. If any of them sit in your cardholder data environment, bring your PCI DSS assessor in early.
Having an unpatched appliance is not in itself a reportable incident. A confirmed compromise may be, and the clock will be tight: NIS2 expects an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report no later than a month after that. Documents taken over file transfer may also be a GDPR question. Our incident reporting clock lines up the deadlines. This is our engineering reading, not legal advice.
/login and /appliance by IP, and put a reverse proxy or WAF with full URI logging in front.New exploited entries appear in our KEV digest; KEV and EPSS covers the patching logic.
Yes, in practical terms. Rapid7 published the full exploit chain on 30 October 2026 and submitted a Metasploit module as pull request #22083, which was still unmerged on 2 November. Assume capable attackers can reproduce it.
BeyondTrust patched SaaS tenants by 9 October 2026, so there is nothing to patch on the appliance. You should still review credentials and configuration, because one hosted instance was compromised on 29 August.
No. The patch does not remove webshells, persistence or stolen credentials. If the appliance was internet-reachable while unpatched, review it for compromise, rebuild it if you can't clear it, and then rotate credentials.
We help EU regulated teams scope exposure, hunt through off-box logs, and set up the SIEM forwarding that makes the next review possible.
Get in touch →