CVE-2026-16527

CVE-2026-16527 is an unauthenticated remote code execution vulnerability in the Performance Co-Pilot (PCP) pmproxy daemon's /store endpoint. The attack surface is straightforward: any network-adjacent actor can send metric data to this endpoint, which the system processes in ways that allow arbitrary code execution on the host. No credentials, no user interaction, no firewall exception needed — just a network path to pmproxy's port 4432 (or whatever port it's bound to). The root cause isn't a subtle logic flaw — it's a trust boundary drawn at the wrong architectural layer. Monitoring infrastructure historically operated on the assumption that metric sources are inherently trusted because they originated from known agents, scheduled jobs, or internal instrumentation. The /store endpoint was almost certainly built for legitimate uses: dynamic metric injection, automated tooling, or integration with collection pipelines. But that design assumed the endpoint would live inside a trusted network zone. When that assumption breaks — and in cloud/containerized environments, it breaks constantly — you don't get a configuration quirk; you get a direct command pipeline from the public internet to code execution on the host. The EPSS score of 0.00395 is almost certainly underweight. Exploitation requires no authentication, no user interaction, and yields full system compromise. The gap likely reflects limited visibility into PCP deployment footprints combined with probability models calibrated on traditional services rather than monitoring infrastructure that was never supposed to face untrusted input. Treat this as internet-exposed until proven otherwise. What to do now: First, verify whether pmproxy is running in your environment and which port it binds to (default 4432). Check if the /store endpoint is accessible from untrusted networks — this includes not just the public internet but any network segment where workloads from different trust domains operate. If pmproxy is exposed to the internet or to multi-tenant network segments, treat it as an active RCE vector. Second, audit your broader monitoring stack for similar patterns. The 'metrics are just data' assumption that produced this vulnerability has appeared in collectd's unixsock plugin, Graphite's whisper storage, and Prometheus endpoints. These internal APIs were designed for trusted collection infrastructure and almost never received security review for internet adjacency. If you're running any monitoring daemon with an API endpoint that wasn't explicitly designed for unauthenticated input, that endpoint is a candidate for the same failure mode. Third, map the blast radius. Compromising pmproxy doesn't just give you one host — it gives you the ability to poison every downstream consumer that trusts those metrics. You can hide real intrusions by normalizing anomalous data, trigger alert fatigue with synthetic load, or establish persistence by corrupting the baseline that 'normal' gets measured against. If pmproxy feeds into incident response tooling or alerting systems, the compromise of that data has tactical value far beyond the single host. Fourth, apply defense-in-depth while you assess patching. Network segmentation, egress filtering on monitoring infrastructure, and alerting on unexpected metric volume or value anomalies won't stop exploitation but can limit the dwell time and blast radius of an attacker who gets here first. The remediation window for monitoring infrastructure is often longer than for user-facing services because these systems occupy organizational blind spots — owned by no one, maintained by everyone, and invisible until something breaks. Don't assume this is low-priority because it's 'just infrastructure.'

Reviewed through automated stages and approved by a human before publication.