CVE-2024-3019

What it actually does

Default pmproxy configuration binds the Redis backend to the local network interface, permitting unauthenticated adjacent-network attackers to issue Redis commands and achieve remote code execution under the Redis service account when the pmproxy service is active.

Why it matters to the business

If the metrics proxy service is manually enabled, attackers on the same network segment can gain unauthorized control of affected hosts, potentially leading to data exfiltration, persistence, or lateral movement; the issue is limited to non-default configurations but affects all PCP 4.3.4 and newer deployments that start pmproxy.

How an attack unfolds

An attacker on the same network segment discovers a host running pmproxy, connects directly to the exposed Redis listener, and abuses Redis features such as module loading or Lua scripting to execute arbitrary commands with the privileges of the Redis user.

How to fix it

Disable pmproxy unless metrics proxying is required; otherwise bind Redis and pmproxy exclusively to localhost or trusted interfaces, enforce network segmentation with host firewalls, and apply any vendor configuration hardening for PCP versions 4.3.4 and newer.

How to confirm the fix worked

Review pmproxy and Redis configuration files for bind addresses, use network scanners to confirm no external exposure on Redis ports, and verify that pmproxy is not running unless explicitly needed via system service status checks.

Typical attack path

1. Scan adjacent network for hosts listening on pmproxy/Redis ports
2. Establish unauthenticated TCP connection to the exposed Redis backend
3. Issue Redis commands to load malicious modules or execute system commands
4. Escalate or persist using the resulting shell under the Redis account

How to detect it

Inspect pmproxy and Redis logs for unexpected remote connections, review service startup history for manual activation of pmproxy, and correlate network flow data showing traffic to Redis ports from non-local addresses.

• pmproxy listening on non-loopback addresses
• Redis TCP connections from adjacent-network hosts
• Unexpected Redis MODULE LOAD or EVAL commands in redis.log

What your security team should do

• Immediately audit all systems for running pmproxy instances and disable where metrics proxying is unnecessary
• Implement host-based firewall rules restricting Redis and pmproxy ports to localhost or approved management subnets
• Add configuration review of PCP components to standard hardening baselines
• Monitor for any future vendor patches addressing the default exposure