How We Found a Critical Microsoft HPC Flaw, No Password Required
Earlier this year, the Abacus R&D team found a way to take control of a Microsoft High-Performance Computing (HPC) Pack cluster with a single network message. No account, no password: one message sent to the cluster’s scheduler was enough to run code on the server that coordinates the whole system. From there, our testing showed the same access could reach the compute nodes the scheduler manages, putting the entire cluster within reach.
Understanding the critical impact this vulnerability could have on organizations around the world if left unaddressed, we reported it to Microsoft privately, before there was any sign it had been exploited. It’s now tracked as CVE-2025-55232, rated 9.8 out of 10 on the standard severity scale, and it’s been patched.
Here’s how the flaw worked, and what it means if your business runs on high-performance computing.
What Microsoft HPC Pack Actually Does
High-performance computing exists for jobs that are too big for a single machine. Instead of running everything on one computer, you spread the work across many. HPC Pack is Microsoft’s software for managing that. It takes a large workload, like a detailed financial model or a long-running simulation, breaks it into smaller pieces, and hands those pieces out to a group of machines that run them at the same time. Work that might take one server several days can finish in a few hours.
The setup is built around two roles. A small number of servers act as coordinators: they schedule the work and assign it out. A much larger number of computers, known as clients, do the computing, checking in with the servers, running what they’re given, and sending results back. A single deployment often has a handful of servers directing hundreds of clients. For any of this to work, every client has to be able to reach the servers over the network. That openness is exactly what an attacker needs.
How & Why Our R&D Team Went Looking
The Abacus R&D team spends its time pulling apart widely used software the way an attacker would, looking for weaknesses before criminals get there first. Our objective is to proactively protect our clients and the industry as a whole from emerging threats. With HPC Pack, we started with a basic question: what’s it actually built from?
Its structure and file signatures showed it was written mostly in C#, one of Microsoft’s common programming languages. That’s useful to know, because C# programs can be run through a decompiler, a tool that turns finished software back into something close to its original source code. In effect, we could read how HPC works from the inside, as if we had the design documents, and find weak points without having to run it and watch every step.
Confirming HPC Pack is built on C# and the .NET framework, which made decompilation possible.
Our experts paid closest attention to the services HPC exposes to the network, since anything reachable over the network is reachable by an attacker too. The encryption and login checks on those services held up reasonably well. The weakness was deeper in, in the code that receives and schedules jobs.
Part of the decompiled code the team reviewed while checking how HPC handles secure connections.
A Single Message to One Port
Networked machines expose their services on numbered ports so other machines know where to reach them. The HPC Job Scheduler listens for jobs on port 5999. Messages arriving there come in a set format, with an expected order, and to read that format the software uses a process known as deserialization: which turns incoming data back into a structured object in memory.
The problem was the implicit trust of incoming data as well as the order things happened in. The scheduler unpacked whatever arrived on that port before checking who sent it or whether the contents were safe. An attacker could send a message dressed up as a job, and when the scheduler unpacked it, it would run the attacker’s code instead. This kind of weakness is called insecure deserialization, and here it led to remote code execution: running commands on a machine you don’t control, over the network.
Two things made it worse. Because the incoming messages were deserialized before any login check, the attacker needed no credentials at all. Additionally, installing HPC opened port 5999 in the Windows firewall automatically, so a standard install left that door open to the network from the start.
Installing HPC opens port 5999 to the network automatically, with no manual setup.
The core of the flaw: the scheduler unpacks incoming data before confirming who sent it and whether it matches the expected format.
Why the CVE Was So Dangerous
The vulnerable service our team identified runs on the servers, the machines that coordinate programs and store data across an environment. But if a cyber criminal compromised one server, it wouldn’t mean the threat ends there. Because the servers push work out to every client beneath them, an attacker with a foothold is in position to send malicious code downstream to the connected machines. In our testing, that’s what a single message could set in motion across a cluster.
For a business, this means a threat actor would be able to reach one of its most critical, widespread assets: its data. These clusters often process a company’s most sensitive material, or even personally identifiable information (PII): the kind of financial and proprietary data that isn’t supposed to leave the building. A successful attack could expose that data, corrupt work in progress, or shut down operations the business depends on, all from one unauthenticated message.
Proving It Out
To confirm the flaw was as serious as it looked, the team built a proof of concept: a small, self-contained test that safely shows a vulnerability is real and exploitable. Ours sent a crafted message to the scheduler and, before any credentials could even be checked, ran a harmless command on the target to show that code was executing. It worked as expected.
A controlled proof of concept which confirmed unauthenticated code execution against the scheduler service.
The proof of concept successfully dropped a file to the path as the system user itself.
The Outcome: CVE-2025-55232, Patched With Microsoft
Finding the flaw first meant we could report it privately to Microsoft instead of watching it circulate. When a vulnerability is confirmed, it’s logged in a public, industry-wide catalog under a unique ID called a CVE (Common Vulnerabilities and Exposures), so defenders everywhere can track the same issue. This one is CVE-2025-55232. It was rated 9.8 out of 10, and Microsoft’s security team had it patched before there was any sign it had been used in the wild.
Microsoft also recognized the team’s work, inviting several of our researchers to the Microsoft Security Response Center (MSRC) event at Black Hat and DEF CON, two of the longest-running gatherings in the field. This acknowledgement is a testament to the hard work of the Abacus Cyber R&D, who are continuing to stay focused on proactively identifying more vulnerabilities and innovating new processes and tools that will allow us to more securely and efficiently support our clients.
What This Means for You
If your organization runs Microsoft HPC Pack, the first step is straightforward: make sure the patch for CVE-2025-55232 is applied everywhere it’s installed and confirm port 5999 isn’t exposed beyond your trusted network. If either one is unclear, it’s worth sorting out now rather than later.
This is the sort of work our R&D team does for the clients Abacus protects: taking apart the software businesses depend on and closing the gaps before anyone else finds them. Most of what we find never makes the news. That’s usually the point.
If you’d like to talk through your own environment, or you’re not sure whether something like this affects your firm, connect with our team.