Publicly exposed serverless functions, particularly on Google Cloud Run, often lack authentication due to business requirements, making them prime targets for application-level attacks like Local File Inclusion (LFI) and command injection. Mandiant‘s analysis shows that successful exploitation can give attackers full control over the container instance, which then serves as a foothold to compromise the entire cloud environment—especially when default service accounts with excessive permissions are used. The rapid adoption of AI workflows, including chatbots, image generation, and ‘vibe-coding,’ has significantly expanded the attack surface, making this a pressing concern for enterprise security teams.

Concrete attack scenarios are demonstrated using vulnerable Python/Flask functions. An LFI vulnerability allows an attacker to read source code, hardcoded secrets, and system files like /etc/passwd via unvalidated file parameters. A command injection vulnerability lets an attacker extract the service account’s OAuth 2.0 bearer token from the metadata server, which can then be used to run Google Cloud CLI commands with the service account’s privileges. If that account has Editor permissions, the result is a full project takeover. Hardening recommendations include using a custom least-privilege service account, segregating public services in a dedicated isolated project, and deploying a Layer 7 Application Load Balancer with Cloud Armor WAF rules (e.g., lfi-v33-stable and rce-v33-stable) to block malicious traffic before it reaches the function.

For serious builders, the key takeaway is that security must be integrated into the development lifecycle from the start—not bolted on after deployment. Default configurations are dangerous; always use custom service accounts with the minimum required permissions. For AI-generated code, enforce sandboxed environments, human-in-the-loop review, and strict egress controls. While these examples focus on Cloud Run, the principles of defense-in-depth, traffic filtering, and identity-based access control apply universally to any public serverless deployment. Proactive vulnerability scanning and continuous security testing remain the ideal standard, but runtime controls provide essential protection when vulnerabilities inevitably slip through.