The Vercel Breach Is a Mobile Supply-Chain Problem, Too

Today Vercel confirmed a security incident but the real risk may not be where most teams are looking.

Attackers reportedly pivoted through a compromised OAuth grant at Context AI, took over a Vercel employee’s Google account, and accessed customer API keys, source code and database contents. Vercel has advised customers to rotate anything marked “non-sensitive.” ShinyHunters is being namechecked, though the group denies involvement.

Most headlines will focus on Next.js apps and backend infrastructure. That’s the obvious blast radius. 

But there’s a less visible and harder to remediate risk: mobile apps.

TL;DR

• This is a mobile supply-chain risk, not just a web incident
• At least 55 high-profile mobile apps contain Vercel-hosted endpoints embedded in production binaries
• Many rely on third-party SDKs, not direct integrations
• Mobile apps cannot quickly patch compromised infrastructure

What our MARI data shows

We queried NowSecure Mobile App Risk Intelligence (MARI)  dataset for *.vercel.app hostnames that appear inside production mobile app binaries — hardcoded URLs, network calls, pinned certificates and captured traffic. (If you’re not familiar, MARI is NowSecure’s solution for third-party mobile app vetting.) The short version:

• 73 unique vercel.app hostnames embedded in mobile apps
• 55 distinct mobile apps across 61 package IDs, iOS and Android
• Spanning fintech, retail, sports betting, social, media, gaming and utilities

That’s not a theoretical exposure. Those are production apps on real phones, talking to Vercel-hosted endpoints right now.

When Context AI gets phished, Vercel gets breached and the fallout lands in Cash App’s binary — that’s not three stories. That’s one mobile-supply chain story.

The apps that stand out

A few patterns worth calling out.

Fintech concentration via Knot API

The single most prevalent hostname in our dataset is knotapi.vercel.app and its siblings (sandbox-knotapi, development-knotapi, inter-prod-switcher-knotapi, inter-dev-switcher-knotapi). 

Knot is a third-party subscription-switching SDK, and their control plane is hosted on Vercel. We see it embedded in:

• Venmo (com.venmo)
•  PayPal (com.paypal.android.p2pmobile)
• Cash App (com.squareup.cash)
• Chime (com.1debit.ChimeProdApp, com.onedebit.chime)
• Klarna (com.klarna.app)
• Cleo (com.meetcleo.cleo)
• Bilt Rewards (com.biltrewards.bilt)
• OnePay (com.onefinance.one)
• Current (com.current.app, com.current.currentapp)
• Lyft Direct (com.payfare.lyft)

These are tier-1 financial apps. None of them got “breached” today. But a shared upstream dependency running on the affected platform means their incident response teams have a question to answer this week: what tokens, endpoints, or configuration did that dependency hand to our app, and do any of them need to be rotated?

The Tapcart e-commerce fan-out

shopify-customer-accounts.vercel.app and tapcart-consumer-sandbox.vercel.app show up in Dressbarn, edikted, Alphalete, World of Books, Livingood Daily and Vapor95. Same pattern: one shared SaaS surface, many downstream consumer apps.

Gambling and daily-fantasy operators

Pulsz, PulszBingo, McLuck, Megabonanza, Betr, Novig, PlayFame — config endpoints and landing pages on *.vercel.app. Money-handling surface.

Brand and sports apps

Chicago Bulls, BNP Paribas Open, Gametime, Hipcamp, Polaroid, Groupon, Feeld, iNaturalist, Base (Coinbase’s org.toshi.distribution), LBCI Lebanon, DoorDash’s Dasher, PicCollage and more.

And then there’s hygiene

A non-trivial chunk of what we found isn’t a production endpoint at all — it’s a Vercel *preview* URL shipped inside  production binaries:

• nativewind-demo-compiler.vercel.app inside CloudSpotter, Chicago Bulls, Groupon, iNaturalist, GeoTrack360
• v0-loading-spinner-app.vercel.app, v0-next-js-shadcn-ui-app-uv.vercel.app — literally v0 scaffolds
•  feeld-website-kqxhr5u0s-feeld-c3c3b796.vercel.app — PR-preview-style hostname
• hearty-web-next-git-new-quiz-web-paywallfree-tria-1c2e29-hearty.vercel.app — same pattern
•  *-dev-*, *-staging-*, *-development-* variants across dozens of apps

A preview URL inside a production binary means the developer either forgot to swap the endpoint, shipped debug code, or — most commonly — copied an example that pointed at someone else’s scaffold and never noticed. That’s a supply chain problem even when there *isn’t* a breach upstream. Today there is one.

Why mobile makes this worse

Mobile risk increases for three reasons: 

1. You can’t rotate a binary.

If a compromised endpoint or key is baked into an installed app, fixing it means shipping an update and waiting on app store approval cycles. 

That’s days or weeks and many users never update.

2. Third-party SDKs hide the dependency.

Most apps didn’t explicitly integrate Vercel. They integrated SDKs that did.

The dependency is often:

• Invisible in SBOMs
• Missing from privacy disclosures
• Difficult for security teams to inventory

(We’ve written more about how third-party SDKs introduce hidden risks in mobile apps —  this is a textbook example.)

3. The attack paths aren’t symmetric with web.

On the web, a compromised endpoint can be rotated quickly. 

On mobile, that same endpoint may control:

• Authentication
• Feature flags
• Payment routing
• Certificate pinning

Compromise the bootstrap, and you compromise everything that follows. And the fix lives in a signed binary you can’t hot-patch.

Mobile Application Risk Intelligence (MARI)

Read More

What to do this week

If you ship a mobile app, there are three immediate steps worth taking.

1. Scan your own binaries for .vercel.app.

Look for: 

• Hardcoded URLs
• Network traffic
• Certificate references
• SDK-driven endpoints 

Include your third-party SDKs in automated mobile application security testing — that’s where the surprises live. MARI customers, ping your CSM if you want to know where to look.

2. Treat it as a third-party incident, not just a vendor notice.

If any of your vendors, SDK or partner uses Vercel, ask: 

• Were you impacted?
• What did you rotate?
• What keys of ours did you hold? 

“We’re not affected” isn’t a sufficient answer. Ask for the rotation log.

3. Audit for preview URLs shipped as production.

A v0-*, *-git-*, *-dev-*, or *-staging-*.vercel.app inside your release binary is a release process bug independent of this breach and it’s fixable.

What does the Vercel breach mean for mobile apps?

Mobile apps may contain hardcoded or SDK-driven dependencies on Vercel-hosted endpoints. If those endpoints are compromised, exposure persists until a new version of the app is distributed and adopted.

Why is mobile supply chain risk harder to mitigate?

Unlike web applications, mobile apps require app store updates to fix embedded dependencies. That introduces delays and extends the window of exposure.

How should mobile teams respond to third-party breaches?

• Scan binaries for exposed infrastructure
• Audit SDK dependencies
• Validate vendor key rotation
• Remove non-production endpoints from release builds

The bigger point

A mobile supply-chain risk occurs when third-party infrastructure or SDK dependencies introduce vulnerabilities into production mobile apps. That’s what this is.

Every mobile app is the endpoint of a supply chain that runs through someone else’s cloud, someone else’s CI and someone else’s OAuth. When Context AI gets phished, Vercel gets breached and the fallout lands in Cash App’s binary — that’s not three stories. That’s one mobile supply-chain story.

Want the full list of affected apps and hostnames? Contact us to get the complete MARI dataset and exposure analysis from NowSecure.