Vercel hakattiin (huhtikuu 2026): 60 minuutin hätätoimintasuunnitelma, joka jokaisen kehittäjän on suoritettava tänään

Vercel hakattiin (huhtikuu 2026): 60 minuutin hätätoimintasuunnitelma, joka jokaisen kehittäjän on suoritettava tänään

1. huhtikuuta 2026 Vercel vahvisti, että hyökkääjät murtivat kolmannen osapuolen tekoälytyökalun (Context.ai), kaappasivat Vercelin työntekijän Google Workspace -tilin ja lukivat ympäristömuuttujia, joita ei ollut merkitty ”aroiksi” rajallisessa osassa asiakasprojekteja. Jos olet julkaissut mitään Verceliin viimeisen 30 päivän aikana, sinun on oletettava, että yksi tai useampi env-muuttujasi saattaa jo olla jonkun muun hallussa, ja sinun on toimittava nopeasti.

Tässä on epämukava totuus: useimmat vibecooderit julkaisevat .env-arvot suoraan mallista koskematta koskaan "Sensitive"-valitsimeen. Juuri tämän tyyppisiä muuttujia hyökkääjä luki. Tämä toimintasuunnitelma opastaa sinua seuraavan 60 minuutin aikana siinä, mitä tarkistaa, mitä kierrättää ja miten kovettaa pinosi, jotta seuraava alustamurto ei kaada sovellustasi.

TL;DR: Mitä tehdä seuraavan 60 minuutin aikana

Jos et lue mitään muuta, tee nämä kuusi asiaa heti:

1. Pysäytä automaattiset julkaisut tuotantohaaroissasi.
2. Suorita vercel env pull ja etsi tulosteesta salaisuuksien kuvioita (sk_live_, AKIA, ghp_, eyJ).
3. Kierrätä kaikki API-avaimet, jotka on tallennettu ei-aroina env-muuttujina, aloittaen maksujen, tietokantojen, autentikoinnin ja pilvipalveluntarjoajien avaimista.
4. Lisää kierretetyt salaisuudet uudelleen käyttäen Vercelin "Sensitive" (Arka) ympäristömuuttujan valitsinta ja julkaise uudelleen.
5. Avaa Vercelin aktiviteettiloki ajalle 1.–20. huhtikuuta ja merkitse kaikki julkaisut, kirjautumiset tai token-tapahtumat, joita et tunnista.
6. Tarkista GitHub-organisaatiosi auditointiloki samalta ajanjaksolta uusien PATien, julkaisuavainten tai työnkulun muutosten varalta.

Alla on täydellinen erittely tarvittavine komennoineen, kuvioineen ja kierrätysjärjestyksineen.

Mitä todella tapahtui Vercelin huhtikuun 2026 tietomurrossa?

Vercel ilmoitti 19. huhtikuuta 2026, että hyökkääjä oli murtautunut Context.ai:hin, kolmannen osapuolen tekoälyn tuottavuustyökaluun, jota Vercelin työntekijä käytti. Sieltä hyökkääjä otti haltuunsa työntekijän Vercelin Google Workspace -tilin, siirtyi Vercelin sisäiseen ympäristöön ja pääsi käsiksi ympäristömuuttujiin, joita ei ollut merkitty "Sensitiveksi" (Araksi).

Muuttujat, jotka on merkitty "Sensitiveksi", käyttävät erillistä salatua lukupolkua, ja Vercelin mukaan ei ole näyttöä siitä, että ne olisivat paljastuneet. Kaikki muu – tavalliset env-muuttujat, jotka sisältävät API-avaimia, tietokanta-URL:eja ja JWT-salaisuuksia – oli luettavissa. Kyberrikosfoorumilla on sittemmin väitetty myytävän Vercelin dataa 2 miljoonalla dollarilla, vaikka Vercel ei ole vahvistanut tietojen vuotamista. Joka tapauksessa varmin toimi on olettaa kompromisoituminen kierrätystarkoituksia varten, vaikka Vercel ei olisi lähettänyt sinulle suoraa sähköpostia.

Yhtiö arvioi hyökkääjän olevan "erittäin sofistikoitunut operatiivisen nopeutensa ja Vercelin järjestelmien yksityiskohtaisen tuntemuksensa perusteella". Suomennos: kyseessä ei ollut skriptipoika, vaan ota aikaraja vakavasti.

Oletko受影响? Miten tarkistaa 5 minuutissa

Lyhyt vastaus: jos käytät Verceliä etkä ole ollut uskonnollinen "Sensitive"-valitsimen suhteen, pidä itseäsi affectedina. Tässä on 5 minuutin triage:

• Avaa Vercelin aktiviteettiloki ja suodata ajalta 1. huhtikuuta 2026 tähän hetkeen. Etsi tuntemattomia kirjautumisia, tokenien luomisia tai julkaisuja.
• Siirry Google Workspace Admin → Security → API Controls ja etsi julkaistu kompromisoitumisen indikaattori: OAuth-asiakastunnus 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Jos se on valtuutettu, peru se välittömästi.
• Tarkista, onko kukaan tiimissäsi koskaan kirjautunut Context.ai:hin Google SSO:n kautta. Jos kyllä, pidä heidän tilejään suuremman riskin kohteena.
• Katso Vercel-projektisi Environment Variables -välilehti. Laske, kuinka monta niistä EI ole merkitty "Sensitiveksi". Jokainen niistä on skopissa.

Jos sait Verceliltä sähköpostin, joka alkaa sanoilla "We identified a security incident affecting your account" (Olemme havainneet tiliisi vaikuttavan turvallisuuspoikkeaman), kuulut vahvistetusti haittaa kärsineisiin. Siirry suoraan kierrätysosioon ja aloita NYT.

60 minuutin hätätilavastaussuunnitelma

Tämä on järjestetty vaikutusalueen laajuuden mukaan. Älä ohita vaiheita, kukin niistä avaa seuraavan.

Vaihe 1: Jäädytä ympäristö (Ensimmäiset 10 minuuttia)

Pysäytä vuoto ennen forensiikan aloittamista:

• Pysäytä automaattiset julkaisut main / production -haaroissa (Vercel Dashboard → Project → Settings → Git).
• Poista tilapäisesti Vercel GitHub App käytöstä osoitteessa github.com/organizations/<your-org>/settings/installations, jos epäilet syvempää kompromisoitumista.
• Vie Vercelin auditointiloki CSV-tiedostoon ja tallenna se paikallisesti. Tarvitset sitä, jos tästä tulee myöhemmin GDPR-ilmoitusvelvollisuuden piiriin kuuluva tapaus.
• Ota käyttöön Observability Plus (edes kokeiluviikko), jotta säilytät laajennetut lokit.

Tämä on "todisteiden säilyttämisvaihe". Kierrätys ennen lokin tilannekuvan ottamista tuhoaa aikajanasi.

Vaihe 2: Hae env-muuttujat ja skannaa ne salaisuuksien varalta

Avaa terminaali ja suorita:

vercel link
vercel env pull .env.vercel-audit

Skannaa sitten tuloste. Nopein tapa on käyttää GitGuardianin CLI:tä:

ggshield secret scan path .env.vercel-audit

Jos et halua asentaa mitään, etsi grepillä näitä kuvioita; ne löytävät 80 % vuotaneista salaisuuksista env-tiedostoista:

grep -E "AKIA[0-9A-Z]{16}|sk_live_[0-9a-zA-Z]{24}|ghp_[0-9a-zA-Z]{36}|ghs_[0-9a-zA-Z]{36}|npm_[0-9a-zA-Z]{36}|eyJ[a-zA-Z0-9_-]+|-----BEGIN" .env.vercel-audit

Jokainen osuma on kierrätysehdokas. Jokainen ei-osuva salaisuus, joka on silti tunnistetieto (DB-URL:t, Redis-salasanat, webhook-allekirjoitusavaimet), on MYÖS kierrätysehdokas; grep löytää vain ilmeisimmät asiat.

Vaihe 3: Kierrätä salaisuudet prioriteettijärjestyksessä (ei aakkosjärjestyksessä)

Tässä vaiheessa useimmat tiimit mokaa. He kierrättävät 40 salaisuutta satunnaisessa järjestyksessä, istuntoavain invalidoi kaikki aktiiviset kirjautumiset ja tukipyyntöjen määrä räjähtää. Tee se porrastetusti:

Taso 0 – Kierrätä seuraavan 30 minuutin aikana:

• Kaikki GitHub Personal Access Tokenit (hienojakoiset ja klassiset)
• Kaikki olemassa olevat Vercelin arat env-muuttujatokenit
• Julkaisusuojauksen tokenit

Taso 1 – Kierrätä tänään:

• Maksunkäsittelijän salaiset avaimet (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, JWT-allekirjoitusavaimet, istuntocookiet
• Tietokantayhteysmerkkijonot, joissa on kirjoitusoikeus (DATABASE_URL, Mongo, Redis)
• Pilvipalveluntarjoajien avaimet (AWS IAM, GCP-palvelutilit, Azure-asiakassalaisuudet)
• Webhook-allekirjoitussalaisuudet (päivitä sekä lähettäjällä että vastaanottajalla)

Taso 2 – Kierrätä tämän viikon aikana:

• Kolmannen osapuolen SaaS-avaimet (sähköposti, SMS, analytiikka, CRM)
• OAuth-asiakassalaisuudet
• SMTP-tunnistetiedot, CDN-avaimet

Taso 3 – Kierrätä kun sopii:

• Vain luku -analytiikkatokenit, Sentry DSN:t, julkiset/anonyymit avaimet

Kriittinen toimintajärjestys:

• Tietokannoille: luo uusi käyttäjä ennen vanhan peruuttamista, tai kaadat sivuston kesken kierrätyksen.
• Istuntoavaimille: suunnittele uloskirjautumistapahtuma, kaikki aktiiviset istunnot kuolevat.
• Webhookeille: päivitä molemmat puolet samassa julkaisuikkunassa.
• Julkaise uudelleen jokaisen env-muuttujan muutoksen jälkeen. Vercel leipoo arvot build-vaiheessa, ei ajonaikana.

Vaihe 4: Lisää kaikki uudelleen "Sensitiveksi" (Araksi)

Kun laitat uudet arvot takaisin, käännä "Sensitive" -valitsin päälle jokaiselle niistä. Arat arvot käyttävät erillistä salatua polkua, ja Vercelin own bulletin mukaan ne eivät paljastuneet tässä tapauksessa. Tämä on yhden napsautuksen muutos, joka olisi pelastanut useimmat affectedit asiakkaat.

Vaihe 5: Auditoi repoasi ei-toivottujen muutosten varalta

Vertaa HEAD:ia päähaarassasi tunnetusti hyvään commitiin ennen 1. huhtikuuta. Keskity seuraaviin:

• package.json-skriptit, erityisesti postinstall, prepare, preinstall
• Lukitus tiedostot (package-lock.json, pnpm-lock.yaml) odottamattomien uusien riippuvuuksien varalta
• .github/workflows/*.yml uusien työnkulkujen tai kiinnittämättömien actionien varalta
• vercel.json build-komentomuutosten tai epäilyttävien uudelleenohjausten varalta
• next.config.js uusien headerien tai tuntemattomiin domainiin osoittavien uudelleenohjausten varalta

Jos julkaiset npm-paketteja, suorita myös npm view <pkg> time --json ja varmista, ettei mitään sellaista ole julkaistu, mitä et ole itse kirjoittanut.

Vaihe 6: Metsästys downstream-järjestelmistä

Hyökkääjät eivät pysähdy env-muuttujiin, he käyttävät niitä. Kysely downstream-järjestelmistäsi ajanjaksolta 1. huhtikuuta – tähän hetkeen:

• AWS CloudTrail: odottamattomat CreateUser, AttachUserPolicy, S3 GetObject-purkaukset, kirjautumiset uusista IP-osoitteista.
• Tietokannan auditointilokit: suuret SELECT * -kyselyt, viennit, yhteydet epätavallisilta alueilta.
• Stripe / Adyen: uudet API-avaimet, epäilyttävät hyvitykset, asiakkaiden luominen outoista sijainneista.
• Autentikointipalveluntarjoaja: mahdottomat matkakirjautumiset, luvattomat salasanan resetoinnit, uudet OAuth-sovellukset.

Mikä tahansa osuma tässä muuttaa tämän kierrätysharjoituksesta todelliseksi poikkeamaksi; eskaloi ja harkitse ilmoitusvelvoitteita (GDPR: 72 tuntia).

Mitä "Vibecooderit" missaavat: Piilotettu hyökkäyspinta

Jos olet oppinut koodaamaan tekoälyavusteisesti käyttämällä työkaluja kuten Claude Code, Cursor tai Copilot, olet todennäköisesti julkaissut ensimmäisen Vercel-sovelluksesi ennen kuin olet edes lukenut turvallisuusdokumenttia. Se on ok. Mutta on neljä piiloansaa, jotka osuvat vibecoodereihin kovemmin kuin kokeneisiin kehittäjiin:

1. NEXT_PUBLIC_-sudinkuoppa. Mikä tahansa NEXT_PUBLIC_-etuliitteellä varustettu asia bundlataan client-side JavaScriptiin. Jos laituit API-avaimen sinne "vain testataksesi", se oli jo julkinen ennen murtoa. Etsi built-tulosteestasi: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Linear / Slack -vuoto. Jos tiimisi liittää salaisuuksia Linear-tehtäviin tai Slack-keskusteluihin "vain hetkeksi", nämä salaisuudet jäävät kolmannen osapuolen lokeihin. Tarkista Linear-auditointilokisi ja etsi samoja regex-kuvioita kuin yllä.
3. .env.local private repossa -oletus. Private repot eivät ole private, jos Vercel GitHub Appisi on kompromisoitu. Jokainen committattu .env.*-tiedosto on skopissa.
4. Esikatselujulkaisut tuotantosalaisuuksilla. Useimmat vibecooderit käyttävät tuotannon env-muuttujia esikatseluympäristöissä. Tämä tuplaa hyökkäyspintasi. Erota ne.

Tämä on tylsää infrastruktuurityötä, jonka tekoälykoodaustyökalut ohittavat. Ratkaisu ei ole lopettaa tekoälyn käyttöä, vaan yhdistää tekoälyn nopeus turvallisuusperustaan. Jos selvität vielä, missä sovelluksesi edes sijaitsee, Vercel vs Netlify -vertailumme ja Railway vs Render vs Fly.io -erittelymme ovat hyvä lähtökohta.

Miten kovettaa pinoasi, jotta seuraava murto ei polta sinua

Alustamurrot ovat kysymys milloin, ei jos. Tässä on perustaso, joka jokaisella tuotantosovelluksella tulisi olla käytössä maanantaihin mennessä:

• Aseta oletuksena jokainen uusi env-muuttuja "Sensitiveksi" Vercelissä. Tee siitä tiimisi lihasmuisti.
• Käytä lyhytikäisiä tunnistetietoja. Vaihda pitkäikäiset AWS/GCP-avaimet GitHub OIDC -federaatioon; pilvipalveluntarjoajasi luottaa CI-identiteettiin suoraan, eikä pitkään elävää salaisuutta tarvitse vuotaa.
• Asenna pre-commit-salaisuusskannaus (gitleaks, Trufflehog). Estää salaisuuksien päätymisen repoyn alun perin.
• Rajoita GitHub Appisi tiettyihin repoihin, ei koko organisaation tasolla.
• Neljännesvuosittainen OAuth-sovellusten tarkistus Google Workspacessa, Microsoft 365:ssa, GitHubissa ja Vercelissä. Poista kaikki, mitä et tunnista.
• Suorita salaisuuksien skannaus Claude Code hookina, deterministinen pre-commit-valvonta silloinkin, kun tekoäly unohtaa.
• Kiinnitä Next.js-versiosi ja seuraa advisoryja. Vercel on ensisijainen Next.js-steward, joten täällä tapahtuvat poikkeamat ketjuuntuvat.
• Segmentoi backend-salaisuutesi. Jos käytät Supabasea tai Firebasea, käytä rivitasoista turvallisuutta ja service-role-avaimia säästeliäästi; vuotanut service-avain tarkoittaa koko tietokannan kompromisoitumista.

Tarvitsetko apua tilanteen lukitsemisessa? Näin Techsy sopii kuvaan

Tässä rehellinen pitch: useimmilla pienillä tiimeillä ei ole turvallisuusinsinööriä, ja 60-vaiheisen poikkeamahallintasuunnitelman lukeminen klo 2 aamulla ei ole kenenkään unelmamaananantai.

Techsyllä olemme suorittaneet poikkeamahallintaa ja alustan kovettamista yli 40 tuotannon Next.js- ja Node.js-sovellukselle viimeisen kahden vuoden aikana. Nimenomaan Vercel-tapauksen osalta tarjoamme:

• 72 tunnin hätätilavaste, Suoritamme Tason 0 / Tason 1 kierrätyksen, skannaamme env-muuttujasi yli 200 salaisuussignaalia vastaan ja auditoimme Vercel + GitHub + pilvilokisi end-to-end. Tyypillinen läpimenoaika: yksi työpäivä.
• Alustan kovettamisauditointi, Arkojen muuttujien migraatio, OIDC-tunnistetietojen kierrätys, pre-commit-salaisuusskannaus, GitHub App -skopaus ja kirjallinen runbook, jotta tulevaisuuden minäsi tietää, mitä tehdä seuraavan murron aikana.
• Jatkuva DevSecOps, Neljännesvuosittaiset OAuth-tarkistukset, jatkuva salaisuuksien skannaus ja poikkeamaharjoitukset, jotta "se ei tapahdu meille" -väitteestä tulee jotain, jonka voit todella perustella.

Olemme insinöörejä, emme checkbox-turvallisuusmyyjä. Jos panikoit juuri nyt, ota yhteyttä ilmaista 30 minuutin triage-puhelua varten, kerromme rehellisesti, tarvitsetko meitä vai selviytyykö yllä olevalla suunnitelmalla.

Usein kysytyt kysymykset

Onko Vercelin hakkaus vahvistettu todeksi vai vain huhu?

Vahvistettu. Vercel julkaisi virallisen turvallisuustiedotteen 19. huhtikuuta 2026, jossa se myönsi luvattoman pääsyn kompromisoituneen kolmannen osapuolen tekoälytyökalun (Context.ai) ja kaapatun työntekijän Google Workspace -tilin kautta. Ympäristömuuttujia, joita ei ollut merkitty "aroiksi", käytettiin. Erillinen BreachForums-viesti väittää myyvänsä dataa 2 miljoonalla dollarilla; tämä osa on vahvistamaton.

En saanut sähköpostia Verceliltä. Olenko turvassa?

Todennäköisesti, mutta "todennäköisesti" ei ole turvallisuusasenne. Vercel ilmoitti ottaneensa yhteyttä rajalliseen osajoukkoon asiakkaita, joilla oli vahvistettu vaikutus. Jos sähköpostiasi ei tullut, riskisi on pienempi, mutta kaikki ei-arot env-muuttujat Vercelin alustalla olivat vaikutusalueella. Suorita yllä oleva 10 minuutin triage joka tapauksessa.

Mikä on ero "sensitive" (arkan) ja tavallisten env-muuttujien välillä Vercelissä?

"Sensitive" ympäristömuuttujat käyttävät erillistä salatua lukupolkua, eikä niitä voi nähdä dashboardissa luomisen jälkeen. Tavalliset env-muuttujat ovat kaikkien projektin oikeudet omaavien luettavissa (mukaan lukien tässä tapauksessa hyökkääjä). Korjaus on ilmainen ja vie yhden napsautuksen muuttujaa kohden.

Pitääkö minun kierrättää KAIKKI salaisuuteni vai vain Vercelissä olevat?

Kierrätä jokainen salaisuus, joka on tallennettu ei-aroona Vercelin env-muuttujana. Jos käytit samaa avainta muualla (yleinen anti-pattern), kierrätä se kaikkialla. Älä unohda .env.local-tiedostoja esikatselujulkaisuissa, CI-järjestelmiä kuten GitHub Actionsia ja muita liitettyjä viitteitä Linearissa tai Slackissa.

Miten skannaan env-muuttujani todellisten salaisuuksien varalta nopeasti?

Suorita vercel env pull .env.audit ja sitten ggshield secret scan path .env.audit. Jos et voi asentaa GitGuardiania, käytä suunnitelman vaiheen 2 grep-yhtälöä; se löytää AWS-avaimet, Stripe-avaimet, GitHub-tokenit, npm-tokenit, JWT:t ja PEM-lohkot.

Pitäisikö minun vaihtaa pois Vercelistä tämän jälkeen?

Ei pelkästään tämän tapauksen vuoksi. Vercelin vaste, julkiset IoC:t, aikajana ja kierrätysohjeistus ovat olleet kohtuullisen avoimia. Jokaisella alustalla tulee joskus olemaan murto. Olennaista on, oletko suunnitellut sen varalle: arkojen muuttujien oletusarvot, lyhytikäiset tunnistetiedot, segmentoidut ympäristöt. Jos harkitset vaihtoehtoja joka tapauksessa, Vercel vs Netlify ja Railway vs Render vs Fly.io -artikkelimme purkavat tradeoffit.

Kuinka paljon minulla on aikaa ilmoittaa asiakkaille, jos olen affected?

GDPR antaa sinulle 72 tuntia tietoisuudesta ilmoitusvelvollisesta murrosta. Kalifornian CCPA:ssa on dataluokkakohtaisia laukaisijoita. SOC 2 / ISO 27001 -sopimukset vaativat usein aikaisempaa ilmoitusta kuin viranomaiset. Jos sinulla on maksavia asiakkaita ja vahvistat heidän datansa vuotamisen, oletu olevasi 72 tunnin kellon alla ja konsultoi lakimiestä ennen kuin lähetät mitään.

Voiko Next.js-sovelluksia hyökätä tämän kautta, vaikka en olisi Vercelissä?

Tapaus on Vercel-alustakohtainen. Next.js itsessään, hostattuna muualla, ei kärsi murron mekanismista. Mutta jos käytit samoja NEXT_PUBLIC_ env-muuttujakuvioita, jotka vahingossa paljastavat salaisuuksia, nämä ongelmat kulkevat koodisi mukana hostista riippumatta. Auditoi built-tulosteesi joka tapauksessa.

Mikä on yhden napsautuksen korjaus, joka olisi estänyt suurimman osan vahingoista?

Jokaisen tunnistetietoja sisältävän env-muuttujan merkitseminen "Sensitiveksi" (Araksi) Vercelissä alusta alkaen. Se on checkbox dashboardissa. Tässä tapauksessa arkoja muuttujia EI käytetty, vain tavallisia. Se on korjaus, ja se maksaa nolla dollaria ja noin viisi minuuttia projektia kohden.

Miten varmistan, ettei tiimini koskaan julkaise merkitsemätöntä salaisuutta uudelleen?

Kolme kerrosta: (1) pre-commit-salaisuusskannaus gitleaksilla, (2) CI-tarkistus, joka epäonnistuu, jos env-muuttuja lisätään ilman sensitive: true -lippua Vercel API:n kautta, ja (3) Claude Code hook, joka suorittaa skannerin jokaisessa editoinnissa. Syvyyspuolustus; mikä tahansa kolmesta löytää 80 %, kaikki kolme yhdessä ~99 %.

Yhteenveto

Vercelin huhtikuun 2026 murto on pahaa, mutta selviytyvissä, jos liikut seuraavan 60 minuutin aikana. Jäädytä julkaisut, hae env-muuttujasi, suorita grep, kierrätä porrastetusti, lisää uudelleen aroina ja metsästää downstream. Siinä koko suunnitelma.

Alustamurrot paljastavat, kuinka paljon luotamme oletusarvoihin. Useimmat tiimit, jotka kärsivät tässä, eivät tehneet mitään väärin; he jättivät vain "Sensitive"-valitsimen ruksimatta, koska kukaan ei kertonut sen merkitystä. Se on vibecoodereiden todellinen oppitunti: tekoälyn generoima koodi julkaistaan nopeasti, mutta turvallisuusoletusarvot eivät tule generaation mukana.

Jos haluat toiset silmät pinoosi, tai et halua suorittaa tätä suunnitelmaa yksin klo 2 aamulla, varaa ilmainen triage-puhelu Techsy-tiimin kanssa. Muuten, onnea, liiku nopeasti ja merkitse ne muuttujat ariksi.