The following is based on my interpretation of information that's been made public:

A Vercel user had their Google Workspace compromised.

The attacker used the compromised workspace to connect to Vercel, via Vercel's Google sign-on option.

The attacker, properly logged into the Vercel console as an employee of that company, looked at the company's projects' settings and peeked at the environment variables section, which lists a series of key:value pairs.

The user's company had not marked the relevant environment variables as "sensitive", which would have hidden their values from the logged-in attacker. Instead of

  DATABASE_PASSWORD: abcd_1234 [click here to update]

it would have shown:

  DATABASE_PASSWORD: ****** [click here to update]

with no way to reveal the previously stored value.

And that's how the attacker enumerated the env vars. They didn't have to compromise a running instance or anything. They used their improperly acquired but valid credentials to log in as a user and look at settings that user had access to.

I don't think that's what the attacker did here. Vercel is a PaaS product where other developers run apps. The enumerated environment variables were the env vars of Vercel's customers, which Vercel likely stores in a long-term data store. Rather than running `env` on a Linux box somewhere, the attacker may have just accessed that data store.

[dead]