# Exposed Cloud Functions: Hardening GCP Serverless Against LFI & RCE

> Mandiant identifies exposed serverless functions as initial access points. Learn to harden Google Cloud Run against LFI and RCE with IAM, WAF, and secure SDLC.

- Published: 2026-07-15T17:23:18.000Z
- Severity: high
- Category: Cloud Security
- Tags: Google Cloud, Cloud Run, Serverless, LFI, Command Injection, RCE, WAF, Cloud Armor, IAM, Mandiant, Cloud Security Posture Management
- Author: Runtime Rebel Intel
- Primary source: https://cloud.google.com/blog/topics/threat-intelligence/exposed-cloud-functions-harden/
- Canonical: https://runtimerebel.com/blog/exposed-cloud-functions-hardening-gcp-serverless-against-lfi-rce

## Key points

- Immediate impact: Compromise of cloud environments, data exfiltration, and service takeover via vulnerable, exposed serverless functions.
- Affected systems: Publicly accessible Google Cloud Run services and functions often lack authentication and leverage default compute service accounts.
- Remediation: Implement defense-in-depth, including least-privilege IAM, WAF, and a secure software development lifecycle.

Mandiant security assessments frequently uncover publicly exposed serverless applications that lack proper authentication. These applications, often Google Cloud Run services and functions, run custom code incorporating third-party packages, making them prime targets for a range of application-level attacks. Successful exploitation, such as through Local File Inclusion (LFI) or Command Injection, can grant an attacker full control over the underlying container instance, establishing a foothold that could lead to a complete compromise of the victim’s cloud environment, according to [Google Cloud's blog](https://cloud.google.com/blog/topics/threat-intelligence/exposed-cloud-functions-harden/).

This analysis details common attack scenarios against exposed serverless functions and outlines actionable guidance for securing these environments. While the focus is on Google Cloud Run, the principles apply universally to any public serverless deployment.

## The Threat of Exposed Serverless Applications

Serverless applications, also known as Function-as-a-Service (FaaS), enable organizations to deploy individual code blocks as microservices within a flexible, event-driven cloud architecture without managing the underlying infrastructure. This architecture is crucial for scaling modern applications, including major e-commerce platforms, payment processing, and increasingly, generative AI workflows.

Publicly exposed serverless workloads represent a significant initial access point for threat actors. These services often contain vulnerabilities within their custom code, imported packages, or even the underlying runtime environment. Once an entry point is exploited, attackers commonly attempt [Privilege Escalation](/glossary#privilege-escalation) or [Lateral Movement](/glossary#lateral-movement) within the compromised environment. Observed techniques include:

*   **Extracting secrets**: Directly from application code or configuration files.
*   **Reviewing application logic**: Identifying further attack vectors or sensitive data.
*   **Exfiltrating service account bearer tokens**: Following successful [RCE](/glossary#rce) by targeting the metadata server.

Compromised secrets or service accounts can enable threat actors to pivot to adjacent systems and workloads. Without robust hardening strategies, this could result in a total cloud environment takeover.

## Attack Scenarios: LFI and Command Injection in Cloud Run

### Detecting Cloud Run LFI Vulnerabilities

In a common scenario, a Python/Flask function running on Cloud Run might accept user-controlled input to open a file without adequate validation. This represents an LFI vulnerability. For instance, a function using a `file` parameter directly in `open()`:

```
import functions_framework

@functions_framework.http
def hello_http(request):
    request_json = request.get_json(silent=True)
    request_args = request.args
    if request_json and 'file' in request_json:
        file = request_json['file']
    elif request_args and 'file' in request_args:
        file = request_args['file']
 
    with open(file, 'r') as resp:
          filedata = resp.read()
    return 'local file data {}!'.format(filedata)
```

An attacker can exploit this by sending a POST request to retrieve sensitive files. For example, `curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "main.py"}'` would return the application's source code. This code can then be analyzed for hardcoded secrets, business logic flaws, internal service endpoints, and technology stack details, which may reveal further [CVE](/glossary#cve) exposure. Furthermore, standard directory traversal (`../../../etc/passwd`) can be used to retrieve system files. Key files an attacker might target include `requirements.txt`, `package.json`, `.env` files, application configuration files (for credentials), and application logs.

### Mitigating Cloud Run Command Injection and Token Theft

Another critical vulnerability arises when a Python function uses shell execution methods with unsanitized user input, enabling command injection. Consider a function where user input directly feeds into `subprocess.run`:

```
import functions_framework
import subprocess

@functions_framework.http
def hello_http(request):
  request_json = request.get_json(silent=True)
  request_args = request.args
  if request_json and 'input' in request_json:
      input = request_json['input']
  elif request_args and 'input' in request_args:
      input = request_args['input']
  result = subprocess.run(input, shell=True,capture_output=True, text=True)
  return format(result)
```

An attacker can leverage this to execute arbitrary commands, specifically targeting the GCP metadata service to retrieve the service account’s bearer token. A `curl` request, such as `curl -X POST https://cloudrun02-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"`, can extract a bearer token valid for one hour.

Once obtained, this token can be used on an attacker-controlled system by setting the `CLOUDSDK_AUTH_ACCESS_TOKEN` environment variable. If the Cloud Run service operates under the default Compute Engine service account with broad `Editor` permissions, this token theft can lead to a full GCP project takeover, allowing attackers to:

*   Read, write, and delete most GCP resources.
*   Deploy new services or modify existing configurations.
*   Access secrets and encryption keys.
*   Exfiltrate data from accessible storage systems.
*   Establish persistent backdoors.

## Hardening Recommendations: GCP Serverless Security Best Practices

Mandiant recommends a parallel approach to effective serverless security, combining secure development practices with compensating runtime controls.

*   **Secure Software Development Lifecycle (S-SDLC)**: Integrate security scanning, code reviews, and least-privilege [IAM](/glossary#iam) into CI/CD pipelines. Implement continuous security testing before deployment.

*   **Vibe Coding Security**: For AI-generated code, ensure multi-layered security enforcement. Isolate AI experimentation in dedicated sandbox environments, enforce strict data egress controls, restrict development to approved IDEs with human-in-the-loop capabilities, and utilize verified plugins under [least privilege](/glossary#least-privilege) to mitigate [Supply Chain Attack](/glossary#supply-chain-attack) vulnerabilities. Adherence to S-SDLC controls and clear internal guidelines for AI use are critical.

*   **Compensating Runtime Controls**: Implement defense-in-depth measures to limit and contain compromise even when application vulnerabilities exist:

    *   **Segregate Public Services**: Host public-facing Cloud Run services in a dedicated, isolated Google Cloud project. This compartmentalization prevents a compromise from immediately affecting critical internal resources. Refer to the secured serverless architecture blueprint for detailed implementation.

    *   **Identity and Access Management ([IAM](/glossary#iam))**: Use custom service accounts for service authentication instead of the default Compute Engine service account. Adhere strictly to the principle of [least privilege](/glossary#least-privilege). For example, grant `Storage Object Viewer` (`roles/storage.objectViewer`) restricted to a specific bucket for read-only access, or `Secret Manager Secret Accessor` (`roles/secretmanager.secretAccessor`) only to individual secrets required.

    *   **Layer 7 Application Load Balancer (ALB) Architecture**: Restrict ingress traffic for serverless functions to internal-only and use an external Layer 7 ALB to manage internet exposure. This provides centralized traffic management, granular control over headers and SSL policies, Cloud Armor [WAF](/glossary#waf) integration for protection against LFI/RFI and SSRF, traffic shaping with rate limits, enhanced visibility through robust logging, and Identity-Aware Proxy (IAP) support for identity-based authentication.

    *   **Web Application Firewall ([WAF](/glossary#waf)) — Cloud Armor**: Integrate Cloud Armor with your Load Balancer to filter malicious traffic. Specifically, `lfi-v33-stable` preconfigured WAF rules can block common local file inclusion attacks, and `rce-v33-stable` rules can block remote code execution attempts. These rules can prevent attacks like path traversal (`../../../etc/passwd`) and the metadata service token extraction described previously.

    *   **Serverless Architecture Controls**: When using direct VPC egress or VPC Access connectors, leverage VPC Service Controls to restrict lateral movement and exfiltration through granular access policies. Hardening individual Cloud Run services is only one component of a secure architecture; defense-in-depth across interconnected Google Cloud resources is crucial.

*   **Cloud Run Threat Detection**: Beyond these hardening recommendations, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources, including credential access, reconnaissance, and the execution of scripts or reverse shells. This service is available for Premium and Enterprise tiers.

## Conclusion

Serverless applications offer immense agility and business value, especially with the rapid adoption of AI-driven development. However, this speed necessitates integrating security early in the development lifecycle, moving beyond default configurations, and prioritizing a robust defense-in-depth strategy centered on strong identity governance and secure architecture. Proactive vulnerability identification and continuous security testing are essential to neutralize threats before serverless functions become publicly accessible.

**Related:** [CVE-2025-29635: Mirai Exploits EoL D-Link Routers](/blog/cve-2025-29635-mirai-exploits-eol-d-link-routers), [Google Vertex AI SDK Model Hijacking via Bucket Squatting](/blog/google-vertex-ai-sdk-model-hijacking-via-bucket-squatting)

---

AI-generated analysis from the primary source above; not human-reviewed before publication — verify anything operational against the original (https://runtimerebel.com/editorial). Quote with attribution and a link to the canonical URL: https://runtimerebel.com/blog/exposed-cloud-functions-hardening-gcp-serverless-against-lfi-rce