TL;DR: Unosecur shows how routine Cloud Functions deployments can trigger Cloud Build under a more powerful default service account, creating indirect privilege escalation and access to sensitive project resources. The case shows that automated deployment identities need the same governance discipline as human and workload accounts.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “ConfusedFunction: How a Routine GCP Permission Becomes a Privilege Escalation Risk”.
Key questions
Q: What breaks when a cloud deployment trigger can run under a more privileged service account?
A: The control boundary breaks between the person who initiates the change and the identity that actually executes it.
Q: Why do routine function deployments create privilege escalation risk in cloud environments?
A: They create risk because deployment workflows often call other services on the user's behalf, and those downstream identities can hold broader permissions than the original developer account.
Q: What are the signs that deployment automation has become overprivileged?
A: Look for build identities that can reach more resources than the deployment truly requires, especially when those rights are broader than the permissions held by the initiating user.
Practitioner guidance
- Review deployment-triggered service accounts Map which service accounts are activated by Cloud Functions deployment and update workflows, then compare their effective permissions with the permissions held by the initiating developers.
- Reduce default Cloud Build scope Replace broad project-level permissions with custom roles that only cover the build, package, and publish actions required for each pipeline.
- Correlate build and IAM logs Monitor Cloud Build executions alongside IAM policy changes and Cloud Functions updates so indirect escalation is visible in one investigation path.
Bottom line: ConfusedFunction shows that cloud privilege escalation can occur through ordinary deployment automation rather than through obvious account takeover or CVE exploitation.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of how Cloud Functions deployment invokes Cloud Build under the default service account
- Specific monitoring points for Cloud Build, IAM, and Cloud Functions events that help surface indirect escalation
- Guidance on tightening service account permissions for build and deployment workflows in GCP
- The article's full remediation sequence for replacing broad roles with scoped custom access
👉 Read Unosecur's analysis of ConfusedFunction and cloud build identity escalation →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
ConfusedFunction exposes a deployment identity gap, not a cloud bug. The security failure sits in the assumption that the identity initiating a change is the identity exercising the resulting access. Cloud automation breaks that assumption when Cloud Build runs under a different service account with broader rights. The practitioner consequence is that build-time identity and deploy-time identity must be governed as separate principals, not collapsed into one access review.
A few things that frame the scale:
- 83% of privilege escalation incidents involved no CVE exploitation, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: Should teams separate human deployer access from build executor access?
A: Yes. The deployer should be able to request a change without automatically inheriting the permissions of the build identity that executes it. That separation limits blast radius, preserves accountability, and prevents a legitimate automation path from becoming a privilege escalation channel. It also makes access review more meaningful because the executor's rights are explicitly governed.
👉 Read our full editorial: ConfusedFunction exposes privilege escalation through cloud build identity