Not affiliated with AWS
← Back to BlogRSS

Every PaaS Breach Becomes an AWS Breach

supply-chaincredential-accessiambreach-analysis

Vercel disclosed in April 2026 that customer environment variables had been exfiltrated from its internal systems. The stolen access keys, source code, and database data were posted to BreachForums for sale; the threat actor separately claimed to have discussed a $2 million ransom with Vercel, which Vercel has not publicly acknowledged. From the initial Lumma Stealer infection at Context.ai in February 2026 to public disclosure, the chain ran for roughly two months.

The breach happened at Vercel. The credentials are yours.

This is what every Vercel customer who pasted AWS_ACCESS_KEY_ID into the dashboard now has to assume: their AWS keys may already be in someone else's database.

What actually happened at Vercel

Trace the chain backward from the BreachForums listing:

Lumma Stealer infection on a Context.ai employee laptop
  -> Browser-stored Google session token harvested
    -> Pivot into the employee's Google Workspace
      -> Take over a Vercel employee's Workspace account
        -> Vercel SSO session granted
          -> Internal Vercel systems
            -> Bulk decryption of customer env vars
              -> Exfiltration -> BreachForums sale

Vercel's bulletin confirms the entry point ("compromise of Context.ai, a third-party AI tool used by a Vercel employee") and the impact: a limited subset of customers had their non-sensitive (plaintext-decryptable) environment variables compromised. Hudson Rock researchers traced the initial vector to a February 2026 Lumma Stealer infection on a Context.ai employee's machine; Context.ai responded to the compromise in March, and Vercel publicly disclosed in April. Trend Micro frames it as an OAuth supply chain attack in which the third-party app's session tokens carried trust into Vercel's identity perimeter.

The remarkable detail isn't the exotic AI-vendor entry point. It's the boring middle of the chain: a SaaS employee's session, used to log into another SaaS, where that employee had standing access to bulk customer secrets. From there, the attacker did exactly what anyone would do: they exported what they could read.

The "non-sensitive" misnomer

Vercel's incident description rests on a critical word: "non-sensitive." In Vercel's UI, environment variables come in two flavors. The default class is decryptable to plaintext at build and runtime, which is what most teams use because it's the only way to reference variables in build logs, server-side functions, and edge runtimes. The "Sensitive" class, which Vercel recommended customers adopt post-incident and which the company has signaled will get "stronger defaults" going forward, restricts what can be read back from the API.

The default class is where AWS access keys, RDS connection strings, and Stripe secrets typically end up. There's no UX nudge in the dashboard pushing teams to mark them otherwise. Calling those variables "non-sensitive" describes the storage tier, not the contents.

This is the pattern Trend Micro flagged in the disclosure analysis: the platform's threat model treated the env-var store as an internal config surface, not as a multi-tenant secret vault. Customers used it as the latter. The attackers agreed with the customers.

This is a four-year pattern, not a Vercel problem

The Vercel breach is the third of its kind in four years. Each one followed the same shape: an endpoint compromise at a developer platform, a session takeover of an engineer with standing access, and a bulk export of customer secrets. The platform changes. The mechanic does not.

2022: Heroku and Travis CI OAuth heist

In April 2022, GitHub disclosed that an attacker had abused stolen OAuth tokens issued to Heroku and Travis CI to clone private repositories from "dozens of organizations, including npm." The attacker pivoted into npm's production infrastructure using a compromised AWS API key found in one of the cloned repos. The breach didn't start at npm. It started at a third-party integrator that npm customers had clicked "authorize" on years earlier.

Cycode's post-incident analysis noted that "over 2,200 companies use Heroku, and over 1,700 use Travis CI." Every one of them is an environment where AWS credentials, SSH keys, and database secrets had routinely been committed to env vars and OAuth-scoped CI configs.

Unit 42's broader study of third-party token risk names the structural problem directly: "Tokens must have a lifecycle. Without rotation and expiration, threat actors can turn one compromise into a prolonged, large-scale breach."

2023: CircleCI

On January 4, 2023, CircleCI told every customer to "rotate any and all secrets stored in CircleCI." The postmortem is the cleanest account we have of the mechanic: one engineer's laptop becomes a forced rotation across the entire customer base.

The chain:

Engineer laptop infected with infostealer (antivirus did not detect)
  -> Active SSO session token stolen from local browser session
    -> Reused to bypass MFA on internal CircleCI systems
      -> Standing privileges to generate production access tokens
        -> Encryption keys extracted from a running process
          -> Customer env vars / contexts / project keys decrypted
            -> Exfiltration on Dec 22, 2022; disclosed Jan 4, 2023

CircleCI's own postmortem is unflinching about the consequence: "Though all the data exfiltrated was encrypted at rest, the third party extracted encryption keys from a running process, enabling them to potentially access the encrypted data." Encryption-at-rest stops nothing once an attacker has the running process. Fewer than five customers ultimately reported confirmed downstream unauthorized access. Every other CircleCI customer still had to rotate every secret on the assumption their data was exposed. The forced rotation is the breach, regardless of what the attackers actually did with what they took.

2026: Vercel

Lumma Stealer on a third-party employee laptop. Harvested session tokens. Pivot into Vercel's identity perimeter via a shared employee identity. Standing access to bulk env-var decryption. Weeks of unmonitored read access. The vendor in the middle changed. The shape did not.

Why PaaS env vars are an unmonitored AWS attack surface

When you paste an AWS access key into Vercel, Heroku, CircleCI, Netlify, or any other PaaS, you've done four things you usually don't think about:

  1. Detached the credential from its account's audit trail. AWS CloudTrail records what the credential did. It does not record the PaaS read events that happened before the credential was used.
  2. Made the credential reachable from any PaaS employee who can read env vars, and put the vendor's endpoint security, supply chain, and IAM into your AWS threat model. That employee set is usually larger than the set with explicit "production access." CircleCI showed that standing privileges to mint tokens were enough.
  3. Accepted the vendor's encryption posture. Plaintext-at-rest is common. Application-layer encryption with keys held by the vendor is standard. KMS-with-customer-keys is rare.
  4. Surrendered rotation control. You can rotate the AWS key on your side. You cannot force the PaaS to expire the cached copy in every internal system that holds it.

Detection is the worst part. There is no log on the AWS side that fires when a Vercel employee's account decrypts your env var. The first signal is the bill spike, the GuardDuty finding, the BreachForums listing, or the disclosure email from the vendor, usually weeks or months after the fact.

IBM's 2024 Cost of a Data Breach research, as reported by Cybersecurity Dive, puts the average combined time to identify and contain a breach where stolen or compromised credentials were the initial vector at 292 days. The Vercel chain's two-month duration isn't an outlier. It's substantially better than the industry baseline.

The numbers are bigger than any single PaaS

The credential exposure baseline is already enormous before any platform breach is added on top:

  • GitGuardian's 2025 State of Secrets Sprawl found 23.8 million new secrets in public GitHub commits in 2024 (a 25% year-over-year increase), and that 70% of secrets leaked in 2022 are still valid today.
  • Datadog's 2025 State of Cloud Security found that 59% of AWS IAM users have an access key older than one year. Long-lived credentials are the norm, not the exception, which means the credentials sitting in PaaS env vars right now are the same ones that have been there for months.

Now layer the PaaS multiplier on top. CircleCI's 2023 incident triggered a forced platform-wide secret rotation across its entire customer base. Heroku's 2022 OAuth abuse traversed dozens of customer organizations through a single integration. Vercel's 2026 incident put unknown numbers of customer AWS keys into a marketplace listing. Each PaaS breach takes the existing per-customer exposure and broadcasts it across the customer base in one event.

This isn't a theoretical risk. It's a recurring one. 2022, 2023, 2026: three of the largest dev platforms breached in four years, every breach a multi-customer credential export.

Reducing the blast radius

You can't prevent the next PaaS breach. You can limit what's in the export when it happens.

Stop putting long-lived AWS keys in PaaS env vars. Vercel, GitHub Actions, CircleCI, and Netlify all support OIDC federation to AWS. The PaaS exchanges a short-lived OIDC token for short-lived STS credentials scoped to a specific repo, branch, or workflow. The credential never rests in the env-var store. The blast radius from a future PaaS breach drops to whatever was in flight during the incident window, typically nothing, because the STS credentials issued via OIDC live for minutes to an hour.

If long-lived keys are unavoidable, scope them ruthlessly. The IAM policy attached to a PaaS-stored access key should pass a brutal read: one bucket, one prefix, one role, one action. No iam:*. No sts:AssumeRole *. No s3:* on *. The credential's blast radius is the policy's reach. That's what gets sold on BreachForums.

Use the platform's "Sensitive" env-var class when it exists. Vercel's Sensitive class restricts API readback and is what the company's own post-incident guidance points customers toward. It's not a complete defense (internal compromise can still reach it), but it raises the cost and reduces the surface of the next bulk export.

Rotate proactively, on a calendar, not on disclosure. Every long-lived credential in a PaaS should have a rotation schedule shorter than the industry breach-detection window. 90 days is a defensible floor. 30 is better. If your rotation cadence is "when the vendor emails us," your credentials' lifetimes are being set by other people's incident response timelines.

Map the blast radius from each PaaS-provisioned IAM identity. This is the question the next breach disclosure will force you to answer in 24 hours: what does the credential we stored in $VENDOR actually unlock? Answer it now. Trace every AssumeRole, every GetSecretValue, every cross-account trust path. That's what the attacker gets when the vendor's next email lands. This is exactly what our agent does, autonomously, starting from the IAM identity an attacker actually lands on.

Key takeaways

  • Vercel's April 2026 breach is the third major PaaS-credential incident in four years. Heroku/Travis in 2022, CircleCI in 2023, and Vercel in 2026 all share the same shape: PaaS-employee endpoint compromise, session takeover, bulk customer secret export.

  • "Non-sensitive" is a storage class, not a content classification. Vercel's plaintext-decryptable env vars contained the same AWS keys, DB strings, and API tokens any production system uses. The label described the vault, not what was inside it.

  • PaaS env vars are an AWS attack surface with no AWS-side telemetry. The PaaS read events that lead to credential exfiltration leave no trace in CloudTrail. By the time you have an AWS-side signal, the credential has already been used.

  • OIDC federation eliminates the structural risk. Short-lived STS credentials issued per build leave nothing in the env-var store to steal. This is the single highest-leverage change for any organization still using long-lived keys in PaaS.

  • Rotation cadence is your last line of defense, and it must be shorter than the industry breach detection window. A credential rotated every 30 days survives at most 30 days of any given disclosure.

  • The next PaaS breach is already inevitable. The pattern is annualized. Make sure the credentials it exposes can't reach anything that matters.

Ready to map the blast radius from every credential you've handed to a third party? Sign up for hackaws.cloud and find out what an attacker would unlock from your PaaS-stored AWS keys, before the next disclosure email arrives.