[security] Unauthenticated endpoints expose runtime internals and allow CPU-exhaustion DoS

[geo-chen]

Hi, is there a place I can share details of a potential security vulnerability please?

[geo-chen]

(email report sent in on 27 May 2026 and bounced)

I am reporting a vulnerability in parca-dev/parca (confirmed on v0.28.0, commit 09e7d45).

The HTTP server registers Go's standard pprof debug endpoints at /debug/pprof/ and all sub-paths
on the same public-facing port (default 0.0.0.0:7070) with no authentication and no option to
disable or rebind them to a private interface. There is no auth middleware, no flag to restrict
these paths, and no way to move them to a separate port.

Root cause: pkg/server/server.go, lines 136-143, registers the pprof handlers inside the chi
router alongside the public API, with no auth wrapper. The parca flags include no option for
incoming-connection authentication.

Impact has two components:

1. Information disclosure. Any network-reachable client can retrieve heap profiles, goroutine
   stack dumps (including function arguments and stack frames that may contain in-memory secrets),
   allocs profiles, and Prometheus metrics. In a deployment where parca receives bearer tokens or
   TLS credentials as flags or environment variables, those values may appear in goroutine stacks.

2. CPU-exhaustion denial of service. The /debug/pprof/profile, /debug/pprof/fgprof, and
   /debug/pprof/trace endpoints accept a ?seconds=N query parameter. An unauthenticated attacker
   can send repeated requests with large N values, pinning a CPU core for the full duration. A
   handful of concurrent requests can saturate all available CPU.

PoC (tested against ghcr.io/parca-dev/parca:v0.28.0, default configuration, no extra flags):

Heap profile download:
curl http://target:7070/debug/pprof/heap -o heap.pprof
Response: HTTP 200, valid gzip pprof binary (~9 KB idle).

Goroutine dump:
curl "http://target:7070/debug/pprof/goroutine?debug=2"
Response: HTTP 200, plain-text goroutine stacks for all running goroutines.

CPU DoS (pins a core for 120 seconds):
curl "http://target:7070/debug/pprof/profile?seconds=120" -o /dev/null &
curl "http://target:7070/debug/pprof/profile?seconds=120" -o /dev/null &
Response: both requests hold the server at high CPU for 120 seconds.

Suggested mitigations (in increasing order of robustness):

• Add a --pprof-address flag that binds the pprof and metrics handlers to a separate
  loopback-only port (e.g., 127.0.0.1:7071), separate from the public API port.
• Alternatively, add --disable-pprof to remove the endpoints entirely.
• As a short-term advisory, document that parca must be deployed behind an authenticating
  reverse proxy if the port is reachable from untrusted networks.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L (5.8 Medium)
CWE-306: Missing Authentication for Critical Function