CVE-2022-46169 cacti · cacti

Cacti remote_agent.php Pre-Auth Command Injection (CVE-2022-46169)

Vulnerability at a glance

Severity, exploitation likelihood & attack requirements

CVSS v3.1 severity
9.8Critical
EPSS · exploitation likelihood
99.826% Probability within 30 daysPercentile 100.0
EPSS trend
Unchanged Since 2026-10-14
Known exploitation
Known exploited CISA KEV catalog
Attack vector
NetworkRemotely reachable
Attack complexity
LowFewer obstacles to exploitation
Privileges required
NoneNo authentication required
User interaction
NoneNo user action needed
Exploit availability & maturity
Not scored Exploit reference available No explicit exploit maturity assessment View exploit evidence
How to read the colors & trend
Higher exposureElevatedModerateLower exposureUnknown / unassessed

CVSS colors follow its reported severity. Attack-factor colors describe each requirement, not an overall risk rating. Gray also covers absence from KEV; absence does not establish safety.

EPSS display bands: below 1% blue, 1–10% amber, 10–50% orange, 50% and above red. These are presentation bands, not FIRST severity categories. The trend compares daily EPSS probabilities, not percentile ranks; “pp” means percentage points. The sparkline shows relative movement, with its vertical scale fitted to the observed scores.

Already protected by existing Atomicorp rules No new CVE-specific rule required.

Atomicorp ModSecurity protection

Protected by Atomicorp rules

Atomicorp ModSecurity rules block attacks exploiting this vulnerability when blocking is enabled. Keep your rules current.

By targeting underlying attack techniques and CWE weakness classes, existing rules can protect against newly disclosed vulnerabilities. Rule changes are regression-tested against attack and false-positive corpora.

2 rules identified Verified 2026-10-21 View rules & research details →

WAF protection applies to the tested attack paths; it does not change the CVSS or EPSS score. Keep your software patched and your Atomicorp rules current.

CISA SSVC assessment

CISA ADP · Assessed 2024-05-13 · SSVC 2.0.3

Exploitation
Active exploitation
Automatable
No
Technical Impact
Total

Stakeholder-Specific Vulnerability Categorization records CISA’s assessment of exploitation, automation, and technical impact. “None reported” reflects the assessment date; it does not establish that no exploit exists. View SSVC source details.

On this page

CVE Details

Technical vulnerability details · CVSS assessments, exploit evidence & CPE data

CVSS assessments

CVSS v3.1 · security-advisories@github.com

  • Base score: 9.8
  • Base severity: CRITICAL
  • Exploitability subscore: 3.9
  • Impact subscore: 5.9
  • Assessment type: Secondary
  • Source identifier: security-advisories@github.com
  • Full vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    • Attack vector: Network
    • Attack complexity: Low
    • Privileges required: None
    • User interaction: None
    • Scope: Unchanged
    • Confidentiality impact: High
    • Integrity impact: High
    • Availability impact: High
  • Exploit maturity: Not scored

CVSS v3.1 · NVD

  • Base score: 9.8
  • Base severity: CRITICAL
  • Exploitability subscore: 3.9
  • Impact subscore: 5.9
  • Assessment type: Primary
  • Source identifier: nvd@nist.gov
  • Full vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    • Attack vector: Network
    • Attack complexity: Low
    • Privileges required: None
    • User interaction: None
    • Scope: Unchanged
    • Confidentiality impact: High
    • Integrity impact: High
    • Availability impact: High
  • Exploit maturity: Not scored

Exploitability and impact subscores describe the vulnerability’s technical characteristics. Exploit maturity describes the reported state of exploitation; these are separate measures.

Assessment source: NVD record · CVE record

CISA SSVC assessments

These are CISA’s published decision points at the assessment time. They are not a complete organization-specific prioritization decision.

  • Provider: CISA ADP
  • Provider identifier: 134c704f-9b21-4f2e-91b3-4a467353bcc0
  • SSVC version: 2.0.3
  • Role: CISA Coordinator
  • Assessment timestamp: 2024-05-13T17:39:57.218915Z
  • Exploitation: active
  • Automatable: no
  • Technical Impact: total
  • Source: CISA ADP in the CVE record

Exploit references

The CVE source data tags these references as exploits. A reference alone does not establish reliability or active exploitation.

Vulnerable CPE configurations

  • cpe:2.3:a:cacti:cacti:*:*:*:*:*:*:*:*
    • Version end (exclusive): 1.2.23
    • NVD match criteria ID: B252EEC1-25BE-428B-96CA-22A0E812D3BA

Vulnerability Description

Cacti is an open source platform which provides a robust and extensible operational monitoring and fault management framework for users. In affected versions a command injection vulnerability allows an unauthenticated user to execute arbitrary code on a server running Cacti, if a specific data source was selected for any monitored device. The vulnerability resides in the remote_agent.php file. This file can be accessed without authentication. This function retrieves the IP address of the client via get_client_addr and resolves this IP address to the corresponding hostname via gethostbyaddr. After this, it is verified that an entry within the poller table exists, where the hostname corresponds to the resolved hostname. If such an entry was found, the function returns true and the client is authorized. This authorization can be bypassed due to the implementation of the get_client_addr function. The function is defined in the file lib/functions.php and checks serval $_SERVER variables to determine the IP address of the client. The variables beginning with HTTP_ can be arbitrarily set by an attacker. Since there is a default entry in the poller table with the hostname of the server running Cacti, an attacker can bypass the authentication e.g. by providing the header Forwarded-For: <TARGETIP>. This way the function get_client_addr returns the IP address of the server running Cacti. The following call to gethostbyaddr will resolve this IP address to the hostname of the server, which will pass the poller hostname check because of the default entry. After the authorization of the remote_agent.php file is bypassed, an attacker can trigger different actions. One of these actions is called polldata. The called function poll_for_data retrieves a few request parameters and loads the corresponding poller_item entries from the database. If the action of a poller_item equals POLLER_ACTION_SCRIPT_PHP, the function proc_open is used to execute a PHP script. The attacker-controlled parameter $poller_id is retrieved via the function get_nfilter_request_var, which allows arbitrary strings. This variable is later inserted into the string passed to proc_open, which leads to a command injection vulnerability. By e.g. providing the poller_id=;id the id command is executed. In order to reach the vulnerable call, the attacker must provide a host_id and local_data_id, where the action of the corresponding poller_item is set to POLLER_ACTION_SCRIPT_PHP. Both of these ids (host_id and local_data_id) can easily be bruteforced. The only requirement is that a poller_item with an POLLER_ACTION_SCRIPT_PHP action exists. This is very likely on a productive instance because this action is added by some predefined templates like Device - Uptime or Device - Polling Time.

This command injection vulnerability allows an unauthenticated user to execute arbitrary commands if a poller_item with the action type POLLER_ACTION_SCRIPT_PHP (2) is configured. The authorization bypass should be prevented by not allowing an attacker to make get_client_addr (file lib/functions.php) return an arbitrary IP address. This could be done by not honoring the HTTP_... $_SERVER variables. If these should be kept for compatibility reasons it should at least be prevented to fake the IP address of the server running Cacti. This vulnerability has been addressed in both the 1.2.x and 1.3.x release branches with 1.2.23 being the first release containing the patch.

  1. Maintain the observed Atomicorp protections. Keep your Atomicorp commercial rules current and confirm that the selected observed rules (344364 , 344370 ) have not been locally disabled. Atomicorp commercial rules are enabled by default. If you use Atomic WAF, review the applicable policy and rule settings.

  2. Apply the vendor’s remediation. WAF protection is defense in depth and does not replace upgrading or following the affected vendor’s guidance.

  3. Validate after changes. Confirm rule updates are current, review WAF events for the affected application, and test application behavior after vendor upgrades, mitigations, or local policy changes.

Research Notes

Atomicorp WAF protections are designed around attack techniques and exploit behaviors, allowing existing protections to apply across multiple vulnerabilities without requiring a unique rule for every CVE.

Public Vulnerability References

Test or Research Source

Research Note Context

This research note documents exploit-technique analysis associated with this vulnerability and references Atomicorp WAF protections observed during engineering review, testing, or validation activities.

Atomicorp security controls are generally designed to identify and mitigate attack techniques and exploit behaviors rather than individual CVE identifiers. As a result, protections developed for one vulnerability may also apply to related attack variants and future vulnerabilities using similar techniques.

Learn More

Atomicorp develops commercially supported security technologies for web applications, servers, endpoints, workloads, and legacy enterprise platforms.

Organizations interested in protecting systems against exploit techniques associated with vulnerabilities such as this one can learn more about:

  • Atomic ModSecurity Rules: commercially maintained WAF rules for ModSecurity deployments, including protections for web attacks, bots, scanners, malware, exploitation attempts, and emerging vulnerability classes.
  • Atomic WAF: an enterprise web application firewall with Atomicorp rules, centralized management, reporting, authentication controls, and operational tooling.
  • Atomic ModSecurity Integrator: a special licensing option for MSPs, MSSPs, OEMs, VARs, reverse proxy providers, and other integrators who want to incorporate Atomicorp ModSecurity rule technology into their own products or services.
  • Atomic OSSEC: an enterprise OSSEC-based intrusion detection, compliance, and security monitoring platform.
  • Atomic Protector: workload protection for Linux, web, cloud, data center, and hybrid environments.

For additional information, product evaluations, or technical discussions, visit https://www.atomicorp.com/ or https://modsecurity.io/ .