Secure your Vercel apps with Prowler: lessons from the April 2026 breach

Amit Sharma

April 26, 2026

This is some text inside of a div block.

On April 19, 2026, Vercel disclosed that an attacker had read customer environment variables out of its systems. Whether your secrets were in that set came down to one setting: whether you had stored them as “sensitive” or as “plain.” Plain-type variables decrypt to readable text. Sensitive ones never return in plaintext, so they stayed out of the leak.

That difference is the kind of misconfiguration a routine scan surfaces in minutes. This post covers what happened on April 19, why platforms like Vercel are a blind spot for tools built around AWS, Azure, and GCP, and the specific Prowler checks that map to the controls Vercel told its customers to turn on.

The new attack surface

Developers are shipping AI-assisted web apps to Vercel: Next.js paired with AI SDKs, chatbot interfaces, LLM wrappers, internal tools. Each one runs on infrastructure Vercel abstracts away, which is good for developer velocity and bad for visibility. Most security tooling was built for AWS, Azure, and GCP, and it has no view into where your frontend runs or how it is configured.

Environment variables are the new secrets manager. Vercel projects store API keys, database credentials, and third-party tokens as environment variables. If those variables are stored as “plain” type instead of “sensitive,” their values are readable in the Vercel dashboard and API responses. Every team member with project access can see them. Every API call returns them in cleartext. And anyone who gets into the account can read them too.

Preview deployments are an attack vector. Every pull request triggers a preview build. If production secrets are shared with preview environments, an external contributor can fork your repo, modify the build process, and exfiltrate those credentials through a preview deployment. This is not theoretical. It is how environment variable exfiltration works on platforms with automatic preview builds.

WAF and firewall features exist but are opt-in. Vercel ships a Web Application Firewall, rate limiting, IP blocking, and managed rulesets. But they are not enabled by default. Most teams deploying AI-powered frontends have not configured any of them. Their applications are directly exposed to SQL injection, XSS, and brute-force attacks.

Team access sprawl goes unchecked. SSO is enabled but not enforced, so members can still bypass your identity provider. Too many people have the Owner role. Invitations sit pending for months. No directory sync means offboarded employees may still have access.

These are not edge cases. They are the default state of most Vercel teams that have not done a security review. On April 19, 2026, that default state stopped being hypothetical.

Exactly what happened on April 19, 2026

Attackers reached customer data without ever touching a customer’s password. They got in through a third-party AI tool, pivoted into Vercel’s systems, and walked out with environment variables belonging to a subset of customers. Within days, a threat actor claiming to represent the ShinyHunters group put the stolen data up for sale on the cybercrime forum BreachForums.

The attack never started at Vercel. It started with a third party.

A Vercel employee used Context.ai, a third-party AI tool. An attacker compromised Context.ai, reportedly through Lumma Stealer infostealer malware on a Context.ai employee’s machine.
That access let the attacker take over the Vercel employee’s individual Google Workspace account.
From the Google Workspace account, they logged into the employee’s Vercel account.
Inside Vercel, they pivoted through systems and were able to enumerate and decrypt non-sensitive environment variables belonging to a subset of customers.

The key phrase from Vercel’s own incident report is that the exposed data was “non-sensitive environment variables stored on Vercel (those that decrypt to plaintext).” Vercel lets you store an environment variable as plain, encrypted, or sensitive. Only the sensitive type is encrypted in a way that is never returned in plaintext. Everything else can be read back. The attacker read back exactly those.

The consequences

Environment variables are where modern apps keep their most sensitive credentials: cloud access keys for AWS, Azure, and GCP, database credentials, third-party API tokens, and GitHub tokens that can deploy to production. Any of those sitting in plaintext is a direct path to your infrastructure, your customer data, or your source code.

The fallout was immediate. The seller advertised customer API keys, source code, and database data, and claimed a $2 million ransom in messages with Vercel. For affected customers, cleanup meant rotating every secret that had been stored in plaintext, combing through AWS CloudTrail, Azure Activity Logs, and GCP Audit Logs for signs of misuse, and auditing GitHub for unauthorized deploy keys and OAuth apps.

Vercel’s own remediation guidance told customers to enable MFA, review and rotate any environment variable not marked sensitive, turn on the sensitive variables feature, review account activity, and raise Deployment Protection to at least Standard. That guidance is the tell. Almost every fix Vercel recommended is something a security scan could have flagged before the breach, not after.

How Prowler would have kept your secrets out of the leak

You could not have stopped Vercel from being breached. That was a compromise of Vercel’s own systems through a third-party tool, and no scan of your own account would have flagged it. What you did control was your blast radius: whether your secrets were in the set the attacker could read back. Prowler can’t see inside Vercel’s systems and won’t catch an intrusion in progress. What it does is keep the readable set small, so a platform compromise is worth less.

The breach exposed environment variables that decrypt to plaintext. Secrets stored as the sensitive type are encrypted and never returned in plaintext, so they were not in the exposed data. The entire difference between “my keys are for sale on BreachForums” and “I slept fine that week” came down to one setting.

Prowler checks that setting. Here is how the Vercel provider maps directly to this incident:

project_environment_no_secrets_in_plain_type flags any environment variable that looks like a secret (names ending in _KEY, _SECRET, _TOKEN, _PASSWORD, _API_KEY, _PRIVATE_KEY) but is stored as plain instead of sensitive. This is the exact misconfiguration the attacker exploited. Fix these and your secrets are not readable, even by someone who gets into your account.
project_environment_production_vars_not_in_preview catches production secrets shared with preview deployments, which limits how far a single compromise can spread.
project_deployment_protection_enabled and project_production_deployment_protection_enabled map to Vercel’s “raise Deployment Protection” guidance.
team_saml_sso_enforced addresses the identity path the attacker actually used. The break-in rode an individual Google Workspace account into Vercel. Enforced SSO plus MFA is what closes that door.
authentication_no_stale_tokens and authentication_token_not_expired keep long-lived API tokens from becoming the next quiet way in.

In other words, the post-breach checklist Vercel handed its customers is a checklist Prowler runs for you continuously, before anyone breaks in.

What Prowler checks

Prowler’s Vercel provider ships with 26 security checks across six service areas. Here is what it covers.

Authentication (2 checks): Stale API tokens unused for 90+ days, expired or soon-to-expire tokens.
Deployment (1 check): Production deployments sourced from feature branches instead of main/master.
Domain (3 checks): Misconfigured DNS records, invalid or missing SSL certificates, unverified domains.
Project (10 checks): Secrets in plain text, production env vars leaking to preview, deployment protection disabled, directory listing enabled, fork protection off, skew protection off, auto-exposed system variables, overly broad env var targeting.
Security (5 checks): WAF disabled, managed rulesets off, no rate limiting configured, no IP blocking rules, no custom firewall rules.
Team (5 checks): SAML SSO not enabled, SSO not enforced, owner role not least-privilege, stale invitations, no directory sync.

Every check includes a severity rating, remediation guidance, and risk context. Let’s look at the ones that matter most.

Secrets stored as plain-text environment variables

Severity: High

This is the exact setting behind the April 2026 breach. Vercel offers three environment variable types: plain, encrypted, and sensitive. The “plain” type stores values in cleartext, visible in the dashboard and returned in API responses. The “sensitive” type encrypts values and never exposes them after creation.

Prowler checks every environment variable whose name ends with known secret suffixes: _KEY, _SECRET, _TOKEN, _PASSWORD, _API_KEY, and _PRIVATE_KEY. If any of those are stored as “plain,” it flags them. The suffix list is configurable through Prowler’s audit config, so you can add patterns specific to your stack.

This is one of those findings that looks obvious in hindsight but is surprisingly common. Teams create environment variables quickly during development, pick “plain” because it is the simplest option, and never revisit the choice. The customers whose data ended up for sale online are the ones who never revisited it.

Production secrets leaking to preview deployments

Severity: Medium

If a secret-type environment variable targets both the production and preview environments, every pull request build gets access to those production credentials. Combined with fork protection being disabled (a separate check), this creates a direct exfiltration path: an attacker forks your repo, modifies the build step to print or POST the environment variables, and opens a PR. The preview build runs automatically with your production secrets.

Prowler checks for this specific combination: encrypted or secret-type variables that target both production and preview simultaneously. The fix is straightforward. Use separate, limited-scope credentials for preview environments so a single leak does not hand over production.

WAF not enabled

Severity: High

Vercel’s Web Application Firewall protects against OWASP Top 10 threats including SQL injection, cross-site scripting, and request smuggling. Prowler does not just check whether WAF is enabled. It runs five separate checks across the full firewall stack:

WAF enabled on the project.
Managed rulesets activated (Vercel-curated rules for known attack patterns).
Rate limiting configured to prevent brute-force and DDoS.
IP blocking rules in place for known malicious sources.
Custom firewall rules for application-specific protection (admin panels, API routes).

If your Vercel project serves an AI chatbot or any application that accepts user input, having no WAF is an open door.

SSO enabled but not enforced

Severity: Critical

This is one of the most common identity misconfigurations across any platform, and it is the kind of gap the April 2026 breach exploited. A team enables SAML SSO, connects their identity provider, and considers the job done. But without flipping enforcement on, team members can still log in with their personal credentials, completely bypassing your IdP, MFA policies, and conditional access rules. That is exactly how attackers rode an individual account into a Vercel environment.

Prowler checks both states: whether SSO is enabled and whether it is enforced. The gap between those two is where credentials get compromised.

Secure your Vercel deployments in minutes

The fastest way to get the breach checklist running against your own account is Prowler Cloud. No agents, no infrastructure to deploy, no sales call.

With Prowler Cloud:

Navigate to Configuration > Cloud Providers.
Click “Add Cloud Provider” and select Vercel.
Paste your Vercel API token and optional Team ID.
Launch a scan.

First results land in minutes. You get a dashboard with pass/fail counts across all checks, finding details with remediation steps, and the ability to schedule daily scans. Try Prowler Cloud free, no credit card required, at cloud.prowler.com.

[ SCREENSHOT: Prowler Cloud Vercel scan results dashboard ]

[ SCREENSHOT: Adding Vercel as a provider in Prowler Cloud ]

Prefer to run it yourself? Every Vercel check is open source Python under the Apache 2.0 license, so you can read exactly what Prowler tests and run the same scan from the CLI:

export VERCEL_TOKEN='your-api-token' prowler vercel

Results land in your terminal, exportable to JSON (OCSF format), HTML, or CSV. From there you can import those findings into Prowler Cloud for centralized visibility across accounts and to automate remediation. See the import findings guide.

For the full setup guide including token creation, team scoping, and configuration options, see the Vercel provider documentation. To browse every Vercel check with descriptions and severity ratings, visit Prowler Hub.

Part of your multi-cloud security posture

Vercel does not exist in isolation. Your Vercel frontend calls AWS APIs, stores data in Azure databases, runs inference on GCP, pulls secrets from environment variables that mirror what is in your cloud accounts. The April 2026 breach proved the point: the secrets exposed on Vercel were keys into AWS, Azure, GCP, and GitHub. Securing Vercel without visibility into the rest of your stack is a partial picture.

Prowler covers 16 providers in a single platform: AWS, Azure, GCP, Kubernetes, Microsoft 365, Google Workspace, GitHub, Cloudflare, Alibaba Cloud, Oracle Cloud, MongoDB Atlas, OpenStack, NHN Cloud, container images, Infrastructure as Code, and now Vercel. Your Vercel security posture sits alongside everything else in one dashboard, so when a platform like Vercel is breached you can check exposure across every connected account at once.

Every check is open source Python under the Apache 2.0 license. You can read exactly what Prowler tests, modify checks to match your organization’s requirements, or contribute new ones. All findings output in OCSF (Open Cybersecurity Schema Framework) format, immediately consumable by any SIEM, SOAR, or data platform.