Vercel Hacklendi (Nisan 2026): Her Geliştiricinin Bugün Uygulaması Gereken 60 Dakikalık Acil Eylem Planı

19 Nisan 2026'da Vercel, saldırganların üçüncü taraf bir yapay zeka aracını (Context.ai) ele geçirdiğini, bir Vercel çalışanının Google Workspace hesabını devraldığını ve sınırlı sayıda müşteri projesinde "hassas" olarak işaretlenmemiş ortam değişkenlerini okuduğunu doğruladı. Son 30 gün içinde Vercel'e herhangi bir şey dağıttıysanız, ortam değişkenlerinizden birinin halihazırda yanlış ellerde olabileceğini varsaymanız ve hızlı hareket etmeniz gerekiyor.

Rahatsız edici gerçek: Çoğu vibe-coder, "Hassas" geçişine hiç dokunmadan .env değerlerini doğrudan bir şablondan alır. Saldırganın okuduğu değişkenler tam da bu kategorideydi. Bu plan, önümüzdeki 60 dakikada ne kontrol edeceğinizi, neyi döndüreceğinizi ve bir sonraki platform ihlali uygulamanızı çökertmesin diye stackinizi nasıl sertleştireceğinizi anlatıyor.

TL;DR: Önümüzdeki 60 Dakikada Yapmanız Gerekenler

Başka hiçbir şey okumayacaksanız, şimdi şu altı şeyi yapın:

1. Üretim dallarınızda otomatik dağıtımları duraklatın.
2. vercel env pull çalıştırın ve çıktıyı gizli kalıplara karşı tarayın (sk_live_, AKIA, ghp_, eyJ).
3. Hassas olmayan bir ortam değişkeni olarak depolanan her API anahtarını döndürün — ödeme, veritabanı, kimlik doğrulama ve bulut sağlayıcı anahtarlarıyla başlayın.
4. Döndürülen secretları Vercel'in "Hassas" geçişini kullanarak yeniden ekleyin, ardından yeniden dağıtın.
5. Tanımadığınız herhangi bir dağıtımı, girişi veya token etkinliğini işaretlemek için 1–20 Nisan'a ait Vercel etkinlik günlüğünüzü açın.
6. Aynı dönem için GitHub kuruluşunuzun denetim günlüğünü inceleyin — yeni PAT'ler, dağıtım anahtarları veya iş akışı değişiklikleri.

Aşağıda ihtiyaç duyacağınız komutlar, kalıplar ve rotasyon sırası dahil tam açıklama yer alıyor.

Vercel'in Nisan 2026 İhlalinde Gerçekte Ne Oldu?

Vercel, 19 Nisan 2026'da bir saldırganın Vercel çalışanı tarafından kullanılan üçüncü taraf bir yapay zeka üretkenlik aracı olan Context.ai'yi ele geçirdiğini açıkladı. Saldırgan oradan çalışanın Vercel Google Workspace hesabını devraldı, Vercel'in iç ortamına sızdı ve "hassas" olarak işaretlenmemiş ortam değişkenlerine erişti.

"Hassas" olarak işaretlenmiş değişkenler ayrı bir şifreli okuma yolu kullanıyor; Vercel, bunların ifşa edildiğine dair kanıt bulunmadığını belirtiyor. Geri kalan her şey — API anahtarları, veritabanı URL'leri, JWT secretları depolayan sıradan env değişkenleri — okunabilir durumdaydı. Bir siber suç forumundaki gönderi, Vercel verilerini 2 milyon dolara sattığını iddia ediyor; ancak Vercel bu iddiayı henüz doğrulamadı. Her halükarda güvenli hamle, doğrudan sizinle iletişime geçilmemiş olsa bile rotasyon amacıyla bir ele geçirme varsayımında bulunmaktır.

Şirket, saldırganı "operasyonel hızı ve Vercel sistemlerini ayrıntılı anlayışı temelinde son derece sofistike" olarak nitelendirdi. Çevirisi: script kiddie değil — saati ciddiye alın.

Etkilendi Misiniz? 5 Dakikada Kontrol Edin

Kısa yanıt: Vercel kullanıyorsanız ve "Hassas" geçişi konusunda titiz davranmadıysanız kendinizi etkilenmiş olarak kabul edin. 5 dakikalık değerlendirme:

• Vercel etkinlik günlüğünü açın ve 1 Nisan 2026'dan bugüne kadar filtreleyin. Tanımadığınız girişlere, token oluşturmalarına veya dağıtımlara bakın.
• Google Workspace Admin → Güvenlik → API Kontrolleri'ne gidin ve yayımlanan güvenlik ihlali göstergesini arayın: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com OAuth istemci kimliği. Yetkilendirilmişse derhal iptal edin.
• Ekibinizdeki birinin Google SSO ile Context.ai'ye giriş yapıp yapmadığını kontrol edin. Evet ise o hesapları daha yüksek riskli olarak ele alın.
• Vercel projenizin Ortam Değişkenleri sekmesine bakın. Kaç tanesinin "Hassas" olarak işaretlenmediğini sayın. Bunların her biri etki alanı içindedir.

Vercel'den "We identified a security incident affecting your account" diye başlayan bir e-posta aldıysanız — onaylanan etkilenen grubundasınız. Doğrudan rotasyon bölümüne atlayın ve ŞİMDİ başlayın.

60 Dakikalık Acil Müdahale Planı

Sıralama patlama yarıçapına göre belirlenmiştir. Adımları atlamayın — her adım bir sonrakinin önünü açar.

Adım 1: Ortamı Dondurun (İlk 10 Dakika)

Adli analiz başlamadan önce kanamayı durdurun:

• main/production dallarındaki otomatik dağıtımları duraklatın (Vercel Dashboard → Proje → Ayarlar → Git).
• Daha derin bir ele geçirme şüphesi varsa github.com/organizations/<kuruluşunuz>/settings/installations adresinde Vercel GitHub App'i geçici olarak devre dışı bırakın.
• Vercel denetim günlüğünüzü CSV olarak dışa aktarın ve yerel olarak kaydedin. Daha sonra bu GDPR bildirimi gerektiren bir olaya dönüşürse ihtiyacınız olacak.
• Genişletilmiş günlükleri tutmak için Observability Plus'ı etkinleştirin (deneme süresi bile yeterli).

Bu, "kanıtları koruma" adımıdır. Günlük anlık görüntüsünden önce döndürme yapmak zaman çizelgenizi mahveder.

Adım 2: Env Değişkenlerini Çekin ve Secretlar için Tarayın

Terminalinizi açın ve çalıştırın:

vercel link
vercel env pull .env.vercel-audit

Ardından çıktıyı tarayın. En hızlı yol GitGuardian'ın CLI'ıdır:

ggshield secret scan path .env.vercel-audit

Hiçbir şey yüklemek istemiyorsanız, bu kalıplarla grep kullanın — env dosyalarındaki sızdırılan secretların %80'ini yakalar:

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

Her eşleşme bir rotasyon adayıdır. Eşleşmeyen her secret da hâlâ bir kimlik bilgisiyse (veritabanı URL'leri, Redis şifreleri, webhook imzalama anahtarları) O DA rotasyon adayıdır — grep yalnızca açık olanı yakalar.

Adım 3: Secretları Öncelik Sırasına Göre Döndürün (Alfabetik Değil)

Çoğu ekibin hata yaptığı yer burasıdır. Rastgele sırayla 40 secretı döndürürler, bir oturum anahtarı tüm aktif girişleri geçersiz kılar ve destek biletleri patlar. Kademeli yapın:

Tier 0 — Sonraki 30 dakika içinde döndürün:

• Tüm GitHub Personal Access Token'lar (ayrıntılı ve klasik)
• Tüm mevcut Vercel hassas env değişkeni token'ları
• Dağıtım Koruma token'ları

Tier 1 — Bugün döndürün:

• Ödeme işlemcisi gizli anahtarları (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, JWT imzalama anahtarları, oturum çerezleri
• Yazma erişimli veritabanı bağlantı dizgileri (DATABASE_URL, Mongo, Redis)
• Bulut sağlayıcı anahtarları (AWS IAM, GCP hizmet hesapları, Azure istemci secretları)
• Webhook imzalama secretları (gönderende VE alıcıda güncelleyin)

Tier 2 — Bu hafta döndürün:

• Üçüncü taraf SaaS anahtarları (e-posta, SMS, analitik, CRM)
• OAuth istemci secretları
• SMTP kimlik bilgileri, CDN anahtarları

Tier 3 — Uygun zamanda döndürün:

• Salt okunur analitik token'lar, Sentry DSN'leri, genel/anonim anahtarlar

Kritik işlem sırası:

• Veritabanları için: Eskisini iptal etmeden önce yeni kullanıcıyı oluşturun, yoksa rotasyon sırasında siteyi çökertirsiniz.
• Oturum anahtarları için: Bir çıkış etkinliği planlayın — tüm aktif oturumlar geçersiz hale gelir.
• Webhooklar için: Her iki tarafı aynı dağıtım penceresinde güncelleyin.
• Her env değişkeni değişikliğinden sonra yeniden dağıtın. Vercel, değerleri çalışma zamanında değil, oluşturma zamanında yerleştirir.

Adım 4: Her Şeyi "Hassas" Olarak Yeniden Ekleyin

Yeni değerleri geri koyduğunuzda, her biri için "Hassas" geçişini açın. Hassas değerler ayrı bir şifreli yol kullanır ve Vercel'in kendi bültenine göre bu olayda ifşa edilmedi. Bu, etkilenen müşterilerin çoğunu kurtarabilecek tek tıklık değişikliktir.

Adım 5: Deponuzu İstenmeyen Değişiklikler için Denetleyin

Ana dalınızdaki HEAD'i 1 Nisan öncesindeki bilinen iyi bir commit'le karşılaştırın. Şunlara odaklanın:

• package.json betikleri — özellikle postinstall, prepare, preinstall
• Beklenmedik yeni bağımlılıklar için kilitleme dosyaları (package-lock.json, pnpm-lock.yaml)
• Yeni iş akışları veya sabitlenmemiş action'lar için .github/workflows/*.yml
• Oluşturma komutu değişiklikleri veya şüpheli yönlendirmeler için vercel.json
• Bilinmeyen etki alanlarına yönelik yeni başlıklar veya yönlendirmeler için next.config.js

npm paketleri yayımlıyorsanız npm view <pkg> time --json komutunu da çalıştırın ve sizin tarafınızdan yazmadığınız hiçbir şeyin yayımlanmadığını doğrulayın.

Adım 6: Aşağı Yönde Avlanın

Saldırganlar env değişkenlerinde kalmaz — onları kullanır. 1 Nisan'dan bu yana aşağı yöndeki sistemlerinizi sorgulayın:

• AWS CloudTrail: beklenmedik CreateUser, AttachUserPolicy, S3 GetObject patlamaları, yeni IP'lerden girişler.
• Veritabanı denetim günlükleri: büyük SELECT * sorguları, dışa aktarmalar, alışılmadık bölgelerden bağlantılar.
• Stripe / Adyen: yeni API anahtarları, şüpheli geri ödemeler, garip konumlardan müşteri oluşturma.
• Kimlik doğrulama sağlayıcısı: imkânsız seyahat girişleri, yetkisiz şifre sıfırlamaları, yeni OAuth uygulamaları.

Buradaki herhangi bir bulgu, bunu bir rotasyon egzersizinden gerçek bir olaya dönüştürür — tırmandırın ve bildirim yükümlülüklerini (GDPR: 72 saat) göz önünde bulundurun.

"Vibe-Coder"ların Gözden Kaçırdıkları: Gizli Saldırı Yüzeyi

Claude Code, Cursor veya Copilot gibi araçlarla yapay zeka destekli kodlama yoluyla geliştirmeye başladıysanız, muhtemelen ilk güvenlik belgesini okumadan önce Vercel'e ilk uygulamanızı dağıttınız. Bu anlaşılır. Ancak vibe-coder'ları deneyimli geliştiricilerden daha sert vuran dört gizli tuzak var:

1. NEXT_PUBLIC_** tuzağı.** NEXT_PUBLIC_ ön ekiyle başlayan her şey istemci JavaScript'ine eklenir. Oraya "sadece test için" bir API anahtarı koyduyasanız, ihlalden önce zaten herkese açıktı. Oluşturma çıktınızı tarayın: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Linear/Slack sızıntısı. Ekibiniz secretları Linear sorunlarına veya Slack iş parçacıklarına "bir saniyeliğine" yapıştırıyorsa, bu secretlar üçüncü taraf günlüklerinde oturmaktadır. Linear denetim günlüğünüzü kontrol edin ve aynı regex kalıplarını arayın.
3. Özel depodaki .env.local varsayımı. Vercel GitHub App'iniz ele geçirildiyse özel depolar özel değildir. Commit edilmiş her .env.* dosyası etki alanı içindedir.
4. Üretim secretlarıyla önizleme dağıtımları. Çoğu vibe-coder, önizleme ortamları için üretim env değişkenlerini yeniden kullanır. Bu, saldırı yüzeyinizi iki katına çıkarır. Bunları ayırın.

Bu, yapay zeka kodlama araçlarının atladığı sıkıcı altyapı işidir. Çözüm, yapay zekayı kullanmayı bırakmak değil — yapay zeka hızını güvenlik temeli ile birleştirmektir. Uygulamanızın nerede yaşadığını hâlâ çözmeye çalışıyorsanız, Vercel vs Netlify karşılaştırmamız ve Railway vs Render vs Fly.io analizimiz iyi başlangıç noktalarıdır.

Stackinizi Bir Sonraki İhlal Sizi Yakmayacak Şekilde Nasıl Sertleştirirsiniz

Platform ihlalleri bir ne zaman sorusudur, olup olmayacağı değil. Her üretim uygulamasının pazartesiye kadar hazır bulundurması gereken temel:

• Vercel'deki her yeni env değişkenini varsayılan olarak "Hassas" yapın. Ekibinizin alışkanlığı haline getirin.
• Kısa ömürlü kimlik bilgileri kullanın. Uzun ömürlü AWS/GCP anahtarlarını GitHub OIDC federasyonuyla değiştirin — bulut sağlayıcınız CI kimliğine doğrudan güvenir, sızdırılacak uzun ömürlü secret olmaz.
• Commit öncesi secret tarama kurun (gitleaks, Trufflehog). Secretların depoya girmesini baştan engeller.
• GitHub App'inizi kuruluş genelinde değil, belirli depolarla kısıtlayın.
• Google Workspace, Microsoft 365, GitHub ve Vercel genelinde üç ayda bir OAuth uygulama incelemesi yapın. Tanımadığınız her şeyi silin.
• Secret taramalarını Claude Code hook'u olarak çalıştırın — yapay zeka unutsa bile deterministik commit öncesi uygulama.
• Next.js sürümünüzü sabitleyin ve güvenlik danışma belgelerini takip edin. Vercel, birincil Next.js sorumlusudur, bu nedenle buradaki olaylar kademelenir.
• Backend secretlarınızı bölümlendirin. Supabase veya Firebase kullanıyorsanız, satır düzeyinde güvenliği ve hizmet rolü anahtarlarını tutumlu kullanın — sızdırılan bir hizmet anahtarı tam bir veritabanı ele geçirmesidir.

Bunu Kilitlemek için Yardıma mı İhtiyaçNız Var? Techsy Burada Devreye Giriyor

Dürüst konuşalım: Küçük ekiplerin çoğunun güvenlik mühendisi yok; sabah 2'de 60 adımlı bir olay müdahale planını okumak kimsenin pazartesini geçirmek istediği bir şey değil.

Techsy olarak son iki yılda 40'tan fazla üretim Next.js ve Node.js uygulaması için olay müdahalesi ve platform sertleştirmesi gerçekleştirdik. Vercel olayı için özel olarak sunduklarımız:

• 72 Saatlik Acil Müdahale — Tier 0/Tier 1 rotasyonunu yürütür, env değişkenlerinizi 200'den fazla secret imzasına karşı tararız ve Vercel, GitHub ve bulut günlüklerinizi baştan sona denetleriz. Tipik teslim süresi: bir iş günü.
• Platform Sertleştirme Denetimi — Hassas değişken geçişi, OIDC kimlik bilgisi rotasyonu, commit öncesi secret tarama, GitHub App kapsamlandırma ve bir sonraki ihlalde ne yapacağınızı bilmeniz için yazılı bir runbook.
• Sürekli DevSecOps — Üç aylık OAuth incelemeleri, sürekli secret tarama ve "bize olmaz" iddiasını gerçekten destekleyebileceğiniz bir hale getirmek için olay tatbikatları.

Biz mühendisleriz, kutucuk işaretleyen güvenlik satıcısı değil. Şu an paniklediyseniz, ücretsiz 30 dakikalık triage görüşmesi için iletişime geçin — yukarıdaki planla bunu kendiniz halledebilecek misiniz yoksa bize mi ihtiyacınız var, dürüstçe söyleriz.

Sıkça Sorulan Sorular

Vercel hacklemesi doğrulanmış mı, yoksa sadece bir söylenti mi?

Doğrulandı. Vercel, 19 Nisan 2026'da üçüncü taraf bir yapay zeka aracı (Context.ai) ve ele geçirilmiş bir çalışan Google Workspace hesabı üzerinden yetkisiz erişim gerçekleştiğini kabul eden resmi bir güvenlik bülteni yayımladı. "Hassas" olarak işaretlenmemiş ortam değişkenlerine erişildi. Ayrı bir BreachForums gönderisi, verilerin 2 milyon dolara satıldığını iddia ediyor; bu kısım doğrulanmadı.

Vercel'den e-posta almadım. Güvende miyim?

Muhtemelen, ama "muhtemelen" bir güvenlik duruşu değildir. Vercel, yalnızca onaylanmış etkisi olan sınırlı müşteri alt kümesini bilgilendirdiğini belirtti. E-postanız gelmediyse riskiniz daha düşüktür — ancak Vercel platformundaki tüm hassas olmayan env değişkenleri etki alanı içindeydi. Yine de 10 dakikalık değerlendirmeyi yapın.

Vercel'deki "hassas" ve normal env değişkenleri arasındaki fark nedir?

"Hassas" ortam değişkenleri ayrı bir şifreli okuma yolu kullanır ve oluşturulduktan sonra panelden görüntülenemez. Normal env değişkenleri, proje erişimi olan herkes tarafından okunabilir — bu olayda saldırgan da dahil olmak üzere. Çözüm ücretsiz ve değişken başına bir tıklama gerektirir.

Tüm secretlarımı mı döndürmeliyim, yoksa yalnızca Vercel'dekileri mi?

Hassas olmayan Vercel env değişkeninde saklanan her secretı döndürün. Aynı anahtarı başka bir yerde kullandıysanız (yaygın bir anti-kalıp), her yerde döndürün. Önizleme dağıtımlarındaki .env.local'ı, GitHub Actions gibi CI sistemlerini ve Linear veya Slack'e yapıştırılan tüm referansları unutmayın.

Env değişkenlerimi gerçek secretlar için nasıl hızlıca tararım?

vercel env pull .env.audit çalıştırın, ardından ggshield secret scan path .env.audit. GitGuardian yükleyemiyorsanız, planın 2. adımındaki tek satır grep komutunu kullanın — AWS anahtarlarını, Stripe anahtarlarını, GitHub token'larını, npm token'larını, JWT'leri ve PEM bloklarını yakalar.

Bu olayın ardından Vercel'den ayrılmalı mıyım?

Yalnızca bu olay nedeniyle değil. Vercel'in yanıtı — kamuya açık IoC, zaman çizelgesi, rotasyon rehberliği — makul ölçüde şeffaf oldu. Her platform eninde sonunda bir ihlalle karşılaşacak. Önemli olan, bunun için tasarlanmış olup olmadığınızdır: varsayılan hassas değişkenler, kısa ömürlü kimlik bilgileri, bölümlendirilmiş ortamlar. Alternatifleri değerlendiriyorsanız, Vercel vs Netlify ve Railway vs Render vs Fly.io yazılarımız değiş tokuşları ele alıyor.

Etkilendiysem müşterileri bildirmek için ne kadar zamanım var?

GDPR size bildirilebilir bir ihlalden haberdar olduğunuz andan itibaren 72 saat veriyor. Kaliforniya (CCPA), veri sınıfına özgü tetikleyicilere sahip. SOC 2/ISO 27001 sözleşmeleri genellikle düzenleyicilerden daha erken bildirim gerektiriyor. Ödeme yapan müşterileriniz varsa ve verilerinin dışa aktarıldığını onaylarsanız, 72 saatlik bir saat üzerinde olduğunuzu varsayın ve herhangi bir şey göndermeden önce hukuk danışmanıyla görüşün.

Vercel'de değilsem bile Next.js uygulamalarına bu yolla saldırılabilir mi?

Olay Vercel platformuna özgüdür. Başka bir yerde barındırılan Next.js'in kendisi ihlal mekanizmasından etkilenmedi. Ancak secretları yanlışlıkla ortaya çıkaran aynı NEXT_PUBLIC_ env değişken kalıplarını kullandıysanız, bu sorunlar kodunuzla birlikte her barındırma sağlayıcısına taşınır. Her durumda oluşturma çıktınızı denetleyin.

Çoğu hasarı önleyebilecek tek tıklık düzeltme nedir?

Vercel'deki her kimlik bilgisi içeren env değişkenini en başından "Hassas" olarak işaretlemek. Bu, paneldeki bir onay kutusudur. Bu olayda hassas değişkenler ERİŞİLMEDİ — yalnızca normal olanlar erişildi. Düzeltme bu, maliyeti sıfır TL ve proje başına yaklaşık beş dakika.

Ekibimin bir daha işaretsiz secret göndermediğinden nasıl emin olurum?

Üç katman: (1) gitleaks ile commit öncesi secret tarama, (2) Vercel API üzerinden sensitive: true bayrağı olmadan bir env değişkeni eklenirse başarısız olan bir CI kontrolü ve (3) her düzenlemede tarayıcıyı çalıştıran bir Claude Code hook'u. Derinlemesine savunma — üçünden herhangi biri %80'ini yakalar, üçü birlikte ~%99'unu.

Sonuç

Vercel'in Nisan 2026 ihlali ciddidir, ancak aşılabilir — önümüzdeki 60 dakika içinde hareket ederseniz. Dağıtımları dondurun, env değişkenlerini çekin, grep'i çalıştırın, kademeli döndürün, hassas olarak yeniden ekleyin ve aşağı yönü araştırın. Tüm plan bu.

Platform ihlalleri, varsayılanlara ne kadar güvendiğimizi ortaya koyuyor. Burada zarar gören ekiplerin çoğu yanlış bir şey yapmadı — "Hassas" geçişini işaretlemedi çünkü kimse bunun önemli olduğunu söylemedi. Vibe-coder'lar için gerçek ders bu: Yapay zeka destekli kod hızla yayımlanır, ancak güvenlik varsayılanları üretimle birlikte gelmez.

Stackinize ikinci bir gözle bakmak istiyorsanız ya da bu planı sabah 2'de yalnız başınıza uygulamak istemiyorsanız, Techsy ekibiyle ücretsiz triage görüşmesi rezervasyonu yapın. Aksi takdirde — başarılar, hızlı hareket edin ve o değişkenleri hassas olarak işaretleyin.