# Chaining Misconfigurations to Full Cloud Compromise: A Case Study in GCP Exploitation

## Executive Summary

During a routine security monitoring exercise, our research team identified a chain of vulnerabilities in a major SaaS integration platform that culminated in complete compromise of its Google Cloud Platform (GCP) environment.

The weaknesses, discovered in a publicly accessible API endpoint, allowed us to:

* **Smuggle arbitrary HTTP methods** through the backend
    
* **Perform Server-Side Request Forgery (SSRF)** to internal GCP resources
    
* **Extract valid service account access tokens**
    
* **Access sensitive Google Cloud Storage buckets** containing cleartext credentials, database dumps, source code, and build artifacts
    

This case study demonstrates how **seemingly minor flaws** — when combined — can escalate into a full breach of a cloud perimeter.

---

## Discovery Context

Our team at ReactiveZero continuously monitors exposed internet-facing assets for security risks, following a methodology that prioritizes **manual testing over automated scanning**. This ensures that subtle, high-impact vulnerabilities are not overlooked.

In this instance, the issues were found in an API endpoint used for **testing HTTP client configurations**. While its purpose appeared benign, its lack of input sanitization and access control provided the perfect starting point for deeper exploitation.

---

## Vulnerability Chain

### 1\. HTTP Method Smuggling

**Vulnerable Endpoint:**

```plaintext
POST /api/v1/di/configurations/http-client/test
```

**Issue:**  
The endpoint accepted a JSON payload that included a `method` parameter — intended to specify the HTTP method used in outbound requests. The backend **directly trusted** this value without sanitization or whitelisting.

By supplying non-standard methods such as `PUT`, `TRACE`, or even arbitrary strings, we confirmed that the backend executed outbound requests with those methods intact.

**Security Implications:**

* Allows bypass of application-level filtering that only expects `GET` or `POST`
    
* Facilitates backend method smuggling for services with method-based access control
    
* Serves as a foundation for SSRF attacks, enabling more complex payload delivery
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1755167198005/6decb313-54a9-460c-9b46-5dd59771b508.png align="center")

---

### 2\. SSRF to GCP Metadata Service

Leveraging method smuggling was only the first step. By manipulating the `uri` parameter in the same endpoint, we achieved **Server-Side Request Forgery (SSRF)**.

**Targeted Internal Resource:**

```plaintext
http://169.254.169.254/computeMetadata/v1/
```

This is the **GCP metadata service**, accessible only from within GCP virtual machines. With SSRF, we bypassed the cloud provider’s perimeter protections and interacted with this service directly.

**What We Retrieved:**

* **Project ID** of the environment
    
* **Active service account identity**:  
    `572120218656-compute@developer.gserviceaccount.com`
    
* **Host and disk metadata**
    
* **Scheduling configurations**
    
* **Cryptographic identity materials** (`mds-client-certificate`), including:
    
    * `encrypted_credentials`
        
    * `key_import_blob` (with `encrypted_seed`)
        
    * `public_area` data
        

**Why this is serious:**  
Even without immediate decryption, access to such materials threatens the trust model of **confidential compute workloads** and **mTLS-based identity federation** in zero-trust architectures.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1755167218112/f354e505-1006-4fce-a785-24eb83c6aed8.png align="center")

---

### 3\. Access Token Extraction and Abuse

From the metadata service, we extracted a **valid OAuth2 access token** bound to the instance’s service account.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1755167241080/de51cf2f-85b7-431e-a306-9bb95042a85c.png align="center")

**With this token, we:**

* Authenticated to the **Google Cloud Storage API**
    
* Enumerated **all accessible buckets**
    
* Inferred **production, staging, and development environment separation**
    
* Identified **buckets belonging to third-party clients**
    

**Example bucket names (redacted where necessary):**

* `acc-******` (client environment)
    
* `dev-******` (development data)
    
* `default-webserver`
    
* `gcf-sources-*` (cloud function source code)
    
* `stamped-io-build-storage` (build artifacts)
    
* `staging.******.appspot.com` (staging data)
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1755167268207/add825ce-6c6e-44dd-b620-2d872d85af7b.png align="center")
    

---

### 4\. Unauthorized GCS Bucket Access

Bucket enumeration was only the beginning. The obtained token allowed **object listing and downloading** from multiple buckets — with no additional authentication challenge.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1755167363853/fa6b0da8-fdd2-430b-ae74-cc687d4b9e2a.png align="center")

**High-Risk Example:**

* `stamped-io-build-storage/fixtures/db.sql` — a **15MB SQL database dump** containing:
    
    * User account tables
        
    * **Cleartext administrator passwords**
        
    * Internal application data
        
    * Potentially **GDPR-regulated personal information**
        
* **Other Exposed Assets:**
    
* `.tar.gz` archives of build artifacts
    
* Function source code packages (`function-source.zip`)
    
* Region and policy metadata revealing operational geography (e.g., `EUROPE-WEST4` )
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1755167375395/e857e9c5-0931-402c-bc5b-703ce454bf73.png align="center")
    

---

## Root Causes

Our analysis identified three primary causes enabling this chain of exploitation:

1. **No HTTP method validation** in the configuration testing endpoint
    
2. **Lack of SSRF protection**, allowing direct interaction with internal cloud services
    
3. **Overly broad service account permissions** and **absence of bucket-level IAM restrictions**
    

---

## Potential Impact

An attacker exploiting these flaws could:

* **Exfiltrate sensitive databases**, including customer PII and authentication credentials
    
* **Steal proprietary code** and build pipelines
    
* **Compromise third-party client environments**
    
* **Perform privilege escalation** within GCP
    
* **Bypass network perimeter protections**
    

The GDPR implications alone — given the exposure of personal data — could result in significant regulatory fines.

---

## Recommended Mitigations

We recommend the affected organization:

1. **Implement strict input validation** for HTTP methods, enforcing an allowlist (`GET`, `POST`)
    
2. **Deploy SSRF protection** using request sanitization and metadata service access restrictions (GCP’s `--no-allow-metadata-server-access`)
    
3. **Reduce service account scopes** to follow the principle of least privilege
    
4. **Apply bucket-level IAM deny-by-default policies** for sensitive assets
    
5. **Rotate and revoke exposed credentials** immediately
    

---

## Conclusion

This incident reinforces a critical truth in cloud security: **minor misconfigurations can combine into devastating exploits** when left unchecked. A harmless-looking “HTTP client test” feature became the entry point for complete cloud compromise.

ReactiveZero disclosed all findings under responsible disclosure guidelines. The affected organization has acknowledged the report and is in the process of remediation.

---

**About ReactiveZero**  
ReactiveZero specializes in precision penetration testing, delivering in-depth manual assessments of cloud, application, and network security. We help organizations uncover vulnerabilities before adversaries do.

📧 info@reactivezero.com  
📞 +31 6 2908 4840