The exposed information includes process arguments, full goroutine stacks, and memory content, which may contain hardcoded database connection strings, credentials, or sensitive application data extracted via heap dumps. Furthermore, an attacker can intentionally initiate CPU profiling tasks, leading to resource exhaustion and denial of service. The impact is significant for environments where internal cluster traffic is not strictly partitioned or where the metrics port is exposed to wider network segments.

Impact

Successful exploitation leads to unauthorized information disclosure, potentially resulting in the compromise of database credentials or internal system configuration details. Additionally, the vulnerability permits denial of service attacks against the exporter, which can disrupt monitoring pipelines and impact observability of the associated PostgreSQL instances.

Recommendation

• Audit network ingress policies for all pods running postgres-exporter to ensure the metrics port is not exposed to untrusted network segments.
• Upgrade the postgres-exporter deployment to a version where 'net/http/pprof' has been removed from the build.
• Implement network-level access control, such as Kubernetes NetworkPolicies, to restrict access to the metrics port to known monitoring server IPs only.
• Scan memory-resident secrets and configuration to ensure that the risk of credential leakage via heap dumps is mitigated by rotating any potentially exposed database passwords.