A 9.9 CVSS bug in your remote access tool is now in ransomware campaigns
The short version
On February 6, 2026, a pre-authentication remote code execution vulnerability was publicly disclosed in BeyondTrust's Remote Support and Privileged Remote Access products. Tracked as CVE-2026-1731, it carries a CVSS score of 9.9 out of 10. An attacker can send a crafted request to an exposed instance and run operating system commands without any credentials at all.
That alone would be bad enough. But the timeline here is what makes this one worth paying attention to.
BeyondTrust's own security team first detected anomalous activity on January 31, before the CVE was even assigned. By February 2, cloud instances were patched. The public advisory came February 6. A proof-of-concept exploit dropped on February 12. CISA added it to the Known Exploited Vulnerabilities catalog on February 13 and gave federal agencies three days to patch or stop using the product. And as of this week, CISA has flagged CVE-2026-1731 as actively used in ransomware campaigns.
From zero-day to ransomware weapon in roughly three weeks.
Why this one matters more than the average CVE
Remote support tools are, by design, some of the most privileged software in an enterprise environment. They exist to let someone reach into a machine and control it. When that access doesn't require authentication, you don't have a vulnerability. You have an open door.
BeyondTrust isn't a niche product. According to security researchers, there are roughly 11,000 internet-facing instances, about 8,500 of which are on-premise deployments that require manual patching. The vendor serves over 20,000 customers across 100+ countries, including 75% of the Fortune 100. The blast radius here is real.
And there's a pattern. In late 2024, Chinese state-backed group Silk Typhoon exploited two different BeyondTrust zero-days to breach the U.S. Treasury Department. That incident involved chaining vulnerabilities, including one in an underlying PostgreSQL tool that wasn't publicly known at the time. The same product family, the same kind of flaw, different year. That pattern should worry anyone running these tools.
What we're telling our clients
During our penetration testing work with gaming studios and enterprise clients, we regularly encounter remote access tools that are internet-facing and running outdated versions. It's one of the most common findings. Teams install these products, they work, and then nobody thinks about them again until something like this happens.
Here's what we're recommending right now:
Patch immediately if you haven't already. Self-hosted BeyondTrust Remote Support users need version 25.3.2 or later. PRA users need 25.1.1 or later. If you're on SaaS, you were auto-patched on February 2, but verify it. Don't assume.
Check for compromise during the vulnerability window. If your instance was internet-facing and unpatched before February 9, treat it as potentially compromised. Review session logs, look for unusual account activity, and check for unauthorized access patterns. BeyondTrust is recommending affected self-hosted customers open a Severity 1 ticket.
Stop exposing management interfaces to the public internet. This is the bigger lesson. Palo Alto's Unit 42 team put it well in their analysis: defense-in-depth means limiting administrative interfaces to internal, segmented management networks or zero-trust access gateways. When a new variant of this kind of flaw appears (and it will), your management plane should be shielded regardless.
Audit your remote access tool inventory. Most organizations we work with don't have a single remote access solution; they have three or four, accumulated over years of different teams making different choices. Shadow IT remote access is a real problem, and each one of those tools is a potential entry point.
The bigger picture for development teams
This CVE is a security story, but it's also a development and infrastructure story. If you're building and deploying web applications (we do this daily with PHP, Docker, and cloud infrastructure), your CI/CD pipelines, staging environments, and production servers are all potential targets for this exact class of attack. Remote support tools touch the machines where your code lives.
When we build cloud-native apps for enterprise clients, especially those with Swiss compliance requirements, we design network segmentation into the architecture from day one. The idea is simple: if a tool in your environment gets popped, the damage should be contained. Not every organization thinks this way, and the ones that don't are the ones scrambling right now.
For native mobile development teams, the risk is a bit different but still real. Build servers, device farms, CI infrastructure: these all have remote access surfaces. In our iOS and Android work for healthcare and IoT clients, we've seen environments where the build infrastructure was more exposed than the production app. That's backwards.
One thing you can do today
Run a scan of your public-facing IP ranges for any remote access or remote support tool endpoints. Not just BeyondTrust; any of them. Tools like Shodan or Censys can help, or just check your firewall rules. If you find management interfaces exposed to the internet, move them behind a VPN or zero-trust proxy before the next CVE drops. Because it will.
The speed at which CVE-2026-1731 went from disclosure to ransomware exploitation is a reminder that patch windows are shrinking. You either have a process for this or you get caught.
If tightening up your remote access exposure or auditing your infrastructure security sounds like something you need help with, let's talk.