TL;DR: CVE-2026-40138 and CVE-2026-40139 are pre-authentication flaws in BeyondTrust Remote Support and Privileged Remote Access that can let attackers bypass login controls on exposed appliances, according to CYCOGNITO. The risk is not just patching speed but the governance gap around internet-facing remote access, privileged entry points, and third-party-managed instances.
NHIMG editorial — based on content published by CYCOGNITO: What are CVE-2026-40138 and CVE-2026-40139?
By the numbers:
- CVE-2026-40138 and CVE-2026-40139 affect versions 25.3.2 and earlier of BeyondTrust RS and PRA.
- 16.8% of observed assets, ccounts for 16.8% of observed assets, ahead of Health Care at 14.4%.
Questions worth separating out
Q: What fails when a remote-access appliance allows pre-authentication login bypasses?
A: The failure is at the trust boundary.
Q: Why do internet-facing support portals increase privileged access risk?
A: They concentrate remote entry into a single externally reachable control point, often with administrative or third-party access attached.
Q: How do security teams know whether a vulnerable remote-access instance is actually exposed?
A: They need both version data and configuration data.
Practitioner guidance
- Inventory every exposed remote-access appliance Build a live list of all internet-facing BeyondTrust RS and PRA instances, including vendor-managed and third-party-operated deployments, then verify patch state against the affected version range.
- Validate the active authentication configuration Confirm which authentication mode each appliance is running, because exploitability depends on specific enabled settings and version checks alone may miss exposed code paths.
- Restrict login interfaces to trusted source ranges Limit access to RS and PRA login portals from known network ranges and approved administrative paths, especially while any self-hosted instance remains under review.
What's in the full analysis
CYCOGNITO's full article covers the operational detail this post intentionally leaves for the source:
- Exact version scope and remediation guidance for Remote Support and Privileged Remote Access appliances
- The specific authentication configurations that influence exploitability and how to validate them
- Exposure patterns by sector and deployment model, useful for prioritising remediation
- CyCognito's recommended review workflow for internet-facing instances and elevated accounts
👉 Read CYCOGNITO's analysis of CVE-2026-40138 and CVE-2026-40139 in BeyondTrust RS and PRA →
BeyondTrust RS and PRA login bypasses: what should defenders do now?
Explore further
Standing trust in remote-access gateways is the real failure mode: these appliances are often treated as controlled entry points, but a pre-authentication bypass turns that assumption into an access-control collapse. The problem is not simply that a patch is missing, but that the trust boundary around privileged remote support was broken before identity was established. Practitioners should treat the login gateway itself as a governance object, not just a service endpoint.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when an exposed access appliance is exploited?
A: Accountability usually spans infrastructure operations, security operations, and the identity team when the appliance brokers authentication or access policy. The organisation needs a clear owner for exposure monitoring, emergency isolation, patch timing, and post-incident verification. Access infrastructure cannot sit in an ownership gap if it forms part of the trust boundary.
👉 Read our full editorial: BeyondTrust login flaws show how exposed remote access breaks trust