{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/cpes/cpe2.3aredhatopenshift_container_platform/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:redhat:openshift_container_platform:*:*:*:*:*:*:*:*"],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-93017"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["OpenShift Container Platform"],"_cs_severities":["high"],"_cs_tags":[],"_cs_type":"advisory","_cs_vendors":["Red Hat"],"content_html":"\u003cp\u003eRed Hat OpenShift Container Platform is impacted by a critical privilege escalation vulnerability (CVE-2026-93017) stemming from an overly permissive ClusterRole assigned to the \u003ccode\u003einsights-operator\u003c/code\u003e. The \u003ccode\u003einsights-operator-gather\u003c/code\u003e ClusterRole incorrectly grants the \u003ccode\u003egather\u003c/code\u003e service account \u003ccode\u003eget\u003c/code\u003e and \u003ccode\u003elist\u003c/code\u003e permissions for \u003ccode\u003esecrets\u003c/code\u003e in the core API group, without limiting the scope to specific namespaces or resources. This effectively permits the service account to access every secret across the entire cluster.\u003c/p\u003e\n\u003cp\u003eAn attacker who has gained the ability to create pods or influence pod specifications - for instance, through a compromised developer account or an application-layer injection vulnerability - can mount the \u003ccode\u003egather\u003c/code\u003e service account to an attacker-controlled pod. Once the pod is running with this identity, the attacker can use standard Kubernetes API calls to retrieve secrets, such as API keys, database credentials, or TLS certificates, leading to a complete compromise of sensitive information stored within the cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a vulnerability (e.g., remote code execution or unauthorized access) allowing pod creation or modification within the cluster.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious pod specification that mounts the \u003ccode\u003egather\u003c/code\u003e service account using \u003ccode\u003eserviceAccountName: \u0026quot;gather\u0026quot;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAttacker deploys the malicious pod into the cluster via the API server.\u003c/li\u003e\n\u003cli\u003eThe pod executes, gaining the elevated permissions associated with the \u003ccode\u003egather\u003c/code\u003e service account.\u003c/li\u003e\n\u003cli\u003eAttacker executes \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e or makes equivalent API requests from within the pod.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server grants the request due to the over-privileged ClusterRole.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates gathered secrets to external infrastructure to achieve final objectives.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation results in full exposure of cluster-wide secrets, including but not limited to database credentials, service-to-service authentication tokens, and TLS private keys. This can facilitate lateral movement within the cluster, escalation to other services, and access to external resources secured by the compromised credentials.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eReview the current cluster-wide RBAC policies for the \u003ccode\u003einsights-operator\u003c/code\u003e and restrict the scope of the \u003ccode\u003einsights-operator-gather\u003c/code\u003e role to only those namespaces and resources strictly necessary for its telemetry-gathering function.\u003c/li\u003e\n\u003cli\u003eImplement Kubernetes Admission Controllers or Policy-as-Code (such as OPA Gatekeeper or Kyverno) to prevent the arbitrary mounting of sensitive service accounts by user-defined pods.\u003c/li\u003e\n\u003cli\u003eAudit existing pods and service account bindings to identify unauthorized use of the \u003ccode\u003egather\u003c/code\u003e service account.\u003c/li\u003e\n\u003cli\u003eMonitor cluster API audit logs for suspicious \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e requests on \u003ccode\u003esecrets\u003c/code\u003e resources originating from the \u003ccode\u003egather\u003c/code\u003e service account.\u003c/li\u003e\n\u003c/ol\u003e\n","date_modified":"2026-10-08T17:14:37Z","date_published":"2026-10-08T17:14:37Z","id":"https://feed.craftedsignal.io/briefs/2026-10-openshift-insights-rbac/","summary":"A misconfiguration in the OpenShift insights-operator ClusterRole grants the 'gather' service account cluster-wide read access to secrets, enabling privilege escalation for attackers who can spawn pods with that identity.","title":"Excessive RBAC Permissions in Red Hat OpenShift insights-operator","url":"https://feed.craftedsignal.io/briefs/2026-10-openshift-insights-rbac/"}],"language":"en","title":"CraftedSignal Threat Feed - Cpe:2.3:a:redhat:openshift_container_platform:*:*:*:*:*:*:*:*","version":"https://jsonfeed.org/version/1.1"}