Google Patches Cloud Run Flaw That Could Have Exposed Container Images
A serious security vulnerability recently patched in Google Cloud Run could have allowed attackers to gain unauthorized access to container images, potentially enabling malicious code injection. Researchers uncovered the flaw, which stemmed from an issue with Identity and Access Management (IAM) permissions, and reported it to Google, who quickly released a fix.
Security researchers recently pulled back the curtain on a now-patched security hole in Google Cloud Platform's (GCP) Cloud Run. This flaw, a privilege escalation vulnerability, could have let attackers peek inside container images and even inject their own malicious code. Think of it as a sneaky back door into your cloud setup.
Tenable security researcher Liv Matan, in a report shared with The Hacker News, explained it this way: "The vulnerability could have allowed an attacker to abuse Google Cloud Run revision edit permissions to pull private images from Google Artifact Registry and Google Container Registry – all within the same account." You can read the full report here.
The security vulnerability has been dubbed "ImageRunner" by Tenable. The good news? Google patched it up on January 28, 2025, after Tenable responsibly disclosed the issue.
Google Cloud Run, for those unfamiliar, is a handy service for running containerized apps without having to worry about the underlying server infrastructure. When Cloud Run needs to deploy a service, it grabs container images from places like the Artifact Registry or Docker Hub.
So, what was the problem? Certain accounts have permission to edit Cloud Run revisions, but not permission to access the container registry. That's a recipe for trouble.
Every time you deploy or update a Cloud Run service, a new version, or "revision," is created. And each revision uses a service agent account to pull the necessary container images.
"If an attacker manages to snag specific permissions – run.services.update and iam.serviceAccounts.actAs – within a project, they could tweak a Cloud Run service and deploy a new revision," Matan said. "This allows them to specify any private container image within the project for the service to pull."
The potential damage? Attackers could get their hands on sensitive, proprietary images stored in your registries. Even worse, they could sneak in malicious code that, when executed, could be used to steal secrets, leak data, or even open a reverse shell for complete control.
Thankfully, Google's patch addresses this. Now, the user or service account creating or updating a Cloud Run resource must have explicit permission to access those container images.
As Google stated in their release notes, "The principal (user or service account) creating or updating a Cloud Run resource now needs explicit permission to access the container image(s)." If you're using Artifact Registry, make sure the account has the "Artifact Registry Reader" (roles/artifactregistry.reader) IAM role on the project or repository holding the container images.
Tenable describes ImageRunner as a "Jenga" vulnerability – a problem that arises from the interconnected nature of cloud services. Pull one piece, and the whole tower can wobble.
"Cloud providers build their services on top of their other existing services," Matan pointed out. "If one service gets attacked or compromised, the other ones built on top of it inherit the risk and become vulnerable as well."
In short, these interdependencies can create unexpected privilege escalation opportunities and hidden risks.
This disclosure comes shortly after Praetorian highlighted several ways a lower-privileged user could abuse an Azure virtual machine (VM) to gain control over an Azure subscription:
- Execute commands on an Azure VM associated with an administrative managed identity.
- Log in to an Azure VM associated with an administrative managed identity.
- Attach an existing administrative user-assigned managed identity to an existing Azure VM and execute commands in that VM.
- Create a new Azure VM, attach an existing administrative managed identity to it, and execute commands in that VM by using data plane actions.
"After obtaining the Owner role for a subscription, an attacker may be able to leverage their broad control over all subscription resources to find a privilege escalation path to the Entra ID tenant," Praetorian security researchers Andrew Chang and Elgin Lee explained. "This path is predicated on a compute resource in the victim subscription with a service principal with Entra ID permissions that may allow it to escalate itself to Global Administrator."
