Yes. CISA added CVE-2022-26143 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A vulnerability has been identified in MiCollab and MiVoice Business Express that may allow a malicious actor to gain unauthorized access to sensitive information and services, cause performance degradations or a denial of service condition on the affected system.
Actively exploited vulnerabilities demand a different response than ordinary CVEs. The priority is to confirm exposure, follow the vendor and CISA guidance for the affected product, and then treat the issue as an exploitation problem, not just a patching problem.
Because CISA has already placed CVE-2022-26143 in the KEV catalogue, the operational assumption should be that scanning, prioritisation, and remediation need to move faster than a normal maintenance window. If patching is delayed, use compensating controls and assume compromise is possible until proven otherwise.
When a flaw can expose sensitive information or disrupt availability, post-remediation review matters as much as the fix itself. That means checking logs, access paths, and any accounts, sessions, or service credentials that could have been used through the affected access control weakness.
Why KEV Listing Changes the Response
A KEV listing is a strong operational signal because it means the vulnerability is not merely theoretical. For defenders, that changes the question from “Should we patch?” to “How quickly can we confirm exposure, contain risk, and verify whether the system has already been touched?” The right response is urgency with evidence, not urgency alone.
The practical consequence is that vulnerability management teams should triage this issue alongside other confirmed exploitation cases rather than waiting for an internal risk committee to elevate it. The KEV catalogue is useful precisely because it reflects real exploitation pressure, which is the signal most teams need to prioritise limited remediation capacity.
For authoritative product and status details, use the CVE Program, the NIST National Vulnerability Database, and the CISA Known Exploited Vulnerabilities Catalog rather than reproducing version details from memory.
What Defenders Should Verify First
Start with asset confirmation: determine whether MiCollab or MiVoice Business Express is present anywhere in the environment, including test, standby, or forgotten deployments. Then verify whether the exposed interfaces are reachable from any network segment that an attacker could realistically use.
If the system is present, validate whether the vendor fix or mitigation is actually applied, not just scheduled. In parallel, review logs for unusual access attempts, failed authentication patterns, unexpected administrative actions, or evidence that data or services were accessed through the vulnerable path before remediation.
That verification step should also include dependent identities and secrets if the affected system mediates authentication or access. When a flaw can expose sensitive information or enable unauthorised access, it is prudent to assess whether passwords, tokens, or service credentials may need rotation after remediation.
Why This Kind of Access Control Weakness Is Operationally Dangerous
An access control issue can do more than open a single door. If an attacker can use it to reach sensitive information or services, the same weakness may support reconnaissance, privilege abuse, service disruption, or follow-on intrusion. That is why “access control” flaws often become broader incident-response problems once they are exploited.
The most serious failure mode is that the organisation treats it as a narrow application bug while the adversary uses it as an initial foothold. In practice, that can lead to unauthorised access, degradation in service quality, or denial of service, especially when the vulnerable component is part of a communications or collaboration stack that many users depend on.
One useful internal reference for this broader vulnerability-response pattern is NHIMG’s Zero-Day and Exploited Vulnerabilities Guide, which covers KEV-driven triage, emergency mitigation, and post-patch hunting. For remediation planning, the Vulnerability Management Guide is the right navigation path for prioritisation, exceptions, and verification.
Risk and Threat Considerations
This type of vulnerability is risky because active exploitation collapses the normal time window defenders expect between disclosure and abuse. Once exploitation is confirmed, the main risk is not only unauthorised access, but also that the affected system may be used as a stepping stone for further internal compromise or service disruption.
Failure mechanism: An attacker targets the exposed access control weakness to obtain information or reach services they should not be able to use, then leverages that access for persistence, reconnaissance, or disruption before defenders complete remediation.
Impact: The organisation can face confidentiality loss, degraded service, denial of service, and a longer incident than the original patching task would suggest, especially if compromise is not checked after remediation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 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 | Active exploitation makes prioritised vulnerability remediation central. |
| CIS-8 — Audit Log Management | Post-exploit review depends on logs showing access and abuse attempts. | |
| Recommendation — Prioritise and remediate KEV-listed flaws first, then verify exposure and closure. Collect and review logs to confirm access attempts and support compromise assessment. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about responding to a known exploited vulnerability. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Evidence of exploitation requires review of logs and security events. | |
| Recommendation — Patch or mitigate the flaw promptly and document any exception until closure. Analyze logs for suspicious access and report indicators of compromise. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | The subject is an exploited product vulnerability that needs formal remediation control. |
| Recommendation — Track, prioritise, and remediate the vulnerability under the vulnerability-management process. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed exposure as a live operational issue. Confirm whether the product is deployed, determine whether it is reachable, and move remediation ahead of routine patch queues if it is in scope.
What to verify: After fixing or mitigating, check for suspicious access, unusual administrative activity, and any signs that sensitive information or access-bearing material may have been exposed. If the system handled credentials or sessions, validate whether rotation is warranted.
Practitioner takeaway: When a CVE is already in KEV, the right security question is not whether exploitation is possible, but whether you have evidence the system was exposed before you contained it.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-26143 (MiCollab, MiVoice Business Express Access Control)?
- CVE-2022-26143 (MiCollab, MiVoice Business Express Access Control)
- Is CVE-2021-25337 (Samsung Mobile Devices Improper Access Control) being exploited in the wild?
- Is CVE-2021-25369 (Samsung Mobile Devices Improper Access Control) being exploited in the wild?