GPU VulnDB

Database/Container, Kubernetes & orchestration

IBM Instana Agent Operator: etcd client certificates copied out of openshift-etcd into a tenant namespace

CVSS 7.7CVE-2026-19283Container, Kubernetes & orchestrationcurated

Impact

The operator copies etcd mTLS client credentials out of the openshift-etcd system namespace so the agent can scrape etcd, but it does not validate where they are being copied to. A tenant who can point the copy at a namespace they own ends up holding a client certificate trusted by etcd itself. etcd is where every Secret in the cluster lives, including tenant service account tokens, image pull credentials and whatever the GPU nodes use to join, so this is a read of the cluster's entire secret store rather than a leak of one credential. Vendor score is 7.7 confidentiality-only with changed scope; this is a separate flaw from the RBAC collision in CVE-2026-19274 in the same advisory, with a different mechanism and a different cleanup.

Who can reach it

An authenticated remote user with rights to drive the operator's credential copy toward a namespace under their control. Requires only low-privilege authenticated access to the cluster API, not admin and not host access.

What to do

Take the fixed build from IBM support node 7286070; affected builds are 1.0.303 through 1.0.323 and the record does not state the fix level. Updating the operator is an image bump and pod restart, no node drain. Patching alone is not enough here because credentials may already have been copied: inventory Secrets in tenant namespaces for etcd client material, and rotate the etcd client certificates if any turn up outside openshift-etcd. Rotation on OpenShift is the expensive part of this one, not the operator upgrade.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.