How do you patch or mitigate CVE-2022-26143 (MiCollab, MiVoice Business Express Access Control)?

CISA’s required action for CVE-2022-26143 is to apply updates per vendor instructions. In practice, find every instance of Mitel MiCollab, MiVoice Business Express 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 changes when CVE-2022-26143 is present in your environment?

The practical question is not whether the vulnerability exists in the abstract, but whether any Mitel MiCollab or MiVoice Business Express instance is still reachable, unpatched, or exposed where it can be abused. Because CISA requires vendors’ updates and the flaw was exploited in the wild, exposure should be treated as a live incident-response and patching priority rather than a routine maintenance item.

For affected systems, the first decision is scope: identify every deployment, confirm whether it is internet-facing or reachable from trusted networks, and determine whether the vendor security update or documented mitigation can be applied without disrupting dependent services. If the product cannot be fixed quickly, the safer interim move is to remove exposure or take the system out of service.

When the product is no longer needed or cannot be contained, mitigation should be operationally equivalent to decommissioning from an attacker’s point of view. That means blocking direct access, removing unnecessary ports and routes, and ensuring any surviving management path is not broadly reachable. If the system must remain online, the mitigation should be paired with heightened monitoring and a clear rollback plan.

Post-patch validation matters as much as the update itself. Review logs and surrounding telemetry for signs of prior exploitation, because a patched vulnerable system can still remain compromised if an attacker used the flaw before remediation. Look for unusual authentication activity, unexpected configuration changes, suspicious outbound traffic, and indicators that the device was used as an initial access point.

What should you verify before you call the issue closed?

Confirm the exact product, version, and deployment path, then verify that the vendor’s remediation or mitigation has actually been applied to every instance, not just the most visible one. In mixed estates, it is common for one appliance, branch deployment, or dormant test system to remain reachable after the primary environment is fixed.

Also verify that exposure has changed in a durable way. If you only applied a temporary network control, the system is still a candidate for future compromise unless the control is enforced at the perimeter and documented in asset ownership or change records. For security operations, the key proof is not “we intended to patch,” but “the vulnerable service is no longer exploitable from where an attacker could reach it.”

For environments with logging gaps, assume the post-exploitation question is unresolved until you have enough telemetry to support it. If logs were not retained through the vulnerable period, increase the confidence threshold before declaring the host clean, because the absence of alerts is not the same as the absence of abuse.

When patching cannot happen immediately, what is the safest interim stance?

The safest stance is to reduce the attack surface before trying to compensate with detection. That usually means removing internet exposure first, then constraining access to the smallest possible set of trusted sources, and finally deciding whether the system is still worth keeping online under that residual risk. If neither a fix nor an effective containment step is available, taking the product out of service is the least ambiguous option.

If temporary mitigation is used, treat it as a time-bound exception with ownership and an expiry date. A mitigation that is not tracked tends to become permanent, and a permanent exception often outlives the compensating controls that made it acceptable in the first place.

After containment, preserve evidence. Capture relevant logs, firewall records, and configuration snapshots before making further changes so investigators can reconstruct whether the system was touched before the update. That evidence is often what determines whether the work ends as patch management or expands into breach response.

Risk and Threat Considerations

Because this CVE was exploited in the wild, the main risk is not just service disruption, but unauthorized initial access into a communications platform that may sit close to identity, call handling, and internal network trust boundaries. Any exposed instance can become an entry point for follow-on activity if attackers reached it before remediation.

Failure mechanism: Unpatched or externally reachable deployments leave the vulnerable access control path available for exploitation, and a successful exploit can occur before defenders notice abnormal activity or complete remediation.

Impact: Attackers may gain a foothold, access internal resources, or use the compromised appliance as a staging point for broader network activity, which makes post-patch compromise checks essential.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	This CVE requires rapid discovery, prioritization, and remediation of exposed vulnerable assets.
Recommendation — Prioritize and remediate exposed MiCollab and MiVoice Business Express systems under continuous vulnerability management.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	The question is about finding vulnerable instances and understanding exposure before remediation.
	PR.IR-01 — Network Resilience	Mitigation includes removing internet exposure or taking the product out of service.
	RS.AN-01 — Analysis	The direct answer requires log review for signs of earlier exploitation after patching.
Recommendation — Identify vulnerable Mitel assets and confirm exposure before you close the incident. Restrict network exposure so the vulnerable service is no longer reachable from untrusted networks. Analyze logs and telemetry for evidence of prior exploitation after remediation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The core action is to apply vendor updates or documented mitigations for the vulnerable product.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch review of logs is needed to detect earlier exploitation attempts.
	AC-4 — Information Flow Enforcement	Removing exposure or constraining access directly addresses the attack path for this CVE.
Recommendation — Apply the vendor update or approved mitigation to remediate the flaw. Review audit records for signs of compromise before declaring the system clean. Enforce network access restrictions so the vulnerable service cannot be reached externally.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	This vulnerability requires timely patching, mitigation, and verification across the estate.
	A.8.15 — Logging	The answer depends on reviewing logs for earlier exploitation after remediation.
Recommendation — Track, prioritize, and remediate the affected Mitel systems under vulnerability management. Retain and review logs to validate whether exploitation occurred before the fix.

Practitioner Guidance

What to prioritise: Patch or isolate every exposed instance first, then verify whether any system was reachable during the vulnerable window. If you have to choose between perfect sequencing and reducing exposure, remove the attack path before spending time on broader hardening.

What to verify: Make sure the vendor update or mitigation was applied to all instances, and then confirm that no alternate route still exposes the service. A single missed edge deployment can keep the risk alive.

Practitioner takeaway: Treat this as an exploited-vulnerability response, not just a patch task, because the real closure condition is not only fixed software but also a clean exposure profile and evidence that the system was not already abused.