The Eight Seconds Took Four Hours: What One Human Attacker Reveals About Penetration Testing

Eight seconds.

That's how long one attacker needed to go from a flaw in a small piece of software to a logged-in session on the server that guards a company's entire cloud setup. Security researchers at Sysdig published the details on September 11.

Speed like that usually points to AI. Attackers have started using AI agents that type and react faster than any person could. This attacker wasn't using one. They wrote their own tools, by hand.

And the eight seconds is a little misleading. Before that, the attacker spent almost four hours quietly looking around, testing things, fixing their own mistakes and working out where the passwords were kept. Once they knew, the break-in itself was quick.

Those four hours are the part worth paying attention to. They're also the part an automated security scan never sees.

What happened, in plain terms

The attacker found a flaw in Marimo, a free tool data teams use to write and run code. The flaw, tracked as CVE-2026-39987, let anyone on the internet open a command window on the server running it. No password needed. It's rated critical, and attacks started less than 10 hours after it was made public.

From there the attacker went hunting. Over a nine hour session and more than 850 commands:

1. 1They found two sets of cloud access keys stored on the server. One was in the system settings, the other inside the app's own database.
2. 2They used those keys to open the company's cloud password vault and take out the key to the guard server.
3. 3They wrote a small program that did all of that in one shot and logged straight in.
4. 4At the same time, a second program tried a completely different way in, in case the first one got blocked.

You don't have to use Marimo for this to matter. Lots of companies run an app that's reachable from the internet on a server that also holds cloud keys. That's the setup this attacker was looking for.

What a security scan would have caught, and what it missed

A vulnerability scan checks your systems against a list of known flaws. Run one against that Marimo server and it would have flagged the problem as critical. Good. Patch it.

But the scan would have stopped there. It wouldn't have told you the server was holding cloud keys in two places. Or that one of those keys could open a vault it had no business opening. Or that nothing stopped the server from sending data out to the internet.

A scanner doesn't treat any of those as flaws. They're settings and permissions, and each one looks small. Lined up together, they handed a stranger the keys to the building.

Think of a home inspection. The inspector writes down that the back door lock is broken. They don't walk through the house and notice the spare car keys hanging by that door, or the garage opener clipped to the visor. A burglar would.

That's what a penetration test is for. A skilled person actually tries to break in, follows each clue to the next one, and shows you how far they got. It's also why stray keys and overly generous access sit at the center of identity and access protection. They shouldn't wait for next quarter's cleanup.

The trap only the human avoided

Sysdig has watched several attackers go after this same flaw, and most of them were AI agents. So the researchers set a trap. They hid a written instruction in a file on the vulnerable server, the kind of thing an AI reads and follows without questioning.

Every AI attacker fell for it.

The human opened that file twice, read the instruction both times, and ignored it.

They also did something the AI attackers didn't: they built a backup plan before they needed one. According to Sysdig, the AI agents it tracked tend to fail, try something new a few seconds later, and never have a plan B ready.

To be fair, the human wasn't perfect. Their backup program had a bug in it. And Sysdig is careful to say neither type of attacker is more dangerous overall. Its bigger point is that defenses built to catch one type will probably miss the other.

For anyone buying security testing, that's the takeaway. Automated tools are fast and consistent, and they behave in predictable ways. People improvise. If your testing only imitates the predictable attacker, you've checked half your defenses.

That's why a person should be running the test. AI can help, as long as it isn't the one making the calls.

Questions your pen test report should answer

Plenty of regulated organizations buy a pen test once a year because an auditor, examiner or insurer expects one. Fair enough. Just make sure the report tells you more than a scan would. A good one answers these:

1. 1What could someone actually do with this access? A good report turns findings into plain consequences, like "could read member account records" or "could reach the payment system." If your CFO can't explain the top three findings after one read, it was written for the wrong audience.
2. 2What was tested, and what was left out? Every system in scope should be listed, and so should every exclusion. The way in here was a data science tool that's easy to overlook when a test gets scoped, and a clean report on a narrow scope can miss the one app that matters.
3. 3Did anyone notice the tester? The report should log when each step happened so your team can check whether monitoring caught it. If the tester got in and everything stayed quiet, that may be the most important finding of all.
4. 4Why is each problem ranked where it is? Severity scores rate flaws one at a time. The stray cloud keys in this breach would probably have rated as minor on their own, and they were the entire route in. Look for rankings based on what each problem leads to in your environment.
5. 5Could your team fix it from the report alone? Each finding needs proof that it's real and specific steps to close it. "Apply the vendor patch" doesn't count.
6. 6Did someone confirm the fixes worked? The PCI Security Standards Council's own guidance calls for a retest once fixes are in. Without one, you know what was broken on test day and nothing about today.

If your last report can't answer most of those, it probably checked a box without telling you much.

There's one more thing to look for, and it's where we think a lot of testing has fallen behind.

Real attackers don't choose between skill and AI anymore. The one Sysdig caught happened to work by hand, but many others now pair a skilled operator with AI that helps them sort through what they find, look up weaknesses and build tools faster. A test that leaves AI out entirely is measuring you against the attacker of a few years ago.

Our pen tests use both. An experienced, credentialed tester leads every engagement and makes every decision. AI works alongside them and speeds up the grind, so in the same testing window they get further into your network than they could on their own. That's much closer to how a real attack plays out today.

The AI stays outside your environment. It never touches your network, so there's nothing on your systems for a planted instruction like Sysdig's to fool. You get the speed AI brings, with a person deciding what to do with it.

The fix was available for months

One more detail. CISA, the federal government's cybersecurity agency, added this flaw to its list of actively exploited vulnerabilities and gave federal agencies until May 7, 2026 to fix it. The attack Sysdig caught happened months later, on a server that still hadn't been patched.

The problem was known. The fix existed. Nobody applied it.

A test on its own can't solve that. Someone has to own each finding, see it through and confirm it stayed fixed, which is the job of exposure management that tracks every finding to closure.

We see the pen test as the first step in a managed cyber risk program, and it works best when one accountable operator handles IT, security and compliance together. Split those across three vendors and a finding like "this account has too much access" can belong to all of them. It tends to get fixed by none.

Where to start

The attacker spent four hours learning the environment and eight seconds using what they learned. Most organizations have never had anyone spend those four hours on their side.

Not sure what one exposed app in your environment could reach? Start there. Get a Security Posture Snapshot and we'll help you find out.

Frequently Asked Questions

Can a vulnerability scan find an attack path like this one?

Usually not. A scan finds known flaws one at a time. It doesn't try the keys it finds or test how small problems add up, and that's where the danger was in this attack. Finding it takes a penetration test.

What is CVE-2026-39987?

It's a critical flaw in Marimo, a free tool for writing and running Python code. It lets anyone who can reach the tool open a command window on its server without a password. Version 0.23.0 fixes it, and CISA lists it as actively exploited.

Is an AI-driven pen test the same as a penetration test?

Not really. A penetration test, by definition, is a human-led engagement where a skilled tester tries to break in the way a real attacker would, making judgment calls along the way. Tools that run on their own, AI-powered or not, work more like an advanced vulnerability scan. They're useful for finding and checking flaws, but they don't improvise, and in Sysdig's research the AI attackers kept falling for a trap a human ignored. The strongest testing puts a person in charge and uses AI to help them move faster.

How often should we run a penetration test?

At least once a year, plus after big changes like a cloud migration or a new internet-facing app. PCI DSS, the payment card security standard, requires exactly that. Other regulators set their own expectations, so check yours.

We use Marimo or a similar tool. What should we do first?

Update Marimo to version 0.23.0 or later and keep it off the public internet. Then check which cloud keys live on that server, cut its access down to what it actually needs, block outbound traffic it doesn't need, and change any keys that might have been exposed.