For many years your common or garden variety penetration tester followed the path of least resistance; just like the average hacker. 

Any nmap-wielding wizard might have pointed a scanner at a target IP range; run a check for misconfigured environments; perhaps done a little password spraying at exposed login portals. Maybe, if feeling energetic, they might have also run a scan for unpatched and exploitable software vulnerabilities; or, scope permitting, sent a phishing email or two.*

Now a competent penetration tester armed with access to a good frontier model and a generous scope can find zero days even in extensively scanned and fuzzed enterprise software like that from VMware. 

Phil Brass and his colleague Matt South, from security consulting firm Atredis Partners are a case in point. In a recent in-depth penetration testing engagement for an unnamed client, they found a pair of critical vulnerabilities in VMware’s vCenter Server Appliance (VCSA) that gave them root on their sophisticated client’s private cloud environment.

(VCSA is the "single pane of glass" to manage VMware environments and unlocks a lot of enterprise features; it is, in short, a rich target.)

Critical vCenter vulnerabilities found with AI

One was CVE-2026-59310, which gives an unauthenticated attacker remote code execution RCE as root via misconfiguration in the rsyslogd configuration file – Atredis Partners has a detailed technical writeup here. 

The other was CVE-2026-59309, which is an authentication bypass vulnerability in the VMware Directory Service. Both require network access to vCenter to exploit (more below) and are somewhat painful to patch, as VMware admits they cause “back in time” errors for some users.

(Don’t let that put you off patching; exploitation is ongoing in the wild. VMware patched the bugs on July 29. German security company Quirso spotted attacks during incident response for a client and believes they started on August 3; attackers have been seen dropping Babuk ransomware. VCSA should not be accessible from a public network...)

Speaking to The Stack, Phil Brass, talked us through the penetration testing engagement, how he and his colleague Matt South found the CVSS 9.8 bugs and what it says about how cybersecurity is evolving.

Transcript lightly edited for brevity and clarity:

Q: What was the job?

We were assigned an internal [network] penetration test.. the duration was a month. Because the duration was big enough, I thought we could probably get somewhere if we gave some LLMs some research tasks.

Once the penetration test started, we found out that [the target private cloud environment] was VMware, and it was managed by vCenter.

I wasn't an expert in VMware, especially [at] enterprise scale, but I thought, "okay, let's just download it, get it installed on my Linux laptop." 

Q: What tools and safeguards did you use?

One of the things I wanted to make sure was that we weren't going to expose any of my client stuff to the LLM: The LLM is going to look just at VMware on an isolated computer. That computer is a Linux laptop that had a plugin [the code mode MCP server for Binary Ninja, a reverse engineering/binary analysis tool] that let the LLM talk to it.

I had VMware workstation and I had downloaded some ISOs of VMware ESXi server, using the exact version that the client had – we hit the network, and we were like, "oh, it's this version and that version."

Q: What did you prompt the LLM with?

The LLM was very good at kind of its own initiative, but also we started to develop a methodology.: ‘Hey, I want you to do a configuration review of all of the services that are listening!” and because they're all binaries, “I want you to look at all the shared libraries that they're linked to, and also all the libraries that are statically linked inside the binary. See if any of those are open source libraries, and exactly what version they used.”

[It was] almost like building a software bill of materials by reverse engineering, and it was also very good at that. And so we found a few [other] vulnerabilities that way, not the ones we’re talking about, though.

Q: What then?

Then we reverse engineered the binaries, turned them into source code, and then using Binary Ninja, looked for vulnerabilities in the source code. 

[Of ] the two big [VMware] vulnerabilities we found, one of them lets you... construct a directory and then put a file called <hostname>-syslog.log, with no secure-path handling  in that directory… you could end up anywhere on the file system; that syslog server was running as root.

The LLM found that 30 minutes after I downloaded vCenter. I literally got vCenter up and running; next thing you know, I have arbitrary file write.

I was pretty stoked, but it was still just arbitrary file write.

See also: Citrix credits JPMorgan, pushes fixes for six ugly NetScaler bugs

I was like, “okay, let's turn this into root.” And it [the LLM] would [respond] “I don't think you can get root because every time we try this, the first line of that file is going to start with a timestamp, and the file name always ends in -syslog.log. [Editor’s note: The researchers couldn't just drop their malicious file and instantly take over the server. The syslog service adds timestamps to the text and .log to the filename, which corrupts initial exploits and causes the system's task scheduler to reject them as invalid.]

I did my thinking, but I couldn't come up with anything. The LLM was looking through a whole bunch of different places in the file system on a Linux box, which is kind of what vCenter is – it's not really Linux, but it's Linux enough – and eventually, it was like, “you know, yes, in /etc/bash_completion.d/  every file in that directory gets loaded if someone logs in, no matter what the extension is, and it gets run by the shell, right?

Bash just ignores commands it doesn't understand; it doesn't stop executing the shell script just because you had a typo. It just skips that line, so the fact that the first line was a timestamp? No big deal.

Q: What did that enable?

“It let us put a file in a place that would then allow us to get that file executed whenever someone logged in, or an important service was restarted, but I couldn't guarantee that anyone was going to log in. I did have some denial of service-type crashes that might allow a service to get restarted, but I didn't want to crash anything on my client side. 

So I said, “okay, now let's see if there's any way to trigger this other than that.” After a bit more searching, the LLM found that there was a service on a different port that was listening, and you could send it a login request – it didn't have to be a valid login request, any login request – and during that login request, it would run as root, a script that would basically source a file called /etc/profile which would then take everything in bash_completion.d and run it. So just by sending this failed login request, I could get our payload executed as root. That was the end of the simple exploit chain. There's a more complicated chain that we built later that cleans up after itself… Anyhow, so that's how it was found!

[Missed the earlier link and want fuller technical details? See here.]

Q: So, found with a lot of AI?

It was found almost exclusively by LLMs. 

We decided early on that was going to be our approach before we started the engagement. We're like, “we have a lot of time. It's a sophisticated client. We're pretty sure that normal scanning isn't going to find anything, so let's just jump right into a high-end reverse engineering project.”

Q: You mentioned it was 30 minutes to an arbitrary write. How long did it take you to get that complete initial exploit chain?

I believe it was about another half hour. It was very quick.

Q: What LLMs/harnesses were you using?

I have Claude Max and Codex Max plans. I use them both for different things. I'm cyber verified on both of them: They'll sometimes [still] give me refusals, but most of the time they'll let me do stuff. And Claude in particular is more than happy to write exploits with me.

Q: VCSA needs to be exposed to exploit these. Is that common?

It should never be exposed to the internet. It depends on the organization, right? Like, there is no need for it to be generally exposed.

If VCSA is the administrative front-end [for your VMware environment] then ideally any organization that's got a good mature networking setup would have put it on a [segmented] administrative network... 

Q: But?

In large virtualization environments who needs access to which VMs, and that all can become a mess quickly, right? So sometimes people will make a flat network – everyone can talk to all of the VMware boxes. 

Q: That doesn’t sound like your client?

In the case of our penetration test, [the client had given us a task that] assumed breach of a highly privileged, highly isolated internal network.

They literally stuck our laptop on this super isolated network and gave us the ability to talk to the laptop, and then from the laptop we could talk to vCenter. But pretty much no one else in the organization could [do this.]

Q: That's a cool pentest engagement!

Yeah, they needed to see if their hardening goes all the way down. 

To do good defense in depth, you need to test at the different depths that you have. I think it was valuable for them, and valuable for Broadcom.

I think this is how pentests are changing, though. I'm seeing it a lot in the engagements we do at Atredis, where you run into some third-party software during an internal or external penetration test, and you start throwing the LLMs at it while you're doing the rest of your work.

It's simplifying things to say it's a “zero-day factory”**, but effectively, you're like, “go off on the side while I'm doing this test” and because they're so much more productive in some ways than a human tester, they can often churn things out in an hour or two that would take us months if we were doing that config review, that reverse engineering, by hand.

 Q: How did Broadcom take the disclosure? [Atredis Partners contacted it on July 8. Broadcom responded the next day, then pushed a hotfix and advisory 20 days later.]

They were very responsive when we submitted, and in my opinion, they fixed it very quickly. I've seen organizations take months and months and months, especially for a vulnerability like this. So all credit to them, they were great to work with. They were never a problem. They asked reasonable questions, and we gave them answers. The back and forth was wonderful. I really enjoyed working with them.

 Q: Did you get a bug bounty?

 [Laughs] We got nothing. Our client buys a lot of Broadcom stuff, so I don't think it would have been fair to kind of double dip. Really, the payment for me is just getting my name in the advisory, getting a chance to talk to guys like you, right? Hopefully, maybe getting a couple of talks accepted on how to assess large appliances, tactical binaries, and find good vulnerabilities and on this changing face of pen testing. With any luck, I'll get a few talks out of it, and that'll be enough for me!

We keep our security reporting free, for public interest. Subscribing for $30/month or $300 a year gets you our thrice-weekly Runtime newsletter, full access to in-depth interviews (coming up, exclusive chats with HSBC's Global CTO and Nestle's CIO) and a 50% discount on tickets to our biannual Chatham House rule Stack Summit – coming November 4th, London. Join peers already subscribing.

*Needless to say, over the years, The Stack has seen much greater creativity than this. A simple yet effective pet favourite was the creation of a typosquatted mailserver. The pentester checked for most commonly mistyped domains close to that of the large company they were testing, spun up a mailserver on that domain for $25, sat back and waited for emails to ITsupport@fatfingers dot com. It took a few days for someone to mail in asking help; the penetration tester called them back, walked them through installing/enabling some remote access software and was in. Perimeter alarms did not go off and the beachhead turned out to have a Word document in its files conveniently labelled "passwords."

** Some 29 “known exploited” vulnerabilities have been added to CISA’s KEV catalog this month (August 2026), versus August 2025's 15.

We always love to hear from readers: ed@thestack.technology

The link has been copied!