What Zero-Day Response Should Be in the Post-Mythos Era

By Sila Ozeren Hacioglu, Security Research Engineer at Picus Security.

If you run PaperCut NG or MF, the last week of August showed what vulnerability response looks like when AI speeds up vulnerability discovery.

On August 27, PaperCut's urgent advisory said attackers were already exploiting servers. No CVE, no exploit, no patch. The first emergency patch came a day later and was bypassed the same day. The third one landed on September 1. Six days without a patch that held or an exploit to test with, while attackers were already exploiting in the wild.

And the window is closing. Disclosure-to-exploitation averaged 21.5 days last year. It is measured in hours now. PaperCut isn't the outlier. It's the template.

Below is one day in the life of a security team, told through a hypothetical CVE.

The CVE is made up. The day is not: it is what PaperCut's customers lived through in August. Let's walk through it hour by hour. 

08:00 – A CVE drops. No patch.

You wake up and CVE-2026-1001 is in your feed: unauthenticated RCE, no patch. You run a version check. Twenty assets match. Before you can finish reading the list, your phone rings. It's management. They've already seen it, they've already been asked about it, and they want an answer in the next fifteen minutes: are we exposed, and what are we doing about it?

Strip the panic away and there are exactly two questions to answer:

1. Are these 20 assets actually exploitable, in my environment?

2. Would my security controls stop it, right now?

Version data says "affected." Version data is not an answer. Both questions start the day at Unknown.

Patching is off the table, because there is no patch. 

Shutting the services down would settle the question, but the business runs on them. Nobody is going to negotiate that. You need a verdict, not a shutdown.

08:05 – Your first instinct cannot act

The natural move is to reach for your automated pentesting tool. Take the exploit, fire it at the 20 assets, see what falls. So you go looking for the exploit.

There isn't one. No public PoC, nothing to run. The tool that would give you the answer is waiting for ammunition, and so are you.

The attacker is not. Weaponization used to take weeks; now it takes hours, and the clock started at 08:00. If you wait for a public exploit, the first working one you see may be the one that hits you.

08:15 – The exploit is a chain, not a payload

Here is the shift. An exploit is not just a payload. It is a chain: the payload has to be delivered, it has to execute, and then the attacker has to escalate privileges, inject into a process and pull credentials to make the foothold worth anything. Each step is a known technique, and techniques can be simulated safely against your controls before anyone has written the payload itself.

You cannot test the exploit, because there is none. But you can test the chain the exploit would need. Map the CVE to the techniques it has to run, delivery, execution, privilege escalation, injection, credential access, and run those against your live stack: NGFW, WAF, endpoint hardening, EDR, SIEM. Per asset. The output is a verdict: would this chain succeed in your environment?

The question "is it exploitable here?" becomes testable ten minutes after disclosure.

We explained how this works in detail in our post on validating CVEs without a working exploit.

08:30 – Simulated, tested, ticketed

By 08:30 the chain has run. The results are not comfortable, and that is the point. The NGFW missed the delivery step. The WAF detected it but did not block. Endpoint hardening flagged execution. The EDR raised no alert. The SIEM raised no alert.

Now the two Unknowns have answers. The 20 assets are exposed to this chain, and nothing in the stack would stop it. But the gaps have names and owners. An action plan is created: a detection rule for the NGFW, a prevention rule for the WAF, GPO hardening for the endpoints, an IOA rule for the EDR, a detection rule for the SIEM. The EDR and SIEM rules deploy automatically. The rest go out as tickets and get worked through the morning, alongside a patch ticket for every affected asset, parked until a patch exists.

By 08:45 the chain is re-run. This time: detected, blocked, blocked, alerted, alerted.

You have not patched anything. You have broken the chain on every affected asset before a working exploit exists.

12:00 – The threat gets a name

Threat intel arrives. An Iranian threat group is running a campaign weaponizing CVE-2026-1001. There is still no public exploit, but the attacks have started. At 08:00 you had a vulnerability. At 12:00 you have an adversary.

That changes the question. The CVE is now one link in a full kill chain: initial access, lateral movement, persistence, exfiltration. You validated the vulnerability this morning. Would you survive the campaign?

12:30 – The whole campaign, rehearsed

You take the new report, pull the group's past behavior from earlier reporting, and assemble the full campaign as an attack simulation. Run it end to end against your controls.

• Initial access: blocked. The 08:30 fixes hold, and the morning pays off twice. 

• Lateral movement: detected, alert fired. 

• Persistence: missed. This is a technique the CVE-focused work could never have surfaced, because it has nothing to do with the CVE. 

• Exfiltration: blocked, egress controls holding.

The persistence gap runs the same loop as the morning: rule delivered, deployed, re-proven. Closed before lunch is over. Remember this rehearsal.

16:00 – The exploit goes public

A working exploit is published. Now, and only now, live testing has ammunition. Automated pentesting can fire the real thing.

But two constraints show up immediately. 

First, you may not be allowed to. Policy often forbids firing live exploits at production or critical assets, and print servers, domain controllers, and OT systems are exactly where that policy bites. 

Second, reach: with a real exploit, a pentest can safely touch maybe 5 of the 20 assets. The other 15 were only ever answerable the way you answered them at 08:15.

16:30 – Ground truth, two ways

The five reachable assets get tested with the real exploit. Three are not exploitable: the controls hardened this morning meet the real attack and hold. That is live confirmation the simulated verdicts were correct. 

Two are exploitable. They need the patch, and there still isn't one, so the patch tickets opened at 08:30 get upgraded to critical, with the working PoC and the exploitation evidence attached. No severity debate. The proof is in the ticket. Until the patch lands, the two go behind the WAF prevention rule with web access restricted to trusted IPs.

18:00 – The attacker arrives. Nothing happens.

The campaign hits your organization. Blocked. Alerted. Gaps already closed. The attack fails against controls validated at 08:15, fixed by 08:30, and proven at 08:45.

Ten hours before the attacker had a working exploit, your environment already did not have this exposure. That is what machine-speed validation buys: you finish before they start.

What this day required

Look at what actually got used. Not one capability, three, and none of them is a silver bullet on its own:

• Exploitability validation without a live exploit, for day-one verdicts and for the assets no attack should ever touch.

• Security control validation, to prove the compensating controls hold, and to catch the persistence gap the CVE never pointed at.

• Agentic pentesting, for ground truth where a real exploit exists and can be safely fired.

And they had to work together, on signal, in hours. The 12:30 campaign reused the 08:30 fixes. The 16:30 pentest confirmed the 08:15 verdicts. Findings from one fed the next. Run them as three siloed tools on three schedules and this day takes six weeks, not ten hours.

That is what the Picus Platform is built to do: exploitability validation, security control validation, and autonomous pentesting on one platform, sharing one data fabric, triggered by change rather than by calendar.

See the whole day, live

We are going to run this exact scenario, live in the product, at The Validation Summit ’26 on October 14 at 1 PM ET and October 15 at 11 AM BST.

Mikko Hyppönen opens with what changed after Mythos. Our CTO Volkan Erturk shows how machine-speed validation closes the patch gap and the speed gap. Security leaders from Chanel, Atlassian, and Kraft Heinz talk about how they are actually preparing. Ron Eddings of Hacker Valley hosts.

One question answered: what does Mythos-ready actually look like?

Two hours. Free. See the workflow run live.

Sponsored and written by Picus Security.