What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live.

Also worth checking your Google Workspace OAuth authorizations. Admin Console > Security > API Controls > Third-party app access. Guarantee there are apps in there you authorized for a demo two years ago that are still sitting with full email/drive access.

▲

trollbridge 27 minutes ago | parent | next [-]

We have multiple Google accounts for this very reason. Of course, a lot of orgs don’t do this due to the Google Workspace per user “tax”. I tried and failed at a past employer to get some account other than my primary for doing OAuth grants like this.

▲

quentindanjou 9 hours ago | parent | prev | next [-]

Usually rotating a credential means that you invalidate the previous one. Never heard of rotating credentials that would only create new ones and keep the old ones active.

▲

simlevesque 8 hours ago | parent [-]

But then every rotation would break production, wouldn't it ?

	▲	cortesoft 7 hours ago \| parent \| next [-]
		rotations are usually two phased. Add new secret/credential to endpoint, and both new and old are active and valid. Release new secret/credential to clients of that endpoint, and wait until you dont see any requests using the old credential. Then you remove the old credential from the endpoint.
	▲	kstrauser 8 hours ago \| parent \| prev [-]
		Ideally, you can have a couple of working versions at any given time. For instance, an AWS IAM role can have 0 to 2 access keys configured at once. To rotate them, you deactivate all but one key, create a new key, and make that new key the new production value. Once everything's using that key, you can deactivate the old one.

▲

oasisbob 6 hours ago | parent | prev | next [-]

> What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live.

That statement in the report really confuses me; feels illogical and LLM generated.

An old deployment using an older env var doesn't do anything to control whether or not the credential is still valid. This is a footgun which affects availability, not confidentiality like implied.

Another section in the report is confusing, "Environment variable enumeration (Stage 4)". The described mechanics of env var access are bizarre to me -

> Pay particular attention to any environment variable access originating from user accounts rather than service accounts, or from accounts that do not normally interact with the projects being accessed.

Are people really reading credentials out of vercel env vars for use in other systems?

▲

nulltrace 3 hours ago | parent | prev | next [-]

Preview deploys are even worse. Every PR spins one up with the same env vars and nobody ever cleans them up. You rotate the key, redeploy prod, and there are still like 200 zombie previews sitting there with the old value.

▲

wouldbecouldbe 9 hours ago | parent | prev | next [-]

When you rotate them, you supposed expire your old vars

▲

kevinqi 8 hours ago | parent | prev [-]

yeah not redeploying on credential changes seems like a design flaw. Render redeploys on env var changes, for instance.

	▲	treexs 7 hours ago \| parent [-]
		Vercel very clearly highlights that you need to redeploy once you make a credential change