Python's exec() function will run whatever you give it. The only thing standing between user-supplied code and the underlying system is what you choose to restrict — and in this case, a SaaS platform forgot to restrict __builtins__.

A researcher discovered that a createUserDefinedFunction GraphQL mutation passed user-defined code directly into an exec() sandbox without setting {'__builtins__': {}}. That single omission left the entire Python built-in function library available. Arbitrary code execution inside a Google App Engine container running Python 3.13 followed without meaningful friction.

In a standalone application, that is a serious finding. In a cloud-hosted environment, it is the starting position for something worse.

The Cloud Context Changes Everything

From inside the GAE container, the path to full cloud identity takeover is well-documented and reliable. SSRF to the GCP metadata service at 169.254.169[.]254 — an internal endpoint accessible from any compute instance by design — returned a signed OIDC JWT for the platform's production service account. That token authenticates as the service account across GCP APIs. Storage buckets, secrets, other services running under the same identity — all of it now accessible to an unauthenticated researcher who started with a GraphQL mutation.

This is the cloud-specific amplification pattern that on-premises RCE does not reproduce cleanly. The metadata service is not a misconfiguration. It is the intended mechanism for credential distribution to compute workloads. Its reachability from user-code execution environments is the misconfiguration — and it is one that survives intact across a large proportion of cloud deployments because network-layer isolation of execution sandboxes is not a default, it is a deliberate choice that has to be made.

Defender Actions

  • Sandbox all user-executed Python with {'__builtins__': {}} as the minimum baseline — review any exec() or eval() call in your codebase that does not explicitly restrict the builtins namespace
  • Block outbound access to 169.254.169[.]254 from any environment that executes user-supplied or externally-influenced code at the network layer, not the application layer
  • Apply least-privilege service account scoping — production service accounts should not carry permissions beyond what the workload requires; lateral movement from a stolen JWT is bounded by what that identity can actually reach
  • In SIEM, alert on metadata endpoint access from application processes, particularly where the source is a user-facing execution environment

The sandbox failed before the cloud was ever involved. The cloud made the consequence total.

None