ImageRunner Vulnerability: Privilege Escalation in GCP Cloud Run

In the intricate tapestry of cloud infrastructure, the security of each thread is paramount, isn’t it? A single weakness, however subtle, can unravel defenses, exposing sensitive assets to compromise. Recently, the cybersecurity community turned its attention to Google Cloud Platform (GCP), following the disclosure of a significant privilege escalation vulnerability within its popular Cloud Run service.

Dubbed the ImageRunner Vulnerability by researchers at Tenable, this flaw highlighted the complex interplay of permissions and service interactions within sophisticated cloud environments. Understanding concepts like the Principle of Least Privilege is crucial in mitigating such risks. For more on recent GCP security developments, see the Google Cloud Next ‘25 recap.

This vulnerability wasn’t about bypassing firewalls or cracking encryption; it cleverly exploited the nuances of Identity and Access Management (IAM) permissions related to deploying containerized applications. It served as a stark reminder that even in highly managed serverless environments, meticulous permission configuration is non-negotiable.

Understanding how ImageRunner worked, its potential impact, and Google’s remediation provides invaluable lessons for securing modern cloud workloads. Let’s delve into the mechanics of this intriguing security flaw and the broader implications it holds for GCP Cloud Run Security.

Setting the Stage: Understanding Cloud Run and Registries

Before dissecting the vulnerability itself, it’s essential to grasp the key GCP components involved:

• Google Cloud Run: This is GCP’s fully managed compute platform that enables users to run stateless containers invocable via web requests or Pub/Sub events. It abstracts away infrastructure management, automatically scaling resources based on demand, offering a powerful serverless experience.
• Google Artifact Registry: The recommended and current solution within GCP for storing, managing, and securing container images and other package formats (like Maven and npm). It serves as a private repository from which services like Cloud Run pull images for deployment.
• Google Container Registry (GCR): The predecessor to Artifact Registry, GCR was a dedicated private Docker image storage service. While deprecated as of March 18, 2025, in favor of Artifact Registry, existing GCR instances and images remain relevant in many environments, and the ImageRunner vulnerability impacted both registry types.

Typically, when a user deploys an application to Cloud Run, they specify the URL of a container image residing in Artifact Registry (or potentially GCR or Docker Hub). Cloud Run then retrieves this image to spin up the necessary container instances. This seemingly straightforward process involves specific IAM permissions and underlying service agents, which became the focal point of the ImageRunner Vulnerability.

Unpacking the ImageRunner Vulnerability: Exploiting Implicit Trust

Discovered by Tenable security researcher Liv Matan, the ImageRunner Vulnerability stemmed from a critical gap in permission enforcement during the Cloud Run service deployment or update process. At its core, it allowed an identity with specific, limited permissions to perform actions far exceeding its intended scope.

The Permission Mismatch

The vulnerability hinged on identities possessing a particular combination of IAM permissions within a GCP project:

1. run.services.update: Permission to modify existing Cloud Run services.
2. iam.serviceAccounts.actAs: Permission to impersonate a service account.

Crucially, the vulnerable scenario involved identities that held these permissions but explicitly lacked the necessary permissions to directly read images from Artifact Registry (e.g., roles/artifactregistry.reader) or Container Registry (e.g., Storage Object Viewer). Logic would suggest such an identity shouldn’t be able to deploy a service using a private image it cannot read, right?

This is where the exploit mechanism came into play.

Abusing the Deployment Process: The Service Agent’s Role

Each time a Cloud Run service is deployed or updated, a new immutable “revision” is created. Behind the scenes, GCP utilizes a service agent – a Google-managed service account – to perform essential tasks associated with the service. In the context of Cloud Run deployments, this service agent is responsible for actually pulling the specified container image from the registry.

The exploit worked as follows:

1. Attacker Gains Initial Foothold: An attacker obtains credentials or compromises an identity possessing the run.services.update and iam.serviceAccounts.actAs permissions within the target GCP project.
2. Modify Cloud Run Service: Using the run.services.update permission, the attacker modifies an existing Cloud Run service configuration to deploy a new revision.
3. Specify Arbitrary Private Image: During the update, the attacker specifies the URL of anyprivate container image residing in Artifact Registry or Container Registry within the same project, even if the attacker’s own identity cannot access that image directly.
4. Service Agent Performs the Pull: The Cloud Run service agent (identified by Tenable potentially related to the Cloud Functions agent, e.g., [email protected]), acting with its own, broader set of permissions granted by Google Cloud, dutifully pulls the image specified by the attacker. This agent did possess the necessary permissions to access the registries.
5. Permission Bypass Achieved: The attacker effectively bypassed the need for direct registry read permissions by leveraging the implicit trust and capabilities granted to the underlying service agent handling the deployment mechanics.

This IAM Misconfiguration Risk allowed the attacker’s limited permissions (run.services.update, iam.serviceAccounts.actAs) to indirectly trigger an action (pulling any private image) that should have required explicit registry read access.

Potential Impact: Beyond Unauthorized Image Access

The consequences of successfully exploiting the ImageRunner Vulnerability were significant:

• Access to Sensitive Images: Attackers could pull and inspect proprietary container images containing sensitive code, intellectual property, or embedded secrets.
• Code Injection and Execution: By modifying the service configuration during the update, attackers could inject malicious instructions (as container arguments or commands). When the container spun up using the compromised image definition, this malicious code would execute within the container’s context.
• Data Exfiltration & Secret Theft: The injected code could be used to scan the container environment, extract hardcoded secrets or service account keys, or exfiltrate sensitive data accessible from within the container.
• Reverse Shell: As demonstrated conceptually by Tenable using an ncat example, attackers could potentially establish a reverse shell connection from the compromised container back to a machine under their control, granting them interactive access.

This vulnerability effectively turned a permission set intended for service management into a powerful vector for Google Cloud Privilege Escalation and unauthorized data access within the Container Security GCP context.

The Fix: Google’s Remediation and Enhanced Checks

Following responsible disclosure by Tenable, Google Cloud implemented a crucial fix to address the ImageRunner Vulnerability. The core change involved enforcing an explicit permission check during the deployment process:

Mandating Explicit Deployer Permissions

The fix ensures that the principal(the user or service account initiating the Cloud Run service creation or update) must now possess explicit read permissions for the container image(s) being deployed. Simply having run.services.update and iam.serviceAccounts.actAs is no longer sufficient to pull an image the deployer cannot directly read.

Specifically, when using Artifact Registry, the deploying principal must have the roles/artifactregistry.reader IAM role (or equivalent permissions) on the project or specific repository containing the image. This closes the gap exploited by ImageRunner, aligning the required permissions with the action being performed.

Timeline and Communication

Google completed the 100% rollout of this breaking change to production by January 28, 2025. Recognizing the potential impact on existing workflows, Google sent Mandatory Service Announcements (MSAs) to affected project, folder, and organization owners during the last week of November 2024, advising them of the upcoming change.

The update was also detailed in the Cloud Run release notes. This proactive communication aimed to give customers time to adjust their IAM policies and ensure legitimate deployments wouldn’t be interrupted.

The Need for Vigilance

ImageRunner, along with other vulnerabilities previously disclosed by Tenable (like CloudImposer and ConfusedFunction, also cited as Jenga examples), demonstrates the potential for novel privilege escalation paths arising from these service interconnections.

It emphasizes the need for both cloud providers and customers to remain vigilant: providers must rigorously audit internal service interactions, and customers must meticulously manage IAM permissions, adhering strictly to the principle of least privilege. Attackers will continuously probe these complex interactions, making ongoing security assessment crucial.

Conclusion: Lessons Learned from ImageRunner

The ImageRunner Vulnerability serves as a critical case study in modern cloud security. It underscores that:

1. IAM is Paramount: Correct and granular IAM configuration is fundamental to GCP security. Misconfigurations or overly broad permissions, even seemingly innocuous ones, can be chained together for significant impact.
2. Implicit Trust is Dangerous: Relying on the implicit permissions of underlying service agents without explicit checks on the initiating user can create exploitable gaps.
3. Cloud Complexity Breeds Risk: The interconnected nature of cloud services (“Jenga”) necessitates a holistic security view, considering how services interact and potentially inherit risks.
4. Provider Responsibility & Customer Diligence: While Google acted responsibly by patching the flaw and notifying users, customers remain responsible for implementing least privilege and verifying their configurations align with security best practices.

While ImageRunner is now fixed, the lessons learned remain pertinent. Continuous vigilance, rigorous IAM management, and an understanding of the underlying service mechanics are essential to maintaining a robust security posture in dynamic cloud environments like Google Cloud Platform.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected]

Frequently Asked Questions (FAQ) about the ImageRunner Vulnerability

What was the ImageRunner vulnerability?

ImageRunner was a privilege escalation vulnerability in Google Cloud Run (GCP) discovered by Tenable. It allowed users with specific update permissions, but without direct registry access, to pull arbitrary private container images from Artifact Registry/Container Registry within the same project by exploiting the permissions of an underlying service agent.

Why was the ImageRunner vulnerability significant?

It was significant because it allowed attackers to bypass intended IAM controls, potentially leading to unauthorized access to sensitive container images, code injection, data exfiltration, or even remote code execution within the deployed container environment, escalating privileges significantly.

How was the ImageRunner vulnerability exploited?

Attackers with run.services.update and iam.serviceAccounts.actAs permissions could modify a Cloud Run service to use any private image in the project. The Cloud Run service agent, possessing broader permissions, would then pull the image, effectively executing the action on behalf of the attacker who lacked direct permission.

When was the ImageRunner vulnerability fixed?

Google completed the rollout of the fix by January 28, 2025. The fix ensures the deploying user/service account has explicit read permission for the container image. Affected customers were notified starting in late November 2024.

Who discovered the ImageRunner vulnerability?

The ImageRunner vulnerability was discovered and reported to Google by security researchers at Tenable, specifically credited to Liv Matan in the provided reports.