HN

Comments (87)

• Menu

  westont5
  I'm not sure I've seen it mentioned yet that when Vercel rolled out their environment variable UI, there was no "sensitive" option https://github.com/vercel/vercel/discussions/4558#discussion.... There was ~2 years or more until it was introduced https://vercel.com/changelog/sensitive-environment-variables...
• tosser12344321
  There are going to be a lot more like this as the IT-enabled economy at large catch up to the risk debt of broad-based experimentation with AI tools from large and small vendors.It's "AI-enabled tradecraft" as in let's take a guess at Vercel leadership's pressure to install and test AI across the company, regardless of vendor risk? Speed speed speed.This is an extremely vanilla exploit that every company operating without a strictly enforceable AI install allowlist is exposed to - how many AI tools like Context are installed across your scope of local and SaaS AI? Odds are, quite a bit, or ask your IT guy/gal for estimates.These tools have access to... everything! And with a security vendor and RBAC mechanism space that'll exist in about... 18-24 months.Vercel is the canary. It's going to get interesting here, no way in heck that Context is the only target. This is a well established, well-concerned/well-ignored threat vector, when one breaks open the other start too.Implies a very challenging 6 months ahead if these exploits are kicking off, as everyone is auditing their AI installs now (or should be), and TAs will fire off with the access they have before it is cut.Source - am a head of sec in tech
• Menu

  thundergolfer
  > AI-accelerated tradecraft. The CEO publicly attributed the attacker's unusual velocity to AI augmentation — an early, high-profile data point in the 2026 discourse around AI-accelerated adversary tradecraft.Attributed without evidence from what I could tell. So it doesn't reveal much at all.
• Menu

  tom1337
  I still don't get how this exactly worked. Is the OAuth Token they talk about the one that you get when a user uses "Sign in with Google"? Aren't they then bound to the client id and client secret of that specific Google App the user signed in to? How were the attackers able to go from that to a control plane? Because even if the attacker knows the users OAuth token, the client id and the client secret, they can access the Google Drive etc. (which is bad, I get that) but I simply do not understand how they could log in into any Vercel systems from that point. Did they find the credentials in the google drive?
• Menu

  datadrivenangel
  "Effective defense requires architectural change: treating OAuth apps as third‑party vendors, eliminating long‑lived platform secrets, and designing for the assumption of provider‑side compromise."Designing for provider-side compromise is very hard because that's the whole point of trust...
• Menu

  _pdp_
  > OAuth trust relationship cascaded into a platform-wide exposure> The CEO publicly attributed the attacker's unusual velocity to AI> questions about detection-to-disclosure latency in platform breachesTypical! The main failures in my mind are:1. A user account with far too much privileges - possible many others like them2. No or limited 2FA or any form of ZeroTrust architecture3. Bad cyber security hygiene
• Menu

  saadn92
  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.
• Menu

  oasisbob
  Some of the details in this report, like the timeline beginning in 2024-2025, haven't been widely reported?Anyone know where these dates are being sourced from? eg,> Late 2024 – Early 2025: Attacker pivots from Context.ai OAuth access to a Vercel employee's Google Workspace account -- CONFIRMED — Rauch statement> Early - mid-2025: Internal Vercel systems accessed; customer environment variable enumeration begins -- CONFIRMED — Vercel bulletin
• Menu

  hungryhobbit
  Why is this same story repeated over and over here?I get it, it's a big story ... but that doesn't mean it needs N different articles describing the same thing (where N > 1).
• Menu

  pier25
  Funny how the headline tries to spin this as an env vars issue.By far the biggest issue is being able to access the production environment of millions of customers from a Google Workspace. Only a handful of Vercel employees should be able to do that with 2FA if not 3FA.
• ubershmekel
  I'm building something that isn't necessarily more secure than vercel, but it is self hosted. I think in the future personal vps family clouds are going to be a lot more common because of these cloud-level attacks and costs.
• greenmilk
  To me the biggest (but not only) issue is that blindly connecting sensitive tools to 3rd party services has been normalized. Every time I hear the word "claw" I cringe...
• Menu

  jwpapi
  What are these non-sensitive variables that could only be the NEXT_PUBLIC ones? else I haven’t seen any difference?Or is it the UI sensitive that they ask you in CLI, that would be crazy. That means if you decide to not mark them as sensitive they don’t store encrypted ???
• Menu

  pier25
  > The CEO publicly attributed the attacker's unusual velocity to AIUnusual velocity? Didn't the attacker have the oauth keys for months?
• krooj
  Interesting - I wonder if this isn't a case of theft on a refresh token that was minted by a non-confidential 3LO flow w/PKCE. That would explain how a leaked refresh token could then be used to obtain access, but does the Vercel A/S not implement any refresh token reuse detection? i.e.: you see the same R/T more than once, you nuke the entire session b/c it's assumed the R/T was compromised.
• anon
  undefined
• anon
  undefined
• anon
  undefined
• anon
  undefined
• Menu

  vaguemit
  I recently went to BreachForums and the space was filled with this
• Menu

  akanet
  This article is solely overly wordy (probably ai) restatements of essentially just what vercel has publicly disclosed already
• Menu

  throwaway27448
  Do any services use vercel?
• semiquaver
  I’m sure this has been said before but the new part of me is that the initial breach happened 22 months ago and has been sitting undetected that whole time. This really looks quite bad for vercel’s security posture.
• forrestthewoods
  I hate environment variables. I hate them so so so much. I can’t think of a single time I would prefer an envvar to a config file.They’re somewhat necessary when dealing with Docker. But I also hate Docker. So it’s not surprising when one bad design pattern leads to another.I suppose maybe envvars make sense when dealing with secrets? I’m not sure. I don’t do any webdev. So not sure what’s least bad solution there.
• Menu

  pphysch
  Security-by-obfuscation is ridiculed but I'm a firm believer that preventing yourself from getting owned when someone is able to type 3 letters `env` is a worthy layer of defense. Even if those same secrets are unencrypted somewhere else on the same system, at least make them spend a bunch of time crawling through files and such.
• guptadeepak
  [dead]
• jdw64
  [dead]
• foreman_
  [dead]