CloudNativePG instance manager (status server, TCP/8000 control endpoints): A set of operator-only control endpoints

Impact

A set of operator-only control endpoints (/pg/mode/backup, /update, /pg/archive/partial, /pg/controldata) sit on the same unauthenticated mux as the kubelet probes on TCP/8000 of every PostgreSQL pod, with network isolation as the only intended boundary — and even with status-port-tls enabled the server never requested or verified a client certificate. Any workload that can reach that port without a NetworkPolicy in the way can drive backup orchestration, trigger WAL and checkpoint activity, and read operational metadata including replication and WAL state, the system identifier, and pg_controldata output. The vendor is careful to bound this: single-flight and self-cleaning backup control means bounded DoS and transient storage pressure, not unbounded WAL exhaustion, secret disclosure or code execution. The lesson for a cluster operator is the assumption, not the severity — a component shipped with 'protected by NetworkPolicy' as its security model, in clusters where NetworkPolicies are frequently absent or permissive.

Who can reach it

Adjacent network / in-cluster, unauthenticated. Any pod able to open TCP/8000 on a PostgreSQL instance pod qualifies, which in a cluster with no restricting NetworkPolicy means every pod including tenant workloads.

What to do

Apply a NetworkPolicy restricting TCP/8000 on instance pods to the operator — this is the mitigation for all currently supported releases, since the hardening was not backported. Upgrading to 1.30.0 adds in-process operator authentication as defence in depth: the operator generates an in-memory ECDSA P-256 client certificate at startup, publishes the SHA-256 fingerprint in .status.operatorCertificateFingerprint, and the instance manager rejects calls to the sensitive endpoints without it. Probe endpoints and /pg/status stay unauthenticated by design.

References

Related entries

• Slurm (user_name / gid field handling): Slurm trusts the user_name and gid fields carried in job RPCs instead ofCVE-2018-10995 · Slurm (user_name / gid field handling)Medium
• IBM Spectrum LSF (job submission, file permissions): Weak file permissions in the LSF install let a local user changeCVE-2018-1724 · IBM Spectrum LSF (job submission, file permissions)Medium
• AMD IOMMU host buffer access - insufficient RMP checks (AMD-SB-3016): Insufficient RMP checking on IOMMU host bufferCVE-2023-20585 · AMD IOMMU host buffer access - insufficient RMP checks (AMD-SB-3016)Medium
• ZKTeco BioAccess IVS v3.3.1 access control platform: An unauthenticated attacker can open and close any doorCVE-2023-38958 · ZKTeco BioAccess IVS v3.3.1 access control platformMedium
• Intel Data Center GPU Flex Series - Windows driver software: Improper access control in the Flex Series Windows driverCVE-2024-43101 · Intel Data Center GPU Flex Series - Windows driver softwareMedium
• Grafana: Org Admin can read dashboard permission mappings belonging to other organizationsCVE-2026-11817 · Grafana access-control API (/api/access-control/users/permissions/search), multi-org stacksMedium