Yes. CISA added CVE-2022-46169 to its Known Exploited Vulnerabilities catalogue on 16 February 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Cacti contains a command injection vulnerability that allows an unauthenticated user to execute code. Any organisation running the affected product should treat remediation as urgent.
What “exploited in the wild” means for CVE-2022-46169
For this CVE, “exploited in the wild” means there is credible evidence that attackers are actively using the command injection flaw against real systems, not just that a proof of concept exists. CISA’s inclusion in the KEV catalogue is the clearest operational signal that exposure is urgent, because it reflects observed exploitation rather than theoretical risk.
That matters because Cacti is a web-facing product and command injection can turn a simple request into system-level execution. Once a flaw reaches that stage, defenders should assume reconnaissance, payload delivery, and follow-on abuse can happen quickly after exposure becomes public.
When you evaluate this question in practice, the key issue is not whether exploitation is possible, but whether your environment can still be reached by the vulnerable version or an equivalent exposed path. A system that is internet-reachable, poorly segmented, or not being actively monitored should be treated as a likely target.
How to judge exposure and urgency
The first triage step is to confirm whether Cacti exists in your asset inventory, whether it is reachable from untrusted networks, and whether any downstream systems inherit its access. If the answer is yes to any of those, this should move into immediate remediation rather than routine backlog handling.
CISA’s KEV listing is especially useful because it shifts the question from “is there a vulnerability?” to “is this vulnerability already being used as an attack path?” That changes prioritisation logic: patching, mitigation, and exposure reduction should jump ahead of lower-risk work, even if the affected deployment is not the most business-critical application in the stack.
For organisations with more than one Cacti instance, look for inconsistent hardening, forgotten lab systems, and externally exposed admin interfaces. Those are common places where an exploited bug stays visible long after the main production estate has been hardened.
What defenders should do before and after remediation
Start by applying the vendor fix or the vendor-recommended mitigation path, then verify that the vulnerable service is no longer reachable in the same way it was before. If patching must wait, reduce exposure by removing internet access, tightening network policy, restricting administrative access, and placing the system under heightened logging and alerting.
If there is any chance the host was exposed before remediation, review web logs, command execution traces, process creation events, and outbound connections for signs of post-exploitation activity. For command injection cases, the important question is not only whether the initial request was blocked, but whether code execution already occurred and established a foothold.
It is also sensible to review credentials and sessions associated with the affected system if it had access to other infrastructure, credentials, or automation paths. Where a vulnerable management system could have touched secrets or privileged interfaces, assume the blast radius may extend beyond the application itself.
Risk and Threat Considerations
Command injection is dangerous because it can convert a web request into arbitrary operating system execution, which often gives an attacker enough control to pivot, stage tools, or harvest additional access. In an exploited product, the immediate risk is not only compromise of the Cacti server, but also whatever systems it can reach, manage, or authenticate to.
Failure mechanism: An unauthenticated attacker sends crafted input that the application passes to the shell or another command execution path, allowing remote code execution and possible follow-on compromise.
Impact: The attacker may gain host control, deploy persistence, steal credentials, move laterally, or use the server as a staging point for broader intrusion.
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, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Prioritises finding and fixing KEV-listed exposed flaws quickly. |
| Recommendation — Prioritise remediation of actively exploited vulnerabilities and verify exposure is removed. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Activities | Active exploitation calls for monitoring signs of unauthorised execution and abuse. |
| PR.PS-01 — Configuration Management | Reducing attack surface and removing exposed vulnerable paths is central here. | |
| Recommendation — Monitor the affected host for suspicious process and network activity after exposure. Harden or isolate the vulnerable service until the fix is confirmed effective. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Command injection is a core application-security design and validation failure. |
| Recommendation — Review input handling and command invocation paths to eliminate shell injection risk. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | The vulnerability enables attacker code execution through command interpretation. |
| Recommendation — Map observed post-exploitation activity to command execution and hunt for follow-on abuse. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed exploitation as a containment problem first, not just a patching task. If the system is exposed, reachable, or privileged, isolate it while remediation is underway and assume the window for abuse is already open.
What to verify: Confirm whether the instance was reachable from untrusted networks, whether relevant logs still exist, and whether the host performed any unexpected child process execution or external communication before the fix was applied.
Decision rule: If you cannot rapidly prove the system was neither exposed nor abused, escalate to compromise assessment and credential review in parallel with remediation, because command injection incidents often leave the widest damage in the systems the vulnerable app could reach next.
Practitioner takeaway: For KEV-listed command injection issues, the right question is not “is there a patch?” but “what access did this system already have, and what else must be assumed at risk if it was exploited?”
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- Is CVE-2022-30525 (Zyxel Multiple Firewalls OS Command Injection) being exploited in the wild?
- CVE-2022-46169 (Cacti Command Injection)
- Is CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection) being exploited in the wild?
- Is CVE-2018-9276 (Paessler PRTG Network Monitor OS Command Injection) being exploited in the wild?
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