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]

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

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.

Astonishing that high damage actions were authorized by authentication delegated to Google and furthermore not subject to hard token 2FA.