New Vulnerability in GCP Cloud Run Shows Why Least Privilege Isn’t Enough

A newly disclosed vulnerability dubbed ImageRunner, uncovered by Tenable Research, exposed a subtle yet powerful privilege escalation pathway in Google Cloud Platform’s Cloud Run service. The vulnerability, now patched by Google, enabled attackers with minimal permissions to illegitimately access and deploy private container images, effectively bypassing standard access control boundaries within a GCP environment.

🔍 Understanding the Vulnerability

The ImageRunner vulnerability revolved around how Google Cloud Run revisions are deployed, particularly the use of service agents to pull container images from Google Artifact Registry or the legacy Container Registry.

In GCP, a Cloud Run service is updated through the creation of a new revision. Each revision represents a version of the containerized application, defined by configuration and image references. While deploying or updating these services, Cloud Run uses a dedicated service agent (e.g., service-[PROJECT_NUMBER]@serverless-robot-prod.iam.gserviceaccount.com) to fetch the specified container image and spin up the service.

🚨 The Exploitation Path

Tenable demonstrated that a user with only two IAM permissions could exploit this deployment flow:

• run.services.update
• iam.serviceAccounts.actAs

These permissions, seemingly benign, allowed the user to:

1. Update an existing Cloud Run service and create a new revision.
2. Specify any private image within the same project—even if they lacked direct artifactregistry.reader or storage.objectViewer permissions on that image.
3. Inject malicious runtime instructions (e.g., reverse shells) into the service’s container configuration.
4. Leverage the Cloud Run service agent, which does have access to pull private images, to run their modified container.

By using this technique, attackers could:

• Access sensitive data embedded in private images.
• Exfiltrate embedded secrets, SSH keys, credentials, or environment variables.
• Run arbitrary code under the identity of the Cloud Run service.

🧪 Proof-of-Concept (PoC) Mechanics

Tenable’s PoC utilized a benign container image (raesene/ncat) uploaded to a GCP project’s private Container Registry. The attacker:

1. Pulled and re-tagged the image as private.
2. Used docker push to store it in the victim’s registry.
3. Then crafted a new Cloud Run revision specifying this private image along with injected container arguments: bashCopyEditnc -lnvp <port> -e /bin/bash
4. On deployment, the Cloud Run service agent pulled the image and executed the injected payload, providing the attacker with a remote shell on the running container.

This behavior occurred without needing direct access to the image or repository.

🧯 Google’s Response and Mitigation

Google addressed the vulnerability with a breaking change rolled out on January 28, 2025. As of this update:

• Any principal (user or service account) attempting to deploy a Cloud Run revision must explicitly have read access to the referenced container image(s).
• This ensures that service agents can no longer be exploited as implicit privilege escalators.

GCP notified affected users and organizations via Mandatory Service Announcements and release notes, urging them to review IAM roles, permissions, and Cloud Run deployment policies.

🧱 The “Jenga®” Vulnerability Pattern

ImageRunner exemplifies Tenable’s concept of the “Jenga” vulnerability architecture, where one cloud service is built upon another. In such a layered model:

“A vulnerability in a foundational service (e.g., service agents) can propagate risks upwards into dependent services (e.g., Cloud Run), resulting in unintended access paths.”

This concept, introduced by Tenable at Black Hat USA 2024, encourages security teams to model inter-service trust and privilege inheritance in cloud platforms, treating them as dynamic and interconnected systems—not isolated components.

🔐 Security Implications for Cloud Architects and DevSecOps

🔎 1. Service Agents as Blind Spots

Service agents in GCP often hold elevated permissions to perform their operational tasks. However, these identities can become shadow privilege escalators if not carefully scoped or monitored.

🛡️ 2. Least Privilege is Not Enough

Even when a user has minimal IAM roles, their ability to interact with trusted services like Cloud Run may grant indirect access to protected resources. Traditional least privilege enforcement must now account for transitive privilege paths.

⚙️ 3. DevOps Risks in CI/CD Pipelines

In many environments, developers and automation tools update Cloud Run services routinely. If identity boundaries and container image permissions aren’t strictly enforced, CI/CD pipelines may inadvertently become a vector for privilege abuse.

✅ Recommended Mitigations

For GCP Users:

• Review IAM permissions, especially run.services.update and iam.serviceAccounts.actAs, and scope them narrowly.
• Enable Artifact Registry access logging to detect unauthorized access attempts.
• Use binary authorization or policy controls to enforce image signature verification.
• Regularly audit service agents and their assigned roles.

For Security Teams:

• Implement cloud threat modeling around GCP services and service agents.
• Integrate detection for Cloud Run updates to sensitive images via SIEM/SOAR platforms (e.g., Chronicle, Cortex XSIAM).
• Use runtime monitoring agents to detect reverse shells or suspicious commands in containerized environments.

ImageRunner is more than just a privilege escalation flaw — it’s a powerful reminder of the complexity and interconnectedness of modern cloud services. As cloud providers abstract infrastructure, security must adapt to hidden layers of automation and delegation.

Cloud-native security teams must rethink traditional models of access control and continuously evaluate how platform services like Cloud Run, IAM, and Artifact Registry interact in real-world attack paths.