18 abuse cases unreviewed — Vercel-hosted Pix payment endpoints still charging victims - Help

— apologies for the direct tag; I saw you handled the Banco de Bogotá and Cloud86 reports. I am not opening new abuse cases, I know that does not raise severity. I am asking for escalation of cases already filed.

18 deployments impersonating the Brazilian creator platform Privacy are live and taking payments from Brazilian consumers. All were reported through vercel.com/abuse, one submission per URL, under "Phishing or Malware":

01387922 cr7-vert.vercel.app 01387927 privacyhot.vercel.app 01387937 privacy-isabel.vercel.app 01387943 privacy-gilt-five.vercel.app 01387947 privacypremium.vercel.app 01387953 privacyaninha.vercel.app 01387954 acesso-privacy.vercel.app 01387959 privacy-oficial-6xo1.vercel.app 01387961 privacybruninha.vercel.app 01387962 privacy-brasil.vercel.app 01387966 privacyofc.vercel.app 01387970 oficial-privacy.vercel.app 01387973 privacyleticiacosta.vercel.app 01387975 privacci.vercel.app 01387978 teste-priv-u76e.vercel.app (the 15 above filed 2026-07-27) 01396291 privacykamylinhasantos.vercel.app 01396292 privacy-kamylinha.vercel.app 01396293 liviaandrade.vercel.app (filed 2026-08-01)

All 18 return HTTP 200 today.

What makes these different from a lookalike landing page: the payment is issued by Serverless Functions on Vercel. It reproduces from any terminal in under a minute, without touching the page.

curl -s -X POST https://cr7-vert.vercel.app/api/pix -H "Content-Type: application/json" -d '{"amount":19.9}' -> 200, valid Brazilian Pix code, beneficiary NEXUS MARKETPLACE LTDA x-matched-path: /api/pix x-vercel-id: gru1

curl -s -X POST https://privacyhot.vercel.app/api/pix/create -H "Content-Type: application/json" -d '{"value":5000}' -> 200, valid Pix code, beneficiary PUSHINPAY response still carries webhook_url "https://seu-site.com", an unedited placeholder from the kit template

curl -s -X POST https://liviaandrade.vercel.app/api/pix -H "Content-Type: application/json" -d '{"amount":19.9}' -> 500 {"error":"Falha ao autenticar com SyncPay"} x-matched-path: /api/pix — the function is live and holds the operator's payment-provider credentials in that project's environment variables

Each successful call mints a new transaction id, so your team can verify at any time. privacy-isabel.vercel.app/api/pix/generate returns 403 "Origem invalida" — alive, but refusing requests that do not originate from its own page.

I suspect the earlier reports were closed as unsubstantiated: an analyst opens the URL, sees a profile page with no card field, and reasonably concludes there is nothing there. The charge is one POST away.

Four deployments from this same campaign have already been disabled by Vercel — privacyoficial, privacybr, privacy-duda and privacy-oficial all return 451 with x-vercel-error: DEPLOYMENT_DISABLED. The call has already been made in-house on this exact template. I am asking for the same treatment on the 18 above.

I would also ask for account-level review rather than URL by URL. These share page templates, favicons and endpoint shapes. Some were built with v0.dev and serve their images from Vercel Blob Storage, which means authenticated accounts with a billing trail, not anonymous uploads. Suspending one URL at a time is why the count keeps growing.

To be clear about my standing: I claim no trademark or copyright here, and this is not a DMCA request. I am a Brazilian brand-protection company reporting consumer fraud.

Request/response transcripts:

https://www.zeroleaker.com/evidence/vercel-2026-07/

Thanks either way.

Thank you for bringing this to our attention. To ensure this is investigated with the necessary priority and privacy, please report all security-related concerns, potential exploits, or abuse directly to the Vercel Security Team.

Please submit your report here: vercel.com/abuse

Reporting via this official channel is the fastest way to reach our security engineers and ensures that sensitive information is handled in a secure environment rather than a public forum.

Thank you — I have already used that channel. 18 reports were filed through vercel.com/abuse , one per URL, and they returned case numbers 01387922-01387978 and 01396291-01396293. That is exactly why I am here: the cases are open and unreviewed, and all 18 URLs are still serving live Pix payment endpoints.

I am not asking to file a new report. I am asking for an existing case block to be looked at. , would you be able to pass these case numbers on, as you did with the Banco de Bogotá and Cloud86 reports?

Four days on, an update rather than a new report: all 18 deployments listed above still return HTTP 200.

Two developments that I think bear on the account-level request:

The campaign has moved off vercel.app. privacyfg.shop is the same Privacy impersonation template, registered through GoDaddy and pointed at Vercel by delegating its nameservers to ns1/ns2.vercel-dns.com. Suspending deployments one URL at a time is why the list keeps growing.
Two of these carry your own build fingerprint. privacyfg.shop embeds the "Built with v0" badge for chat b_1TaNmVbu63N, and privacyaninha.vercel.app (case 01387953) embeds b_l8WrJFS5OQf. Those resolve internally to authenticated accounts, which should let your Safety team check whether these share an operator without depending on anything I can see from outside.

To be accurate about privacyfg.shop: it has no self-hosted payment route, and its checkout host (pay.checkoutpixes.com) no longer resolves. I am citing it as evidence of the pattern, not as a live payment endpoint. The Pix functions documented above are the ones still answering.

, I am not asking for anything new to be filed — only for the existing case block to reach the Safety team.