CVE-2022-46169 (Cacti Command Injection)

What makes command injection dangerous in Cacti?

Command injection is dangerous because it turns a web-facing input flaw into operating system command execution. In a product like Cacti, that can move an issue from application misuse to full server compromise, which is why KEV-listed exploitation matters operationally and not just theoretically.

The practical security concern is that an unauthenticated attacker does not need valid user access first. When input reaches a shell or command runner without strict validation, the attacker can often chain commands, read local files, alter data, or plant persistence on the host.

How organisations confirm exposure to this CVE

Exposure assessment starts with a complete asset inventory: identify every Cacti deployment, where it sits, whether it is internet reachable, and whether it is behind compensating controls such as a reverse proxy, WAF, or network segmentation. That is the only reliable way to know whether the vulnerable code path is reachable from an attacker.

Because this is a KEV-listed issue, organisations should also compare their environment with the vendor advisory and the NIST National Vulnerability Database entry for authoritative record details, and then verify whether the vulnerable component exists in their own deployment. For prioritisation of known exploited issues, the CVE Program and CISA KEV together provide the canonical reference points.

Internet exposure increases urgency because unauthenticated command injection is far easier to weaponise than a flaw that requires internal access or a privileged login. Even where a system is not public, lateral movement inside the network can still reach it if internal trust is weak.

Remediation and compensating controls

The preferred fix is to apply the vendor’s remediation for the exact Cacti release in use, then confirm the instance no longer exposes the vulnerable path. If immediate patching is blocked, reduce attack surface by restricting access to trusted administrative networks, removing unnecessary public exposure, and disabling or isolating the affected service until it can be updated.

For vulnerable command execution paths, compensating controls should focus on preventing attacker-controlled strings from reaching the shell, limiting the privileges of the service account, and tightening file-system and process permissions so a successful exploit has less room to operate. Network controls can slow opportunistic exploitation, but they are not a substitute for removing the flaw.

Use the Vulnerability Management Guide as a practical model for prioritising KEV-listed issues, tracking remediation status, and verifying that the vulnerable asset is actually covered by your patch programme.

Detection and post-exploitation review

Detection should look for unusual web requests, unexpected process creation from the Cacti service, shell activity, suspicious child processes, and new outbound connections that do not match normal monitoring behaviour. If exploitation is suspected, review logs for command-delimiter characters, abnormal parameter values, and repeated requests that look like exploitation attempts rather than normal UI traffic.

After patching, organisations should still treat the host as potentially compromised if there is any sign of exploitation. Review for new users, altered scheduled tasks, modified binaries, webshells, persistence mechanisms, and credential theft, then reimage or rebuild if integrity cannot be trusted.

For broader exploit patterns and command-injection techniques, the Web Application Attacks Guide provides a useful taxonomy of how injection flaws are typically abused in practice.

Risk and Threat Considerations

This vulnerability is high-risk because unauthenticated command injection can give an external attacker immediate execution on an internet-facing management system. Once that happens, the issue is no longer limited to the application layer, it becomes host compromise with possible data access, service disruption, and pivot potential.

Failure mechanism: The attacker supplies crafted input that is passed into a command context, where the operating system interprets attacker-controlled metacharacters or arguments and executes unintended commands.

Impact: The attacker may gain remote code execution, steal credentials or configuration data, implant persistence, or use the host as a foothold for further movement inside the environment.

Practitioner Guidance

Why practitioners should care: A KEV-listed command injection in a management platform should be treated as a priority exposure, not a routine bug. If the service is reachable and untrusted input can reach command execution, the main question is whether the instance has already been probed or abused.

What to watch for: Focus on exploit indicators around the web tier and the host beneath it, especially unusual process trees, unexpected outbound traffic, and post-request system activity that does not fit normal monitoring workflows.

Practitioner takeaway: Confirm exposure first, patch or isolate quickly, and assume compromise until log review and host integrity checks prove otherwise.

Related resources from NHI Mgmt Group

• CVE-2022-30525 (Zyxel Multiple Firewalls OS Command Injection)
• CVE-2022-29303 (SolarView Compact Command Injection)
• CVE-2022-33891 (Apache Spark Command Injection)
• CVE-2025-59689 (Libraesva Email Security Gateway Command Injection)