Yes. CISA added CVE-2022-31199 to its Known Exploited Vulnerabilities catalogue on 11 July 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Netwrix Auditor User Activity Video Recording component contains an insecure objection deserialization vulnerability that allows an unauthenticated, remote attacker to execute code as the NT AUTHORITY\SYSTEM user.
How to confirm whether this CVE is being actively exploited
The practical question is not whether the flaw is technically severe, but whether your environment is exposed to a vulnerability that has already crossed into real attacker use. For this CVE, the starting point is to confirm whether Netwrix Auditor’s User Activity Video Recording component exists anywhere in your estate, then verify whether the affected product is internet-reachable, internally reachable from a low-trust segment, or present on hosts with broad administrative access.
From an operations standpoint, KEV status changes the response threshold. Once a vulnerability appears in CISA’s catalog, it should be treated as a live exploitation problem, not a routine patch backlog item. CISA Known Exploited Vulnerabilities Catalog is the authoritative place to verify that status, while the CVE Program remains the canonical identifier source.
Because the issue is an insecure deserialization flaw, exposure is not only about installation presence. You also need to check whether the vulnerable component is enabled, whether management interfaces are exposed beyond the intended admin network, and whether any compensating controls, such as segmentation or host hardening, actually limit remote reachability.
Why this vulnerability is dangerous when it is in the wild
Insecure deserialization is dangerous because it can turn a single crafted request into code execution, often before ordinary authorization logic can help. In this case, the direct answer already makes the impact clear: an unauthenticated remote attacker can execute code as SYSTEM, which means exploitation can lead to full host compromise, rapid follow-on discovery, and potential credential or token theft from the affected server.
The broader risk is that exploitation often looks like normal application traffic until the payload is processed. That makes exploit detection dependent on host telemetry, suspicious process creation, unexpected child processes, and anomaly hunting around the vulnerable service rather than only perimeter filtering. NIST National Vulnerability Database is useful for record-level tracking, but the response decision should be driven by exploitability and exposure, not by score alone.
If the component sits on a server that also stores authentication material, log data, or administrative tooling, the impact can extend well beyond the initial Netwrix service. That is why this kind of flaw belongs in the same response path as other actively exploited remote code execution issues, even when the immediate vulnerable product seems narrow.
What to do if patching or remediation must wait
The first fallback is containment, not optimism. If you cannot remove the exposure immediately, restrict reachability to the smallest possible admin set, isolate the host, and disable or remove the specific component if business function allows it. For a known exploited vulnerability, temporary compensating controls should be treated as short-lived risk reduction, not as a substitute for correction.
Zero-Day and Exploited Vulnerabilities Guide is the right internal playbook for this situation because the response pattern is the same: verify scope, accelerate remediation, and use active-hunting steps when exploitation has already been observed in the wild. The vendor advisory and the CISA catalog should remain your source for exact version and fix details.
If internet exposure cannot be eliminated quickly, treat the host as potentially compromised until proven otherwise. That means preserving logs, checking for unexpected outbound connections, and validating whether the vulnerable service spawned unusual processes or wrote suspicious files after the known exploitation date.
Risk and Threat Considerations
This CVE combines two high-risk conditions: unauthenticated remote access and code execution as SYSTEM. That makes it attractive for both opportunistic exploitation and post-compromise staging, because attackers can move from initial execution to persistence, local discovery, and broader compromise very quickly.
Failure mechanism: A crafted deserialization payload reaches the vulnerable component, the application processes attacker-controlled objects, and the attacker gains arbitrary code execution without needing valid credentials.
Impact: The affected host can be fully taken over, with a realistic path to data access, service disruption, credential theft, and further movement inside the environment if the server has trust relationships or elevated access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Actively exploited CVEs require prioritized remediation and tracked exceptions. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation depends on identifying vulnerable instances and scope. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Exploitation checks rely on reviewing logs and host telemetry for suspicious activity. | |
| Recommendation — Accelerate remediation and document any compensating-control exception until the flaw is removed. Scan for vulnerable instances and verify where the affected component is deployed. Review logs and host telemetry for signs of exploitation or post-compromise activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed flaws should be prioritized through an active vulnerability management process. |
| CIS-8 — Audit Log Management | Confirming exploitation depends on usable logs and event retention. | |
| Recommendation — Prioritize the CVE for rapid remediation and track exposure until closure. Retain and review logs that can confirm suspicious execution and lateral movement. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed vulnerabilities on externally reachable administrative or monitoring systems as immediate-response items. If the system is still in service, confirm whether the vulnerable component is actually needed before you spend time on deeper forensic work.
What to verify: Check whether the host shows signs of post-exploitation activity, including new local accounts, unusual scheduled tasks, unexpected child processes, archive or staging activity, and outbound connections that do not fit the server’s normal role. Preserve evidence before cleanup when compromise is plausible.
Decision rule: If the asset cannot be patched immediately, isolate it, restrict access, and assume compromise until you have enough telemetry to rule that out. If the server handled sensitive credentials or administrative sessions, rotate the relevant secrets and invalidate sessions after containment.
Practitioner takeaway: Once a vulnerability is in CISA KEV, the real decision is how quickly you can shrink exposure and prove whether exploitation already happened, not whether the issue is worth prioritising.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-31199 (Netwrix Auditor Insecure Object Deserialization)?
- CVE-2022-31199 (Netwrix Auditor Insecure Object Deserialization)
- Is CVE-2025-8875 (N-able N-Central Insecure Deserialization) being exploited in the wild?
- Is CVE-2022-21445 (Oracle ADF Faces Deserialization of Untrusted Data) being exploited in the wild?