CISA's required action for CVE-2022-42948 is to apply updates per vendor instructions. In practice, find every instance of Fortra Cobalt Strike in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What patching CVE-2022-42948 actually means in practice
CVE-2022-42948 is not just a software update task, it is an exposure-management task for an actively exploited remote code execution issue. The immediate objective is to locate every Fortra Cobalt Strike instance, apply the vendor security update or documented mitigation, and, if remediation cannot be completed quickly, remove internet exposure or take the product out of service until it can be fixed.
For teams that want the broader response pattern for exploited flaws, the Zero-Day and Exploited Vulnerabilities Guide is useful because it frames the same operational sequence: identify, contain, patch or mitigate, then verify whether exploitation may already have occurred.
Because the flaw was used in the wild, the patch decision should be tied to exposure, not just version inventory. If the product is reachable from the internet, assume the remediation clock is already running and treat the instance as a candidate for immediate containment, even if you have not yet confirmed malicious activity.
How to confirm exposure and choose the right remediation path
Start by building a complete inventory of where Cobalt Strike is deployed, including forgotten lab hosts, jump systems, and any externally reachable management surfaces. The key question is not whether the application exists somewhere, but whether a reachable instance can still be used as an execution foothold.
When the product is still required, follow the vendor’s update instructions first and then validate that the change removed the exposure you were targeting. If you need a process for handling exploit-prone software more generally, the Vulnerability Management Guide is relevant because it emphasises asset scope, emergency prioritisation, verification, and exception handling for vulnerabilities that are already being exploited.
When patching is delayed, the mitigation choice should be driven by blast radius. Reducing access paths, removing internet exposure, or temporarily retiring the product is often safer than leaving a vulnerable instance reachable while waiting for a maintenance window.
What to check after patching or mitigation
Do not treat successful patching as the end state. Review authentication events, process creation, configuration changes, and adjacent host activity for signs that the flaw was exploited before the fix was applied. The point is to distinguish “remediated” from “remediated after compromise.”
The CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm that this issue is handled as a known exploited vulnerability and to reinforce why post-fix hunting matters. For a second source of truth on the vulnerability record itself, NIST National Vulnerability Database remains the standard reference point for CVE documentation and product record details.
If you find evidence of abuse, treat the incident as more than a patching event. Rebuild or reimage affected systems where appropriate, preserve evidence before making destructive changes, and review whether lateral movement, credential theft, or persistence may have followed the initial execution.
Risk and Threat Considerations
Remote code execution in a security tool is dangerous because the product itself may sit on a high-trust path, often with broad access to endpoints, operators, or management networks. When that path is exposed to the internet, exploitation can convert a single vulnerable service into an immediate operator-level foothold.
Failure mechanism: An attacker reaches the vulnerable interface, triggers code execution, and uses the resulting access to run commands, stage payloads, or pivot into adjacent systems before defenders notice.
Impact: The compromise can extend beyond the application host to stored credentials, operator workflows, internal network visibility, and any downstream systems that trusted the compromised instance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | CVE patching and KEV-driven prioritisation are core vulnerability management tasks. |
| CIS-16 — Application Software Security | The issue is an application vulnerability requiring vendor-directed remediation or mitigation. | |
| Recommendation — Prioritise, patch, and verify exploited vulnerabilities first. Apply vendor fixes and compensating controls to exposed software. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The answer centers on applying fixes, mitigations, and verification after remediation. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation and post-fix verification depend on continuous vulnerability identification. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-patch log review is needed to detect earlier exploitation. | |
| Recommendation — Implement flaw remediation promptly and track completion. Scan for vulnerable instances and confirm remediation status. Review logs for signs of compromise after remediation. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | The flaw is exploited through a public-facing interface for remote code execution. |
| T1059 — Command and Scripting Interpreter | Successful RCE commonly results in attacker command execution on the host. | |
| Recommendation — Hunt for exploitation of internet-facing services. Detect and contain post-exploitation command execution. | ||
Practitioner Guidance
What to prioritise: Treat external exposure as the deciding factor. If the instance is reachable from untrusted networks, contain it first, then patch, because exploitability matters more than whether the host appears stable.
What to verify: Confirm that every deployed instance was either updated or removed from exposure, and that logs were reviewed across the time window when the flaw may have been weaponised. If you cannot prove those two things, the job is not complete.
Decision rule: If you cannot patch immediately, disable the service or isolate it behind controls that materially remove attacker reachability. Do not accept a “temporary” exception unless you have a bounded compensating control and a firm removal date.
Practitioner takeaway: For a KEV-listed RCE, the correct sequence is exposure first, remediation second, and compromise assessment third, because the operational question is not only whether you fixed the flaw, but whether someone got there before you did.
Related resources from NHI Mgmt Group
- CVE-2022-42948 (Fortra Cobalt Strike User Interface Remote Code Execution)
- How do you patch or mitigate CVE-2022-26500 (Veeam Backup & Replication Remote Code Execution)?
- How do you patch or mitigate CVE-2022-26501 (Veeam Backup & Replication Remote Code Execution)?
- How do you patch or mitigate CVE-2021-1647 (Microsoft Defender Remote Code Execution)?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org