Is CVE-2022-41223 (Mitel MiVoice Connect Code Injection) being exploited in the wild?

Yes. CISA added CVE-2022-41223 to its Known Exploited Vulnerabilities catalogue on 21 February 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. The Director component in Mitel MiVoice Connect allows an authenticated attacker with internal network access to execute code within the context of the application.

What “actively exploited in the wild” means for this CVE

For a CVE like this, the practical question is not whether the flaw exists, but whether defenders should treat it as an active incident-response priority. Once CISA adds a vulnerability to the KEV catalogue, it is a strong signal that exploitation is no longer hypothetical and that exposure should be handled as urgent operational risk, not routine backlog.

The key triage step is to confirm whether any instance of Mitel MiVoice Connect is reachable in your environment and whether the affected component can be accessed from internal network paths. If you have that product in scope, treat the issue as a real exploitation path until proven otherwise, because authenticated code injection against an internal component can be used to pivot from limited access to broader compromise.

How to think about exposure and remediation

The right response is to validate exposure first, then apply the vendor’s fixed version or mitigation path, using the CISA KEV entry as the prioritisation trigger. For vulnerability teams, that means this item belongs ahead of lower-confidence findings, especially where the asset is internet-adjacent, reachable from a trusted internal segment, or used by privileged operators. The CISA Known Exploited Vulnerabilities Catalog is the authoritative source for the exploitability signal, while the vendor advisory should drive exact version and remediation details.

If patching must wait, reduce the reachable attack surface immediately: restrict internal access to the management path, isolate the system from non-essential network segments, and review whether the exposed service can be reached by accounts that should not need it. For prioritisation and verification, pair CISA KEV status with exploitability-focused triage using the FIRST EPSS signal and the vendor guidance, rather than relying on severity labels alone.

What to check after remediation or suspicion of abuse

Because the vulnerability allows code execution in the context of the application, compromise assessment matters as much as patching. Review authentication logs, process creation events, unusual child processes, unexpected outbound connections, new scheduled tasks, and signs that the application spawned commands or tooling it normally would not use. If the server handled sensitive administration or telephony workflows, treat those accounts and sessions as potentially exposed too.

Where there is any indication of abuse, preserve logs and memory evidence before rebuilding. If the system was reachable only by a narrow set of operators, compare that operator list with the access records around the time of possible exploitation, because the most important question is often not just “was it exploited?” but “what trust path made the compromise possible?” The NIST National Vulnerability Database helps anchor the vulnerability record, while the CVE Program provides the canonical identifier and record structure.

Risk and Threat Considerations

Code injection in an internally reachable application is dangerous because it can turn ordinary administrative access into execution authority inside the target service. In environments where telephony or collaboration systems are trusted by operations staff, that trust can give an attacker a quiet path to persistence, lateral movement, or further credential harvesting.

Failure mechanism: An authenticated attacker with internal network access abuses the vulnerable Director component to run code as the application, then uses that foothold to extend control beyond the original session or user boundary.

Impact: The compromise can affect service integrity, expose adjacent credentials or session material, and create a launch point for broader enterprise compromise, especially when the system sits near administrative trust relationships.

Standards & Framework Alignment

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

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Active exploitation status requires identifying vulnerable assets in scope.
	PR.AA-05 — Identity Management, Authentication, and Access Control	Internal authenticated access is part of the exploit path and exposure control.
	RS.MI-01 — Incidents are Contained	Suspected exploitation requires containment before or alongside eradication.
Recommendation — Inventory exposed Mitel systems and confirm where the vulnerable component is reachable. Restrict who can reach the affected management path and validate privileged access. Isolate the affected system if abuse is suspected and preserve evidence before rebuild.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Known exploited vulnerabilities need continuous discovery and prioritisation.
	SI-2 — Flaw Remediation	The vulnerability requires remediation or mitigation once exposure is confirmed.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation checks depend on reviewing logs for abuse indicators.
Recommendation — Track the CVE in vulnerability monitoring and escalate it ahead of routine findings. Apply the vendor fix or approved mitigation as soon as the asset is confirmed in scope. Review authentication, process, and network logs for signs of exploitation.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as a response event, not a routine vulnerability ticket. If the system is present, reachable, and business-critical, prioritise containment and patching over deeper debate about theoretical exploitability.

What to verify: Confirm whether the product is deployed, whether the vulnerable component is reachable from any internal network zone, and whether the server has logs that cover the relevant time window. If you cannot verify exposure quickly, assume it exists until disproven.

Decision rule: If patching is delayed, remove non-essential network access and review the administrative accounts that can reach the service; if exploitation is suspected, shift immediately to compromise assessment and evidence preservation.

Practitioner takeaway: KEV inclusion means you should manage this as a live exploitation risk with response discipline, not as a vulnerability scoring exercise.