Exploit Chain Patch Playbook: A Copy-and-Use Template

Purpose of This Template

When CISA adds a vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, many teams treat it as a single issue. The recent Ivanti Connect Secure incident shows why this approach can fail. Three flaws were linked: an authentication bypass (CVE-2026-104935, CVSS 8.6), a remote code execution flaw, and a privilege escalation flaw. Together, they allowed an attacker to execute code with root-level access without authentication. The privilege escalation (CVE-2026-111357, CVSS 8.8) and the file-upload flaw (CVE-2026-118527, CVSS 4.3) were added to the KEV catalog later, with federal deadlines of November 2 and November 13, 2026.

Notice the 4.3 CVSS score. Alone, that flaw might be ignored. In a chain, it was critical. This template provides a one-page decision record to ensure chain-level thinking, so a "medium" finding doesn't hide in a critical incident.

Prerequisites

Before using the template, ensure you have:

• An asset inventory identifying internet-facing remote access and gateway appliances, with version data.
• A named owner for each appliance class and an emergency change path.
• A feed for KEV additions and vendor advisories, plus at least one source of threat reporting.
• Log retention long enough to trace back before the disclosure date, as exploitation often predates advisories.
• Authority to isolate or take a device offline without a committee meeting.

If you lack the inventory, address that first. No template can compensate for not knowing where the vulnerable version runs.

The Template

Copy this into your ticketing system or runbook. Complete one record per exploit chain, not per CVE.

EXPLOIT CHAIN RESPONSE RECORD

1. Trigger

• Date and time trigger received: ______
• Source (KEV addition / vendor advisory / threat report / peer share): ______
• Record owner: ______ Executive sponsor: ______

2. Chain Map

• Is the full chain closed by a single release? Y / N
• Are any links still unpatched or awaiting a backport? Y / N (If Y, document compensating controls in Section 5.)
• Priority rating for the chain (use the highest-impact outcome, not the lowest CVSS): ______

3. Exposure Assessment

• Affected assets and versions: ______
• Internet-facing? Y / N
• Fixed version target per supported branch: ______
• Assets that cannot be patched within the deadline: ______

4. Threat Context

• Known actor or cluster: ______
• Observed objectives (credential theft, reconnaissance, persistence, other): ______
• Credentials and secrets potentially reachable from the device (directory metadata, admin passwords, recovery keys, service accounts): ______

5. Actions and Deadlines

• Internal deadline: ______ External deadline (regulatory or contractual, if any): ______

6. Decision Log

• Decisions made, by whom, and when: ______
• Risk accepted and by whom: ______

7. Closure

• Patch verified on all assets: Y / N
• Compromise assessment result: ______
• Lessons captured and process changes filed: ______

Customizing the Template

Section 2 is critical. Most vulnerability programs score and queue CVEs individually. This table forces your team to consider what an attacker can achieve with the combined links. Set your priority rating based on the chain's outcome. In this case, it's unauthenticated root access, regardless of the lowest individual score.

Set your own deadlines. The federal deadlines in the Ivanti case apply to Federal Civilian Executive Branch agencies under CISA's directive. If you're not a federal agency, don't adopt them blindly. Define internal timelines based on exposure: internet-facing gateway appliances with active exploitation should have the shortest window, often hours or days. Establish these timelines in policy before an incident occurs.

Tailor Section 4 to your environment. The observed actor behavior in this case included more than web shells. The attacker extracted credentials, limited Active Directory metadata, performed host reconnaissance, and searched for administrator passwords and BitLocker recovery keys. This indicates what needs to be rotated. Adapt the "reachable secrets" field to include whatever your gateway can access: directory service accounts, VPN pre-shared keys, certificates, and stored recovery material.

Address the disclosure gap. Vendors don't always release every fix at once. In this case, the vendor prioritized a fix for the primary exploitation path and later delivered patches for the remaining flaws. Your template should assume partial fixes occur. If Section 2 shows an unpatched link, treat the device as exposed and apply compensating controls: restrict management interfaces, limit access to trusted source ranges, increase logging, and consider temporary removal from service for high-value segments.

Incorporate threat intelligence. Subscribe to vendor advisories and independent researcher reports, not just KEV. A chain is often documented before every link is cataloged. When a researcher describes a combined attack, open a record immediately and map the links you can identify, even if some CVEs aren't yet public.

Align with frameworks. If you report against NIST SP 800-53, this record supports flaw remediation and incident handling evidence. If you follow NIST SP 800-61, Section 5's compromise assessment maps to the detection and analysis phase. Under CIS Controls v8.1, it supports continuous vulnerability management.

Validation Steps

A template only counts if it works under pressure. Validate it in three ways.

1. Run a Tabletop Exercise. Present your team with a fictional three-CVE chain where one link scores low and one patch is delayed. Observe whether they prioritize the chain or the lowest score. Time how long it takes to complete Sections 1 through 3.
2. Test the lookback. Choose one internet-facing appliance and confirm you can query its logs for the period before a hypothetical disclosure. If retention is too short, address this gap now.
3. Verify the patch, don't assume it. After remediation, confirm the running version on each device matches the fixed release for its branch. Record who verified and how. Report completion rate and elapsed time as Key Risk Indicators (KRIs) to leadership, along with Mean Time to Remediate for chain-linked findings.

Revisit the template after each use. The first version will miss something specific to your environment, and each real incident is an opportunity for improvement.