The defender's field guide
What is Exploit Wednesday?
Patch Tuesday risks, explained. A checklist you can use.
Exploit Wednesday is an informal name for the day after Microsoft's monthly Patch Tuesday, when attackers can use newly published advisories and fixes to investigate vulnerabilities in unpatched systems. For defenders, it is a reminder to identify affected assets, prioritize real exposure, and verify remediation.
It is not a prediction that an attack will happen on Wednesday. Exploitation can precede a patch or follow it much later. Do not wait for a particular weekday to address urgent risk.
Patch Tuesday vs. Exploit Wednesday
Microsoft's Windows monthly security release normally arrives on the second Tuesday of the month. It also issues out-of-band updates when necessary. That is the vendor's release schedule, not a universal timetable for every product or attacker. Microsoft's release-cycle documentation explains the distinction.
- Patch Tuesday
- The scheduled release of updates and information about the issues they address. Your first question: What changed, and do we use it?
- Exploit Wednesday
- The informal name for the response window after disclosure. Your next question: Where are we exposed, and what proves we acted?
- Hack Wednesday
- Our weekly defensive habit: turn evidence into owned actions. The weekly habit complements the monthly patch cycle; it does not replace urgent response.
Why can a patch help an attacker?
An advisory can identify an affected component and the conditions required to exploit it. Comparing patched and unpatched code, often called patch diffing, can provide additional clues. Producing a reliable exploit still depends on the vulnerability and environment; disclosure does not make every bug immediately exploitable.
The useful security lesson is the gap between a fix being available and a fix being effective across your assets. Downloading a package, opening a ticket, and deploying an update are different milestones. A failed restart or an overlooked server can leave that gap open.
Historical example
WannaCry: an available patch was not enough
Microsoft's published timeline records three milestones. This is an example of the patch-to-remediation gap, not a claim that WannaCry began on a Wednesday.
- Microsoft released MS17-010, addressing SMB vulnerabilities.
- The Shadow Brokers publicly released exploits including EternalBlue.
- WannaCry used EternalBlue in ransomware attacks against vulnerable systems.
Source: Microsoft's retrospective and EternalBlue timeline. Almost two months separated the patch and the outbreak. That history does not establish a safe waiting period for the next vulnerability.
Our operational takeaway: maintain an inventory that includes internal systems, verify patch coverage, restrict unnecessary paths between systems, and prepare recovery. If an asset was exposed before remediation, investigate that period rather than assuming the patch erased a compromise.
Your Exploit Wednesday response checklist
Use these six checks when an advisory changes, not just once a month. They are a proposed operating workflow, not a compliance certification or a universal remediation deadline.
Capture the advisory
Record the CVE, affected versions, vendor fix, prerequisites, known exploitation, and source timestamp. Recheck updates rather than relying on an old screenshot or an AI summary.
Leave with: A vendor advisory link and a timestamped applicability decision.
Match it to real assets
Compare the advisory with endpoint, cloud, application, and dependency inventories. Check runtime versions and vulnerable features. An unmatched asset is unknown, not automatically safe.
Leave with: An affected asset group, a verified not-affected result, or an owned discovery task.
Prioritize the attack path
Combine exploitation evidence, reachability, privileges, business impact, and existing controls. Include critical internal systems and lateral movement paths; internet exposure is not the only risk.
Leave with: A reasoned priority, accountable owner, and deadline under your response policy.
Patch or mitigate safely
Use trusted vendor packages, an approved change path, proportionate testing, and a rollback plan. When patching is blocked, validate the vendor mitigation and record its scope, expiry, and residual risk.
Leave with: A change ticket, deployment result, and time-limited exception where necessary.
Check for compromise
Review relevant telemetry for the exposure period and escalate suspicious evidence through the incident-response process. A successful patch does not remove an existing foothold or undo stolen credentials.
Leave with: Detection coverage, investigation references, and acknowledged logging gaps.
Verify and close the loop
Verify the running version or effective mitigation and service health. Reconcile missing assets, failed restarts, and offline devices before closing work. Keep a next check-in for unresolved cases.
Leave with: Post-change evidence, remaining exposure, and the next owner update.
Start with the Microsoft Security Update Guide and relevant vendor advisories. CISA's Known Exploited Vulnerabilities catalog adds evidence of exploitation in the wild. FIRST's EPSS estimates exploitation probability over the next 30 days; it does not establish whether your specific asset is compromised.
Use those inputs alongside severity, business impact, reachability, and effective controls. Absence from KEV or a low predicted probability is not proof of safety. Follow any applicable legal, contractual, or organizational response requirements.
A worked example: which system goes first?
Fictional tabletop scenario. These are invented asset groups, not real CVEs or findings about a company. Assume your inventory and affected-version checks are current.
| Asset group | Evidence | Proposed next action |
|---|---|---|
| A: Internet-facing gateway | Affected version verified; active exploitation reported; privileged access path. | Activate urgent response. Apply an approved fix or validated mitigation and investigate the exposure window. |
| B: Internal test service | Critical severity; affected version verified; access limited to an isolated lab; no known production dependency. | Confirm the isolation and dependencies, then schedule a prompt tested change with an owner. Do not treat it as risk-free. |
| C: Identity infrastructure | Potentially affected; inventory stale; high business impact; reachability unknown. | Assign urgent discovery in parallel with A. Escalate if exposure or compromise is confirmed; unknown is not low priority. |
A can warrant action before B despite B's severity label. C needs immediate clarification, not a place at the bottom of the queue. Actual priorities can change as evidence arrives; your response owner makes the decision.
Closure needs more than a green dashboard. If one gateway did not restart, A remains partially exposed. If the lab shares production credentials, reassess B. If C cannot be inventoried, record that uncertainty and decide on interim protection.
Take it to your next triage
Free vulnerability triage worksheet
Download a blank spreadsheet or a Markdown checklist with an incident handoff template. Record advisory evidence, affected assets, owner, priority reason, deadline, mitigation expiry, verification, and the next update. No signup required.
Use these files in your approved internal workspace. HackWednesday does not receive your completed worksheet. Do not post asset inventories, credentials, or incident details publicly.
Make the response repeatable without another status meeting
Keep one shared queue and ask each owner for evidence, not a new slide deck. A useful update says which assets remain affected, what changed, which uncertainty blocks progress, and when the next verification happens.
The companion Hack Wednesday team playbook provides a short review agenda and handoff format. For AI-assisted triage, use the SOC security guide: models can help assemble evidence, but they should not invent asset status or gain production authority from an advisory.
Common questions about Exploit Wednesday
Is Exploit Wednesday an official Microsoft event?
No. It is an informal security term for the period after Patch Tuesday when newly disclosed fixes can help attackers understand vulnerabilities in systems that remain unpatched. It is not a separate Microsoft release or a guarantee of an attack.
Does Exploit Wednesday happen every week?
The phrase traditionally refers to the day after Microsoft's monthly Patch Tuesday. HackWednesday's weekly review is an editorial and operational habit, not a claim that Microsoft publishes its monthly security updates every Tuesday.
Should I wait until Wednesday to install security updates?
No. Follow vendor guidance and your organization's risk-based change process. Active exploitation or critical exposure may require urgent action before the next scheduled review. A calendar reminder is not a safe waiting period.
Is every Exploit Wednesday attack a zero-day?
No. Attackers can target known vulnerabilities after a fix is available, often called n-day exploitation. Zero-day attacks and out-of-band fixes can also occur outside the monthly cycle.
Does a vulnerability's absence from CISA KEV mean it is safe?
No. KEV is evidence of known exploitation, not a complete list of every exploitable vulnerability. Consider vendor guidance, affected assets, attack paths, and business impact even when a vulnerability is not listed.
Can AI do the Wednesday triage for my team?
AI can draft advisory summaries, inventory queries, and tickets. Verify the source evidence and affected versions, use approved data handling, and keep changes within explicitly authorized workflows. An AI answer is not proof that an asset is patched or uncompromised.