CVE-2026-102764: BeyondTrust Authentication Bypass and Patch Guidance

CVE-2026-102764 affects BeyondTrust Remote Support, and exploitation has been confirmed. Organizations need to establish two separate facts: whether the appliance received the security patch and whether an attacker accessed it before that patch arrived. A successful update answers the first question. It cannot, by itself, answer the second.

The distinction matters for an appliance that brokers privileged access. An investigation may have to extend from appliance integrity to account permissions, credentials, and systems reached through remote sessions. The practical response is to track patch completion and compromise assessment independently, then join their evidence before closing the incident.

What the advisory establishes

O BeyondTrust BT26-05 advisory describes inadequate origin validation in an internal messaging component. An unauthenticated remote attacker can perform file operations under the relevant conditions. BeyondTrust rates the issue Critical, with a CVSS v4 score of 9.3, and identifies Remote Support versions through 26.2.3 as affected. Those are the disclosed vulnerability boundaries; they do not describe a public, universal request that directly returns a root shell.

Origin validation asks whether a message actually came from an entity entitled to invoke an operation. A service can have a login screen and still contain a separate component that incorrectly trusts a message. In that design, the failure occurs before the ordinary account permission model can provide the protection an administrator expects. This is why verifying that an external login page requires credentials does not establish that this vulnerability is absent.

O CWE-290 classification concerns authentication bypass through spoofing. It does not identify a specific HTTP header, API route, or transport in this product. The term “origin” does not establish a browser Origin-header flaw. BeyondTrust has withheld exploitation-enabling details, so the public advisory does not support an endpoint-specific test or an Origin-header workaround.

The incident evidence is broader than the flaw description. Mandiant’s ARMORY CASTLE investigation describes exploitation in late August 2026, followed by privilege escalation and further intrusion activity. Initial unauthorized file access, operating-system privilege, and application account privileges are different stages. They should have different evidence requirements in an investigation, even when they occur on the same appliance.

Which deployments need action

The patch is identified as BT26-05-RS. The following matrix condenses the vendor’s deployment guidance; it is a snapshot checked on October 17, 2026. Record the actual patch result for each instance rather than deriving it from the product’s release number alone.

The PRA row needs qualification. In its October 16 incident update, BeyondTrust says Privileged Remote Access shares affected code, but its internal testing had not identified an exploit path in PRA. It issued a precautionary patch. That is different from confirming PRA exploitation, and different from establishing that every possible PRA deployment is unaffected.

The same update dates patch release to October 8, while the security advisory says all Remote Support SaaS customers had received the patch by October 9. Release and fleet completion are different milestones. For a self-hosted instance, neither date replaces the local installation record. An instance with automatic updates disabled needs particular attention, but an enabled update setting is still an intention, not evidence that a particular update finished.

Build the inventory around the appliance or tenant, not a spreadsheet row labeled only “BeyondTrust.” Include the product, deployment model, version at the time of exposure, current version, patch state, and owner. Keep former versions when they are available. A current inventory can show that an instance is fixed today while concealing the period in which it was vulnerable.

Separate exposure from evidence of intrusion

BeyondTrust’s public account identified two affected customers as of its October 16 update, and said it had no evidence of activity after August. Those limits belong beside the exploitation claim. They establish that exploitation occurred; they do not establish that every exposed customer was compromised or that attacks are currently occurring at every vulnerable installation.

For triage, use two independent axes. The first is exposure: an affected deployment existed, was reachable through the relevant paths, and had not yet received the correction. The second is investigative evidence: unauthorized file activity, unexplained permission changes, suspicious sessions, or corroborating host artifacts. High exposure with incomplete logs is an unresolved case, rather than a clean case. A confirmed suspicious role change on a patched appliance remains significant even though the vulnerability scanner now reports success.

This matrix is an analytical model, not a vendor detection rule. Its purpose is to prevent one type of evidence from being used to answer a different question. A patch result has strong relevance to future exposure. A permission-change event has relevance to account integrity. Neither is a substitute for reconstructing the other’s timeline.

A small offline filter for permission changes

Mandiant’s report includes JSON events with an event type of user_changed and flattened fields describing old and new default Jump Item roles. That makes permission changes a useful investigation pivot. A change to Administrator deserves review, especially if it has no corresponding change request, but it is not a signature unique to this intrusion.

The Python 3 helper below reads a local, normalized JSONL export from standard input. Each line must be a JSON object with the field names shown in the report. It selects transitions into Administrator for the user or team default Jump Item role. It does not connect to an appliance, parse every native syslog format, identify an exploit request, or establish that a selected change was malicious.

import json
import sys

ROLE_FIELDS = (
    "permissions:jump_item_role:default:name",
    "permissions:jump_item_role:teams:name",
)


def review_reasons(event):
    if event.get("event") != "user_changed":
        return []
    reasons = []
    for field in ROLE_FIELDS:
        before = event.get("old_" + field)
        after = event.get("new_" + field)
        if isinstance(before, str) and after == "Administrator":
            if before != after:
                reasons.append(field)
    return reasons


for line_number, line in enumerate(sys.stdin, 1):
    if not line.strip():
        continue
    try:
        event = json.loads(line)
        if not isinstance(event, dict):
            raise ValueError("expected a JSON object")
    except (ValueError, TypeError) as error:
        print(f"line {line_number}: {error}", file=sys.stderr)
        continue
    reasons = review_reasons(event)
    if reasons:
        print(json.dumps({"line": line_number, "review": reasons}))

Save it as review_roles.py and run it against an authorized local export:

python3 review_roles.py < normalized-events.jsonl

The output contains input line numbers and the fields that triggered review. It deliberately omits the full event so that usernames and other sensitive contents are not copied into another output by default. Keep the original export unchanged and use the line number to retrieve context. A line number is an index into that exact file, not a stable event identifier across exports.

We executed this helper locally against synthetic fixtures covering a default-role increase, a team-role increase, an unchanged administrator role, a downgrade, an unrelated event, missing fields, malformed JSON, and a JSON value that was not an object. The two increases were selected; malformed input was reported separately. This validates the helper’s filtering behavior on those fixtures. It is not a reproduction of the vulnerability or a validation against a customer appliance.

The filter intentionally requires both an old string value and the exact new value Administrator. Missing old values therefore remain outside its matches. Different localization, nested exports, renamed fields, or a collector that drops keys require an explicit normalization step. Test the mapping against a known authorized role change before trusting a zero-result run. Do not silently translate missing data into “no privilege increase.”

An expected administrative change will produce a match, so the next decision comes from change records, actor identity, source address, adjacent sessions, and the affected account’s use afterward. Conversely, an attacker could act through an existing privileged account without producing this transition. The helper narrows a review queue; it does not bound the incident.

Log coverage determines what a negative result means

BeyondTrust’s Remote Support syslog documentation describes events generated by the appliance interfaces and clients. It documents remote syslog configuration under /appliance > Security > Appliance Administration, support for up to three destinations, and a Syslog over TLS option. Cloud-specific settings have separate documentation. Use the instructions for the actual deployment rather than assuming self-hosted settings apply to a SaaS tenant.

For investigation, configuration is only the starting point. Establish when forwarding began, whether the receiver accepted messages throughout the exposure window, what filters were applied, and whether retained data includes the event families under review. A collector with thirty days of retention cannot clear an August exposure in mid-October. A TLS setting protects a transport connection; it does not prove the collector retained every event needed for the case.

Preserve time information carefully. Record the appliance’s timezone, the receiver’s timestamp behavior, and any observed clock offset. Avoid converting a rough timestamp into an exact sequence that the records cannot support. If two events have uncertain ordering, keep that uncertainty visible rather than assigning causality based on their display order in a search result.

Off-appliance records are especially useful when host integrity is in question, but they also need provenance. Retain an original export, its collection time and scope, and an integrity hash. Perform parsing and normalization on copies. If a parser rejects records, preserve the rejection count and examples. A successful search over a silently truncated export can be less informative than a failed search that clearly identifies the missing interval.

Patch completion and incident closure need separate owners

An appliance team can finish the update while an incident team is still evaluating prior access. That is a reasonable intermediate state. Problems arise when a single “remediated” field hides the difference and downstream teams assume that credentials and connected systems have already been reviewed.

These are recommended acceptance criteria rather than a claim that every customer must rebuild every appliance. The response should follow the evidence and the vendor’s recovery guidance. If compromise is suspected, coordinate evidence preservation before disruptive actions. Rebuilding a system can remove valuable local artifacts, while leaving reusable credentials untouched can preserve an attacker’s access elsewhere.

Credential recovery also has ordering constraints. Rotating a secret while an attacker still controls the system receiving the replacement can expose the new value. Plan containment, restoration, rotation, and validation as related actions. Identify which team owns each dependent system and record exceptions explicitly, including compensating controls and a time to revisit them.

The useful final deliverable is a record that another engineer can audit: which instance was exposed, when it was corrected, which evidence was examined, what could not be recovered, and why the remaining risk is acceptable. CVE-2026-102764 demands urgent patch verification. Its confirmed exploitation also demands that “patched” retain its precise meaning, so that historical intrusion assessment is completed rather than accidentally closed.