A newly disclosed vulnerability named ImageRunner, uncovered by Tenable Research, exposed a subtle yet powerful privilege escalation pathway in Google Cloud Platform’s Cloud Run service. This vulnerability, now patched by Google, allowed attackers with minimal permissions to illegitimately access and deploy private container images, effectively bypassing standard access control boundaries within a GCP environment. The discovery of this vulnerability raises significant concerns about the effectiveness of the least privilege principle within cloud environments.
1. Recognizing the Vulnerability
The ImageRunner vulnerability was identified by Tenable Research, revealing a critical flaw in how Google Cloud Run revisions are deployed. Specifically, the issue revolved around the use of service agents to pull container images from the Google Artifact Registry or the legacy Container Registry. Google has since patched this vulnerability, but its existence highlights crucial weaknesses in the cloud service’s access control mechanisms.
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. The deployment or updating of these services involves the use of a dedicated service agent to fetch the specified container image and spin up the service. This process, under certain conditions, allowed attackers to exploit service agents for nefarious purposes.
2. Understanding the Exploit
The ImageRunner vulnerability can be traced back to the intricate deployment process of Google Cloud Run services. When updating these services, service agents play a crucial role in fetching container images from repositories. Tenable discovered that certain interaction paths between service agents and container registries within Cloud Run could be exploited to bypass existing security controls.
The core of the problem lies in the permissions granted to users interacting with Cloud Run services. By acquiring specific IAM permissions, attackers could indirectly manipulate the deployment processes. Service agents, operating with elevated permissions, were inadvertently turned into tools that facilitated unauthorized access to private container images and deployment of unintended service revisions.
3. Exploitation Pathway
Tenable demonstrated a precise exploitation pathway that required only two IAM permissions to be effective:
run.services.updateiam.serviceAccounts.actAs
With these permissions, the attacker could perform several actions. They could update an existing Cloud Run service and create a new revision, specify any private image within the same project, inject malicious runtime instructions into the service’s container configuration, and leverage the Cloud Run service agent to run the modified container. These actions effectively bypassed the need for direct artifactregistry.reader or storage.objectViewer permissions on the image.
Attackers exploiting this vulnerability could potentially access sensitive data embedded in private images, exfiltrate embedded secrets, SSH keys, credentials, or environment variables, and run arbitrary code under the identity of the Cloud Run service. The minimal permissions needed to execute this attack path underscored a significant gap in the access control frameworks normally employed in cloud environments.
4. Potential Outcomes
The ramifications of the ImageRunner vulnerability were far-reaching. Attackers with access to the vulnerable system could exploit it to access sensitive data contained within private images, including secrets, SSH keys, credentials, and environment variables. This unauthorized access could lead to severe data breaches and compromise critical security postures.
Additionally, the exploitation of this vulnerability allowed attackers to run arbitrary code within the compromised Cloud Run service’s context. By injecting malicious runtime instructions, attackers could execute unauthorized commands that could further compromise the integrity and security of the affected systems. This capability amplified the potential damage that could be wrought through what appeared to be minimal privilege IAM roles.
5. Demonstration Mechanics
Tenable’s proof-of-concept (PoC) effectively demonstrated the severity of the ImageRunner vulnerability. Their approach involved using a benign container image uploaded to a GCP project’s private Container Registry. The attacker would then re-tag the image as private and store it in the victim’s registry using docker push.
Next, a new Cloud Run revision was crafted, specifying the private image along with injected container arguments. For example, the instructions might include bashCopyEditnc -lnvp -e /bin/bash. Upon deployment, the Cloud Run service agent, which had the necessary access to pull private images, would inadvertently execute the injected payload, giving the attacker a remote shell on the running container. This methodology showcased how attackers could gain significant control over the compromised environment without needing direct access to the image or repository.
6. Google’s Response
In response to the discovery of the ImageRunner vulnerability, Google took immediate action. On January 28, 2025, Google implemented a breaking change that required any principal (user or service account) attempting to deploy a Cloud Run revision to have explicit read access to the referenced container image(s). This update curtailed the ability of service agents to be exploited as implicit privilege escalators.
Additionally, Google communicated with affected users and organizations through Mandatory Service Announcements and release notes. These notifications urged Cloud Run users to review their IAM roles, permissions, and deployment policies to ensure that security practices were sufficiently robust to prevent similar vulnerabilities in the future.
7. Implications for Cloud Security
The ImageRunner vulnerability exemplified a broader concept identified by Tenable, known as the “Jenga” vulnerability pattern. This pattern describes how a vulnerability in one foundational cloud service can propagate risks to higher-level dependent services. In the case of ImageRunner, a flaw in the behavior of service agents impacted the security of Cloud Run deployments, revealing unintended access paths.
This concept requires security teams to adopt a holistic view of cloud security, recognizing that cloud services are interdependent and dynamically interconnected. Rather than treating each service as an isolated component, security must model and evaluate how they interact, share trusts, and what permissions they implicitly grant within the cloud ecosystem.
8. Guidance for Cloud Architects and DevSecOps Teams
Service Agents’ Elevated Permissions
Service agents within GCP often hold elevated permissions necessary to perform their operational tasks. This inherent power can turn them into potential blind spots for privilege escalation if not carefully scoped and monitored. Understanding and mitigating the risks posed by these privileged identities is critical for maintaining a secure cloud environment.
Minimal Privilege Isn’t Sufficient
The principle of least privilege suggests granting users the minimum permissions necessary for performing their tasks. However, ImageRunner demonstrated that even minimal IAM roles could indirectly grant access to protected resources by leveraging trusted services like Cloud Run. Therefore, organizations should consider transitive privilege paths and more rigorously enforce access controls.
Risks in CI/CD Pipelines
Continuous integration and continuous deployment (CI/CD) pipelines frequently involve dynamic updates to Cloud Run services. Developers and automation tools within these pipelines, if not strictly constrained, can inadvertently become vectors for privilege abuse. Ensuring that identity boundaries and container image permissions are strictly enforced within CI/CD workflows is essential to secure the deployment processes.
9. Suggested Preventative Measures
For GCP Users
Organizations utilizing GCP should take several steps to mitigate the risks highlighted by ImageRunner:
- Review and Scope IAM Permissions: Focus on limiting the scope of permissions such as
run.services.updateandiam.serviceAccounts.actAs. - Enable Artifact Registry Access Logging: Implement access logging mechanisms to detect unauthorized access attempts on the Artifact Registry.
- Use Binary Authorization and Policy Controls: Enforce image signature verification to prevent unauthorized images from being deployed.
- Regularly Audit Service Agents and Roles: Conduct regular audits of service agents and their assigned roles to ensure that permissions are not overly permissive.
For Security Teams
Security teams need to adopt advanced strategies to safeguard cloud environments:
- Cloud Threat Modeling: Implement threat modeling around GCP services and service agents to better understand potential attack vectors.
- Detection Integration: Integrate detection for Cloud Run updates targeting sensitive images into SIEM/SOAR platforms such as Chronicle and Cortex XSIAM.
- Runtime Monitoring: Use runtime monitoring agents to detect reverse shells or suspicious commands within containerized environments.
Conclusion
A recently revealed vulnerability, named ImageRunner, discovered by Tenable Research, highlighted a critical yet nuanced privilege escalation route in Google Cloud Platform’s Cloud Run service. This flaw, which Google has since fixed, provided attackers with minimal permissions the ability to inappropriately access and deploy private container images, effectively circumventing the usual access control measures within a Google Cloud Platform environment. This weakness underscores major concerns regarding the adequacy of the least privilege principle, a key concept for securing cloud environments, as it questions whether current practices are sufficient in preventing unauthorized access within such platforms. The exposure of this vulnerability serves as a stark reminder of the ongoing need for rigorous security measures and constant vigilance in cloud service infrastructures to protect against such exploitation and maintain robust security postures.
