Executive Summary

Security researchers identified a privilege escalation risk in Google Cloud environments related to Cloud Functions deployments, known as ConfusedFunction. The issue arises because deploying or updating a Cloud Function automatically triggers a build process that runs under a powerful service account. If an attacker gains permission to modify a Cloud Function, they can indirectly leverage the default Cloud Build service account to obtain broader access to cloud resources, including sensitive data, source code, and other services within the project.

Organizations using Google Cloud should review service account permissions, enforce least privilege, and monitor build activity associated with Cloud Functions deployments.

The risk hidden in plain sight

Most privilege escalation attacks announce themselves. ConfusedFunction does not. It moves through the deployment workflow that an engineer triggers every day, using a service account the platform automatically assigns, exercising permissions that nobody explicitly reviewed. By the time anything looks unusual, the access has already been used. ConfusedFunction is a direct example of this tension. The vulnerability does not rely on a software flaw or a zero-day exploit. It relies on how two cloud services interact during a routine deployment and on the assumption that the service account driving that interaction has been appropriately constrained. In most environments, that assumption does not hold.

The broader implication extends beyond this specific issue. As cloud ecosystems grow more interconnected, the interactions between services create access paths that are rarely reviewed, rarely visible, and increasingly attractive to attackers. Identity and permission abuse of this kind is not an edge case. It is becoming the standard playbook.

Breaking down the attack

The entry point: 
The attack begins with a single permission: the ability to create or update a Cloud Function. This is not an unusual permission. Developers working in GCP environments routinely hold it as part of their standard access. In many organizations, it would not trigger a second look during an access review. What is less visible is what that permission unlocks indirectly.

The trigger point: 
When a Cloud Function is deployed or updated, Google Cloud automatically triggers a Cloud Build job to handle the build and packaging process. That build job does not run under the identity of the deploying user. It runs under the default Cloud Build service account, which in many GCP projects has significantly broader permissions than the identity that initiated the deployment. This is the core of the ConfusedFunction issue. An attacker with permission to deploy a function does not need to directly escalate their own privileges. They trigger a deployment and piggyback on a more privileged identity that is automatically introduced.

The escalation: 
Because the default Cloud Build service account can interact with multiple cloud services, the attacker may gain indirect access to Cloud Build resources, storage buckets and function source code, artifact and container registries, and other sensitive project resources. Actions that were entirely outside the scope of the attacker's original permissions become accessible through a process initiated by the platform on their behalf.

Why most teams miss it

The activity that enables ConfusedFunction appears, on the surface, to be normal deployment behavior. A Cloud Function is updated. A Cloud Build job runs. Permissions are exercised by a legitimate service account. None of these events are inherently suspicious in isolation, which is precisely why this class of attack is effective. Traditional security monitoring tends to focus on direct privilege escalation, where an identity attempts to explicitly grant itself elevated permissions. ConfusedFunction bypasses that model entirely. The escalation is indirect, operating through a trusted automated process rather than through the attacker's own identity. Without visibility into how service accounts interact during build and deployment workflows, the activity is effectively invisible to most detection approaches.

What to watch for

Security teams monitoring for ConfusedFunction-related activity should focus on interactions between Cloud Functions and Cloud Build, rather than watching either service in isolation. Key areas to track include:

• Unexpected Cloud Function creation or updates
• Unusual Cloud Build executions
• IAM policy changes following build activity
• Access to sensitive resources triggered during builds

Centralised logging across Cloud Build, IAM, and Cloud Functions events is the baseline requirement. Without a unified view of how these services interact, the correlation needed to surface suspicious behaviour simply cannot happen.

How to reduce your exposure

Immediate Actions (0 to 24 Hours): 
The first priority is understanding the current exposure. Security teams should review which identities hold permissions to create or update Cloud Functions and audit the default Cloud Build service account to understand what it can access. In many GCP projects, this service account has never been explicitly scoped and carries permissions far beyond what any individual build job requires.

Short-Term Actions (24 to 72 Hours) 
Once the current state is visible, the next step is reducing it. Unnecessary IAM permissions on service accounts involved in build and deployment workflows should be restricted. Monitoring should be enabled for unusual Cloud Build activity, and access to sensitive resources reachable through a build job should be reviewed and rotated where appropriate.

Long-Term Posture 
Sustainable reduction of this risk requires treating service account governance as an ongoing practice rather than a one-time remediation. Least privilege access policies should be applied to all service accounts, with regular audits of cloud IAM permissions and build pipeline configurations. Automated deployment workflows should be subject to the same security review process as any other access grant, because in terms of the access they can exercise, they are equivalent.

How Unosecur closes the gap

ConfusedFunction is precisely the class of risk that traditional security tooling is not built to catch. The identities involved are legitimate. The activity looks normal. The escalation occurs through a process initiated by the platform, not through anything the attacker did directly. Catching it requires visibility into how service accounts behave across automated workflows, not just whether they exist. Unosecur maps every non-human identity in your environment, including the service accounts powering your build and deployment pipelines, and continuously monitors how those identities are used. When a service account accesses resources outside its expected pattern, that deviation is detected in real time rather than after the fact. Permissions that are broader than any workflow requires are flagged before they become exploitable.

For GCP environments specifically, Unosecur provides the identity-level visibility needed to answer the questions ConfusedFunction exposes: which service accounts are involved in Cloud Functions deployments, what they can access, and whether that access is appropriate for the tasks they actually perform. Those are not questions most teams can answer today. They need to be.

This is bigger than one vulnerability

ConfusedFunction is one instance of a vulnerability class that is increasingly relevant across major cloud platforms. The pattern is consistent: automated workflows carry powerful identities, those identities are rarely reviewed with the same rigor applied to human access, and attackers who understand the interactions between cloud services can exploit that gap without triggering conventional detection. The identities involved in build, deployment, and automation pipelines are not passive. They authenticate, they access data, they modify resources, and in many environments they hold more effective privilege than any individual user. Treating them as a background concern rather than a primary governance target is what creates the conditions ConfusedFunction exploits.

The takeaway

ConfusedFunction is not an exotic attack. It requires no special tooling, no zero-day, and no sophisticated tradecraft. It requires one routine permission and the knowledge of what that permission quietly unlocks. That is what makes it dangerous, and that is why the identity layer is the only place where it can be reliably addressed. The service accounts that power your deployment automation are not background infrastructure. They are active identities with real access to real systems, and in many environments they are the least governed assets in the entire stack. That is not a configuration problem. It is a visibility problem. And visibility is where it has to start.