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

Activity

1. geo-chen commented on Jun 24, 2026

   

   geo-chen

   on Jun 24, 2026

   Author

   More actions

   (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