Mandiant flags exposed cloud functions as breach entry points

Key Takeaways

• Publicly accessible serverless functions without authentication are a common initial access point for attackers
• Local File Inclusion and Command Injection vulnerabilities can give attackers full container control
• Attackers pivot by extracting secrets from code and stealing service account tokens from metadata servers

Mandiant security assessments keep finding the same problem: serverless functions sitting on the public internet with no authentication in front of them. In a blog post published July 16, 2026, Google's threat intelligence arm walks through exactly how attackers exploit these exposed cloud functions, from initial code execution to full environment takeover.

The attack chain is straightforward. A publicly exposed Google Cloud Run service or AWS Lambda function contains a vulnerability, often a Local File Inclusion (LFI) or Command Injection flaw. The attacker exploits it, gains control of the container, then pivots by stealing secrets from the code or exfiltrating service account tokens from the metadata server. From there, lateral movement across the cloud environment becomes possible.

Why serverless functions keep getting exposed

Serverless architectures have exploded alongside generative AI adoption. Chatbots, image generation pipelines, multi-step AI agents, all built on functions that spin up on demand. The business case is compelling: no infrastructure to manage, automatic scaling, instant deployment. But that speed creates risk.

Mandiant notes that many public deployments exist because of specific business requirements, not careless configuration. A webhook endpoint needs to receive external traffic. An API must serve third-party integrations. The function has to be public. The mistake is assuming that "public" and "unauthenticated" are the same thing.

These functions run custom code with third-party packages. That code often contains injection vulnerabilities. The packages often contain known CVEs. The runtime environment itself can be exploited. Each layer is an attack surface.

How the attack chain works

Mandiant's example is a Python/Flask function running on Cloud Run. It accepts a file parameter from user input and passes it directly to Python's open() function without validation. That's textbook LFI.

with open(file, 'r') as resp:
    filedata = resp.read()
return 'local file data {}!'.format(filedata)

An attacker sends a POST request asking for main.py. The function returns its own source code. Now the attacker can review hardcoded API keys, database credentials, authentication tokens, and internal service endpoints. They can map the technology stack from import statements and search for CVEs in those packages.

Standard directory traversal sequences like ../ let attackers read system files. From there, the metadata server becomes the prize. Successful remote code execution means the attacker can request the service account's bearer token from that metadata endpoint. With that token, they can impersonate the function's identity and access whatever cloud resources it can access.

The pivot to full compromise

Once attackers have a service account token, the game changes. They're no longer exploiting a single function. They're authenticated to your cloud environment with whatever permissions that service account holds.

Common post-exploitation moves include reviewing application logic to find additional attack vectors, accessing adjacent systems and workloads, and exfiltrating data from storage buckets or databases. If the service account has overly broad permissions, as many do by default, the attacker can escalate to full environment control.

Hardening strategies that actually work

The Mandiant guidance boils down to a few principles. First, add authentication even when a function must be publicly accessible. OAuth, API keys, or identity-aware proxy can sit in front of the function itself. "Public" should mean "reachable," not "open to everyone."

Second, validate all user input. The vulnerable code accepted a file path directly from the request. Input validation and output encoding prevent most injection attacks. This is basic application security, but serverless deployments often skip it because they feel like "just a small function."

Third, apply least-privilege to service accounts. A function that reads from one Cloud Storage bucket doesn't need write access to all buckets. It doesn't need access to BigQuery. It doesn't need the default compute service account's broad permissions. Scope service accounts to exactly what the function requires.

Fourth, block metadata server access when possible. Google Cloud's VPC Service Controls and AWS's IMDSv2 with hop limits can restrict token exfiltration from compromised containers.

• Add authentication to all public endpoints, even "internal" services
• Validate and sanitize all user-controlled input
• Apply least-privilege permissions to service accounts
• Restrict metadata server access with network controls
• Audit third-party packages for known vulnerabilities

The AI connection

Mandiant explicitly ties this risk to generative AI adoption. AI workflows depend heavily on serverless functions. A chatbot that processes user queries, an image generation pipeline that accepts prompts, an AI agent that executes multi-step tasks, all run on Cloud Run or Lambda or Azure Functions.

These AI-powered functions often accept complex, user-controlled input by design. They parse prompts, execute code (in "vibe-coding" scenarios), and interact with external services. The attack surface is larger than a traditional CRUD API. The consequences of compromise are more severe when the function has access to sensitive training data or can invoke privileged operations.

Frequently Asked Questions

What is a Local File Inclusion vulnerability in cloud functions?

Local File Inclusion occurs when a function accepts user input to open files without validating the path. Attackers can request sensitive files like source code, configuration files, or system data by manipulating the file parameter.

How do attackers steal service account tokens from serverless functions?

After achieving code execution, attackers query the cloud provider's metadata server, which runs on a well-known internal IP. The metadata server returns the service account's bearer token, which attackers can use to authenticate to other cloud services.

Should all serverless functions require authentication?

Yes. Even functions that must be publicly reachable should require authentication via API keys, OAuth, or identity-aware proxy. Public accessibility and open authentication are separate decisions.

What permissions should a serverless function's service account have?

Only the minimum permissions required for the function's task. A function reading from one storage bucket needs read access to that bucket only, not broad project-level permissions.

Why are AI workloads particularly vulnerable to these attacks?

AI functions often accept complex, user-controlled input by design. They may execute code, parse untrusted prompts, and access sensitive training data, creating a larger attack surface than traditional APIs.

Source: Cloud Blog