What Is a Cloud Vulnerability? Most Definitions Stop Short
Ask ten security teams what a cloud vulnerability is and you'll get ten answers that range from "misconfigured S3 bucket" to "zero-day in a container runtime." None of them are wrong. Most of them are incomplete.
A cloud vulnerability is any weakness in a cloud platform, its APIs, its identity model, or its operational tooling that an attacker can exploit to gain unauthorized access, disrupt services, or exfiltrate data. That definition covers the obvious stuff—publicly accessible databases, overly permissive IAM roles, unpatched container images. But the most dangerous cloud vulnerabilities aren't flaws in code. They're flaws in trust relationships between systems. Design gaps where two security boundaries each assume the other is doing the checking.
Google's Config Connector, disclosed publicly in August 2025 by independent cloud security researcher Justin O'Leary, is that kind of vulnerability. It has no CVE. It won't show up in your scanner. Google calls it working as intended. And if you're running GKE with Config Connector deployed—which Google's own documentation recommends you configure with organization-level permissions—your Kubernetes namespaces are the attack surface for your entire cloud estate.
This is what AI cloud vulnerabilities actually look like in production. Not some exotic model injection. A YAML file and a missing authorization check.
The Tool That Built the Attack Surface
Config Connector (KCC) is Google's open-source Kubernetes operator. It lets you declare GCP infrastructure—projects, IAM policies, storage buckets, billing configurations—as Kubernetes resources. You write YAML, apply it with kubectl, and KCC translates that into API calls against Google Cloud.
The design goal is legitimate. Developers shouldn't need direct cloud credentials to provision a database. They write a manifest; KCC creates the resource using a centralized service account. Credential sprawl drops. GitOps workflows tighten. Teams ship faster.
But here's the structural problem. The KCC service account holds broad Google Cloud permissions, often Organization Admin, because working out the exact minimum set of permissions for a sprawling infrastructure fleet is genuinely difficult. Google's documentation acknowledges this difficulty. Meanwhile, Kubernetes users who submit resource requests don't need GCP identities at all. That's the entire point.
Two boundaries. Neither one validates what the other should.
How ConfigConfusion Works: The Confused Deputy Pattern
O'Leary dubbed this ConfigConfusion. The technique exploits what security researchers call a confused deputy, a pattern where a privileged service acts on behalf of a less-privileged user without verifying whether that user should actually be authorized for the requested action.
The exploitation path takes seconds. O'Leary's proof of concept, presented at ARMO's CyberKubernetes conference during Black Hat in Las Vegas, walks through it:
- An attacker obtains kubectl access to any Kubernetes namespace where KCC operates. They have zero GCP permissions.
- They craft an IAMPolicyMember resource specifying their own email, their target organization ID, and the role
roles/owner. - They apply it.
kubectl apply -f takeover.yaml.
KCC checks whether the Kubernetes user is authorized to create an IAMPolicyMember resource. The answer is yes, they have namespace permissions. KCC checks whether its own service account can grant organization-level roles. The answer is yes, that's what it's configured to do. Neither check asks the question that matters: does the person submitting this request deserve to grant Organization Owner to themselves?
The user-controlled organization ID flows straight through to the Google Cloud IAM API. KCC executes using its own service account credentials. The attacker becomes Organization Owner. Projects, secrets, billing accounts, Gmail addresses belonging to colleagues, all accessible.
The audit trail shows KCC's service account as the actor. Not the attacker's identity. Good luck tracing it back forensically.
Why Google's Response Tells You More Than the Bug
Google rated ConfigConfusion P1/S1, their highest priority and severity classification, on March 27th. They told O'Leary "Nice catch!" Eleven days later, Google Security Bot reversed course entirely. Bug bounty denied. "Working as intended."
O'Leary's characterization of the flaw is more precise than Google's framing: "It's more of a security design issue, or an insecure default if you like. There's nothing fundamentally broken within KCC, just a lack of a key security check."
That distinction matters for any organization running cloud infrastructure. The vulnerability isn't that KCC has a coding error. The vulnerability is that KCC was designed so users don't need cloud identities, and that same design removes the only input you'd need to validate cloud-level authorization. Google's own write-up acknowledges the obvious fix, check whether the requesting user has the corresponding cloud permission, would require every Kubernetes user to have a GCP identity, which would undermine KCC's purpose. Our parallel coverage of how Google handled the ConfigConfusion disclosure walks the timeline in detail.
That's the real cloud vulnerability. Not a bug. A structural gap between two authorization systems that each assume the other covers this case.
The Pattern Isn't Unique to Google
This is where the story gets uncomfortable for anyone managing multi-cloud Kubernetes. O'Leary identified the same logic in AWS Controllers for Kubernetes (ACK) and Azure Service Operator v2. All three tools bridge Kubernetes RBAC with cloud IAM using a privileged intermediary. All three face the same confused deputy question: does the system verify that the requesting Kubernetes user should be able to trigger the cloud action they're asking for?
The detection angle compounds this. Because KCC authenticates to GCP using its own credentials, Cloud Audit Logs records the KCC service account as the actor for any resource creation. The attacker's Kubernetes identity never touches the GCP audit plane. A privilege escalation that takes five seconds to execute becomes nearly invisible in standard logging.
What Organizations Running KCC Should Do Right Now
Google's recommended mitigations focus on reducing what KCC can do, since changing how KCC authorizes requests would require rearchitecting the tool:
- Audit KCC service account permissions. Remove broad roles like
roles/ownerunless strictly required. Work out the minimum set. This is hard, which is why most orgs never do it, and exactly why this attack persists. - Restrict IAM resource creation. Limit who can create
IAMPolicyMember,IAMPolicy, andIAMPartialPolicyresources in your namespaces. This is the single most effective mitigation, remove the ability to submit the attack payload. - Monitor organization-level IAM changes. Alert on any IAM modifications KCC makes at the organization level, especially those not flowing through your established GitOps pipeline.
None of these are silver bullets. They're damage reduction.
What ConfigConfusion Means for Cloud Vulnerability Management
The AI cloud infrastructure space is racing toward declarative everything. GitOps pipelines, operators that manage cloud resources as code, AI-assisted infrastructure provisioning layered on top of these abstractions. Each layer of abstraction introduces a new boundary between who requested something and who executed it.
ConfigConfusion isn't going away. No CVE means it won't trigger your vulnerability scanners. No patch means it won't close with a maintenance window, where a patch does exist, the race to apply it is exactly the dynamic AI cybersecurity companies tracking exploit spread flag whenever a fix goes public. The fix here requires architectural changes that conflict with the tool's design goals.
The takeaway for security teams: your vulnerability management process probably assumes that known flaws have known fixes. ConfigConfusion breaks that assumption. The right response to a cloud vulnerability like this isn't a patch cycle, it's a permissions review. Ask what your operators can actually do. Ask who can submit resources to them. Ask whether your audit logs can even distinguish between legitimate and malicious activity when the actor field is always the same service account. It is the same question at the heart of most corporate data exposure risks: abstraction that hides who touched what.
The answers to those questions are uncomfortable. That's the point.
