Pwn2Own operates on a 90-day coordinated disclosure timeline: when a vulnerability is successfully demonstrated, the technical details are disclosed to the affected vendor immediately but kept confidential for up to 90 days to allow time for patching. After 90 days (or earlier, once the vendor ships the patch), the full technical write-up becomes public.
This creates a curious situation for enterprise defenders. After Pwn2Own Berlin 2026, the security community knows:
- That VMware ESXi has a cross-tenant code execution zero-day
- That Microsoft Exchange Server has a three-bug SYSTEM RCE chain
- That Windows 11 has four independent LPE paths
- That Red Hat Enterprise Linux has at least two LPE vulnerabilities
- That SharePoint has a second RCE chain distinct from May’s patched CVE
What the community does not know is the specific technical details of any of these vulnerabilities. The 90-day hold prevents reconstructing exploits from technical writeups. But it does not prevent defenders from taking pre-emptive actions.
The Defender’s Perspective on the 90-Day Window
What threat actors can do in the 90-day window: Nation-state and advanced criminal groups with their own research capabilities can attempt to independently rediscover the same bugs. They know which products were targeted and roughly which component categories (from competition category descriptions and partial disclosures by researchers on social media). Independent rediscovery is harder than reverse-engineering a patch, but it is not impossible for well-resourced actors.
What defenders can do in the 90-day window:
Reduce attack surface before the patch arrives. For Exchange SYSTEM RCE: ensure OWA is behind a WAF with Exchange-specific rule sets; restrict Exchange management interfaces to management network access only; review which external IP ranges can reach port 443 on Exchange Servers. None of these prevent a determined attacker from exploiting an unknown bug through an allowed access path, but they reduce the population of potential attackers who can exploit it.
Pre-position rapid patching capability. For each confirmed Pwn2Own category, identify the specific products in your environment, the system owners, the change management pathway, and the testing requirements. When Microsoft, Broadcom, and Red Hat release the Pwn2Own patches, the deployment pathway should be ready and waiting — not discovered ad hoc on the day the patch arrives.
Set up monitoring for the vulnerability class. Even without knowing specific CVE details, Pwn2Own competition announcements describe the vulnerability class (use-after-free, race condition, authentication bypass). Review whether your existing monitoring covers exploitation indicators for those classes on the affected products.
Conduct targeted threat hunts. For actively-exploited zero-days like CVE-2026-42897, the 90-day window is actually a prompt to hunt for prior compromise before the patch arrives. Hunt for exploitation patterns now, rather than waiting for a patch to trigger the incident response.
The Patch Release: When the Clock Changes Meaning
When a Pwn2Own patch is released, the 90-day window transitions from “known bug, unknown details” to “known bug, public technical details approaching”. Within days or weeks of the patch, researchers reconstruct the vulnerability from the diff and publish technical writeups. Shortly after, exploit code appears.
The historical exploitation timeline for high-profile vulnerability disclosures is compressing. For Exchange vulnerabilities in particular — given the historical pattern of rapid nation-state weaponisation of DEVCORE disclosures — the window between “patch released” and “active exploitation in the wild” has been measured in days.
This means that when the Exchange SYSTEM RCE patch arrives (likely between July and August 2026), the operational priority is equivalent to an actively exploited zero-day: patch within 24 hours, not at the next maintenance window.
Scheduling the Patch Response Now
For each Pwn2Own Berlin 2026 target product, create a calendar entry for the 90-day patch deadline and assign a named owner for the patch response. The deadlines are:
- Bugs from Day 1 (13 May 2026): Patch expected by 11 August 2026
- Bugs from Day 2 (14 May 2026): Patch expected by 12 August 2026
- Bugs from Day 3 (15–16 May 2026): Patch expected by 13–14 August 2026
If a vendor releases the patch earlier — which many do, particularly for severe vulnerabilities — the deadline moves earlier. Monitor vendor security advisory channels for out-of-band updates for Exchange, VMware ESXi, Windows 11, RHEL, SharePoint, and VirtualBox throughout the summer.
The 90-day clock is not a countdown to danger. It is a known timeline that defenders can use to be prepared. Using it is a meaningful differentiator between organisations that respond reactively to patches and those that anticipate them.
Share this article