Vercel Bị Hack (Tháng 4/2026): Quy Trình Khẩn Cấp 60 Phút Mà Mọi Developer Cần Thực Hiện Ngay

Vercel Bị Hack (Tháng 4/2026): Quy Trình Khẩn Cấp 60 Phút Mà Mọi Developer Cần Thực Hiện Ngay

Vào ngày 19 tháng 4 năm 2026, Vercel xác nhận rằng kẻ tấn công đã xâm nhập vào một công cụ AI bên thứ ba (Context.ai), chiếm quyền kiểm soát tài khoản Google Workspace của một nhân viên Vercel và đọc các biến môi trường không được đánh dấu là "nhạy cảm" trên một tập hợp con hạn chế các dự án của khách hàng. Nếu bạn đã triển khai bất kỳ thứ gì lên Vercel trong 30 ngày qua, bạn cần giả định rằng một trong các biến env của mình có thể đã nằm trong tay người khác và bạn cần hành động nhanh chóng.

Đây là sự thật khó chịu: hầu hết các vibecoder (lập trình viên dựa nhiều vào AI/cảm hứng) đều đẩy các giá trị .env thẳng từ template mà không bao giờ chạm vào nút chuyển đổi "sensitive" (nhạy cảm). Đó chính xác là loại biến mà kẻ tấn công đã đọc được. Quy trình này sẽ hướng dẫn bạn từng bước trong 60 phút tiếp theo: những gì cần kiểm tra, những gì cần xoay vòng (rotate) và cách củng cố hệ thống của bạn để đảm bảo vụ vi phạm nền tảng tiếp theo không làm sập ứng dụng của bạn.

Tóm tắt nhanh: Những việc cần làm trong 60 phút tới

Nếu bạn không đọc gì khác, hãy thực hiện ngay sáu điều sau:

1. Tạm dừng auto-deploy trên các nhánh production.
2. Chạy vercel env pull và dùng grep để tìm các mẫu bí mật trong đầu ra (sk_live_, AKIA, ghp_, eyJ).
3. Xoay vòng mọi khóa API được lưu trữ dưới dạng biến env không nhạy cảm, bắt đầu với các khóa thanh toán, cơ sở dữ liệu, xác thực và nhà cung cấp đám mây.
4. Thêm lại các bí mật đã xoay vòng bằng cách bật nút chuyển đổi "Sensitive" của biến môi trường trong Vercel, sau đó triển khai lại.
5. Mở nhật ký hoạt động (activity log) của Vercel từ ngày 1–20 tháng 4 và đánh dấu bất kỳ sự kiện triển khai, đăng nhập hoặc token nào mà bạn không nhận ra.
6. Xem xét nhật ký kiểm toán (audit log) của tổ chức GitHub trong cùng khoảng thời gian, tìm các PAT mới, khóa triển khai hoặc thay đổi workflow.

Dưới đây là phân tích chi tiết, bao gồm các lệnh, mẫu nhận diện và thứ tự ưu tiên xoay vòng mà bạn sẽ cần.

Chuyện gì thực sự đã xảy ra trong vụ vi phạm Vercel tháng 4/2026?

Vercel đã thông báo vào ngày 19 tháng 4 năm 2026 rằng kẻ tấn công đã xâm nhập Context.ai, một công cụ năng suất AI bên thứ ba được một nhân viên Vercel sử dụng. Từ đó, kẻ tấn công chiếm quyền kiểm soát tài khoản Google Workspace của Vercel thuộc về nhân viên này, di chuyển sang môi trường nội bộ của Vercel và truy cập vào các biến môi trường không được gắn cờ là "nhạy cảm".

Các biến được đánh dấu là "nhạy cảm" sử dụng đường dẫn đọc được mã hóa riêng biệt, và Vercel khẳng định không có bằng chứng cho thấy chúng bị lộ. Mọi thứ khác, bao gồm các biến env thông thường lưu trữ khóa API, URL cơ sở dữ liệu, bí mật JWT, đều có thể đọc được. Một bài đăng trên diễn đàn tội phạm mạng sau đó tuyên bố đang bán dữ liệu Vercel với giá 2 triệu đô la, mặc dù Vercel chưa xác nhận việc dữ liệu bị đánh cắp. Dù thế nào đi nữa, hành động an toàn nhất là giả định đã bị xâm phạm để phục vụ mục đích xoay vòng, ngay cả khi Vercel chưa gửi email trực tiếp cho bạn.

Công ty đánh giá kẻ tấn công là "cực kỳ tinh vi dựa trên tốc độ hoạt động và sự hiểu biết chi tiết về hệ thống của Vercel." Nói cách khác: đây không phải là trò đùa của trẻ con, hãy coi trọng từng giây phút.

Bạn có bị ảnh hưởng không? Cách kiểm tra trong 5 phút

Câu trả lời ngắn gọn: nếu bạn sử dụng Vercel và chưa từng nghiêm túc tuân thủ việc bật nút "Sensitive", hãy coi như bạn bị ảnh hưởng. Đây là quy trình sàng lọc trong 5 phút:

• Mở nhật ký hoạt động của Vercel và lọc từ ngày 1 tháng 4 năm 2026 đến nay. Tìm kiếm các lần đăng nhập lạ, tạo token hoặc triển khai không rõ nguồn gốc.
• Vào Google Workspace Admin → Security → API Controls và tìm kiếm chỉ số thỏa hiệp đã được công bố: OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Nếu nó được ủy quyền, hãy thu hồi ngay lập tức.
• Kiểm tra xem bất kỳ ai trong nhóm của bạn đã từng đăng nhập vào Context.ai bằng Google SSO hay chưa. Nếu có, hãy coi tài khoản của họ là rủi ro cao hơn.
• Xem tab Environment Variables của dự án Vercel. Đếm xem có bao nhiêu biến KHÔNG được đánh dấu là "Sensitive". Tất cả những biến đó đều nằm trong phạm vi ảnh hưởng.

Nếu bạn nhận được email từ Vercel bắt đầu bằng dòng "We identified a security incident affecting your account" (Chúng tôi xác định một sự cố bảo mật ảnh hưởng đến tài khoản của bạn), bạn nằm trong nhóm bị ảnh hưởng đã được xác nhận. Hãy bỏ qua phần giới thiệu và bắt đầu phần xoay vòng NGAY LẬP TỨC.

Quy Trình Ứng Phó Khẩn Cấp 60 Phút

Quy trình này được sắp xếp theo mức độ ảnh hưởng (blast radius). Không bỏ qua bước nào, vì mỗi bước đều mở đường cho bước tiếp theo.

Bước 1: Đóng băng Môi trường (10 phút đầu tiên)

Ngăn chặn thiệt hại lan rộng trước khi bắt đầu điều tra pháp lý số:

• Tạm dừng auto-deploy trên các nhánh main / production (Vercel Dashboard → Project → Settings → Git).
• Tạm thời vô hiệu hóa Vercel GitHub App tại github.com/organizations/<your-org>/settings/installations nếu bạn nghi ngờ có sự xâm nhập sâu hơn.
• Xuất nhật ký kiểm toán (audit log) của Vercel ra file CSV và lưu cục bộ. Bạn sẽ cần nó nếu sự cố này trở thành một sự cố phải thông báo theo GDPR sau này.
• Bật Observability Plus (thậm chí chỉ dùng thử một tuần) để giữ lại các nhật ký mở rộng.

Đây là bước "bảo tồn bằng chứng". Xoay vòng khóa trước khi chụp ảnh nhanh nhật ký sẽ phá hủy dòng thời gian sự kiện của bạn.

Bước 2: Kéo Biến Env và Quét Tìm Bí Mật

Mở terminal và chạy:

vercel link
vercel env pull .env.vercel-audit

Sau đó quét đầu ra. Cách nhanh nhất là sử dụng CLI của GitGuardian:

ggshield secret scan path .env.vercel-audit

Nếu bạn không muốn cài đặt thêm gì, hãy dùng grep để tìm các mẫu sau, chúng phát hiện 80% bí mật bị rò rỉ trong các file env:

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

Mỗi kết quả khớp là một ứng cử viên cần xoay vòng. Mọi bí mật không khớp nhưng vẫn là thông tin xác thực (URL DB, mật khẩu Redis, khóa ký webhook) cũng LÀ ứng cử viên cần xoay vòng; lệnh grep chỉ bắt những thứ hiển nhiên nhất.

Bước 3: Xoay Vòng Bí Mật Theo Thứ Tự Ưu Tiên (Không phải theo bảng chữ cái)

Đây là nơi hầu hết các nhóm mắc sai lầm. Họ xoay vòng 40 bí mật theo thứ tự ngẫu nhiên, một khóa session bị vô hiệu hóa làm hỏng mọi phiên đăng nhập đang hoạt động, và vé hỗ trợ kỹ thuật tăng vọt. Hãy làm theo từng tầng:

Tầng 0 — Xoay vòng trong 30 phút tới:

• Tất cả GitHub Personal Access Tokens (cả loại fine-grained và classic)
• Tất cả token biến env nhạy cảm hiện có của Vercel
• Token Deployment Protection

Tầng 1 — Xoay vòng trong hôm nay:

• Khóa bí mật của bộ xử lý thanh toán (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, khóa ký JWT, cookie session
• Chuỗi kết nối cơ sở dữ liệu có quyền ghi (DATABASE_URL, Mongo, Redis)
• Khóa nhà cung cấp đám mây (AWS IAM, tài khoản dịch vụ GCP, bí mật client Azure)
• Bí mật ký Webhook (cập nhật ở cả bên gửi VÀ bên nhận)

Tầng 2 — Xoay vòng trong tuần này:

• Khóa SaaS bên thứ ba (email, SMS, analytics, CRM)
• Bí mật client OAuth
• Thông tin xác thực SMTP, khóa CDN

Tầng 3 — Xoay vòng khi thuận tiện:

• Token analytics chỉ đọc, Sentry DSNs, khóa public/anon

Thứ tự thao tác quan trọng:

• Đối với cơ sở dữ liệu: tạo người dùng mới trước khi thu hồi người dùng cũ, nếu không bạn sẽ làm sập trang web giữa chừng.
• Đối với khóa session: lên kế hoạch cho sự kiện đăng xuất, mọi phiên đang hoạt động sẽ chết.
• Đối với webhook: cập nhật cả hai phía trong cùng một cửa sổ triển khai.
• Triển khai lại sau mỗi lần thay đổi biến env. Vercel đóng gói các giá trị tại thời điểm build, không phải runtime.

Bước 4: Thêm Lại Mọi Thứ Dưới Dạng "Sensitive"

Khi bạn đưa các giá trị mới vào, hãy bật nút chuyển đổi "Sensitive" cho từng biến một. Các giá trị nhạy cảm sử dụng đường dẫn mã hóa riêng biệt và, theo thông báo của chính Vercel, đã không bị lộ trong sự cố này. Đây là thay đổi chỉ với một cú nhấp chuột lẽ ra đã cứu được hầu hết các khách hàng bị ảnh hưởng.

Bước 5: Kiểm Tra Repo Để Tìm Thay Đổi Không Mong Muốn

So sánh HEAD trên nhánh main của bạn với một commit đáng tin cậy từ trước ngày 1 tháng 4. Tập trung vào:

• Các script trong package.json, đặc biệt là postinstall, prepare, preinstall
• File lock (package-lock.json, pnpm-lock.yaml) để tìm các dependency mới bất ngờ
• .github/workflows/*.yml để tìm workflow mới hoặc actions không được ghim phiên bản
• vercel.json để tìm thay đổi lệnh build hoặc các rewrite đáng ngờ
• next.config.js để tìm header mới hoặc redirect trỏ đến các domain lạ

Nếu bạn xuất bản các gói npm, hãy chạy thêm npm view <pkg> time --json và xác minh không có gì được phát hành mà bạn không phải là tác giả.

Bước 6: Truy Tìm Ảnh Hưởng Lan Truyền

Kẻ tấn công không dừng lại ở biến env, chúng sử dụng chúng. Hãy truy vấn các hệ thống downstream của bạn cho khoảng thời gian từ ngày 1 tháng 4 đến nay:

• AWS CloudTrail: các lệnh CreateUser, AttachUserPolicy bất ngờ, bùng nổ lệnh S3 GetObject, đăng nhập từ IP mới.
• Nhật ký kiểm toán cơ sở dữ liệu: các truy vấn SELECT * lớn, xuất dữ liệu, kết nối từ các khu vực bất thường.
• Stripe / Adyen: khóa API mới, hoàn tiền đáng ngờ, tạo khách hàng từ các vị trí lạ.
• Nhà cung cấp xác thực: đăng nhập "du lịch không thể" (impossible-travel), đặt lại mật khẩu trái phép, ứng dụng OAuth mới.

Bất kỳ dấu hiệu nào ở đây sẽ biến việc này từ một bài tập xoay vòng thành một sự cố thực sự, hãy leo thang và xem xét nghĩa vụ thông báo (GDPR: 72 giờ).

Những Gì "Vibecoders" Bỏ Qua: Bề Mặt Tấn Công Ẩn

Nếu bạn bắt đầu coding với sự hỗ trợ của AI, sử dụng các công cụ như Claude Code, Cursor hoặc Copilot, có thể bạn đã triển khai ứng dụng Vercel đầu tiên của mình trước khi ever đọc tài liệu bảo mật. Điều đó không sao. Nhưng có bốn bẫy ẩn gây ảnh hưởng nặng nề hơn cho vibecoders so với các developer dày dạn kinh nghiệm:

1. Cú súng NEXT_PUBLIC_. Bất cứ thứ gì có tiền tố NEXT_PUBLIC_ đều được đóng gói vào JavaScript phía client. Nếu bạn nhét một khóa API vào đó "chỉ để test", thì nó đã công khai từ trước cả vụ hack. Hãy grep đầu ra build của bạn: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Rò rỉ qua Linear / Slack. Nếu nhóm của bạn dán bí mật vào các issue Linear hoặc thread Slack "chỉ trong một giây", những bí mật đó nằm trong nhật ký của bên thứ ba. Hãy xem lại nhật ký kiểm toán Linear và tìm kiếm các mẫu regex tương tự như trên.
3. Giả định .env.local trong repo riêng tư. Repo riêng tư không còn riêng tư nếu Vercel GitHub App của bạn bị xâm nhập. Mọi file .env.* đã commit đều nằm trong phạm vi ảnh hưởng.
4. Triển khai Preview với bí mật Production. Hầu hết vibecoders tái sử dụng biến env production cho môi trường preview. Điều này làm gấp đôi bề mặt tấn công của bạn. Hãy tách biệt chúng.

Đây là công việc hạ tầng nhàm chán mà các công cụ coding AI thường bỏ qua. Giải pháp không phải là ngừng sử dụng AI, mà là kết hợp tốc độ của AI với một tiêu chuẩn bảo mật cơ bản. Nếu bạn vẫn đang mơ hồ về nơi ứng dụng của mình thực sự tồn tại, bài so sánh Vercel vs Netlify và phân tích Railway vs Render vs Fly.io của chúng tôi là những điểm khởi đầu tốt.

Cách Củng Cố Hệ Thống Để Vụ Vi Phạm Tiếp Theo Không Thiêu Rụi Bạn

Vi phạm nền tảng là chuyện khi nào, không phải liệu có. Đây là tiêu chuẩn cơ bản mà mọi ứng dụng production nên có sẵn trước thứ Hai:

• Mặc định mọi biến env mới là "Sensitive" trong Vercel. Hãy biến nó thành phản xạ có điều kiện của nhóm.
• Sử dụng thông tin xác thực ngắn hạn. Thay thế các khóa AWS/GCP dài hạn bằng liên kết GitHub OIDC, nhà cung cấp đám mây của bạn sẽ tin tưởng trực tiếp vào danh tính CI, không có bí mật dài hạn nào để bị rò rỉ.
• Cài đặt quét bí mật pre-commit (gitleaks, Trufflehog). Ngăn chặn bí mật xâm nhập vào repo ngay từ đầu.
• Hạn chế quyền của GitHub App cho các repo cụ thể, không phải toàn bộ tổ chức.
• Xem xét ứng dụng OAuth hàng quý trên Google Workspace, Microsoft 365, GitHub và Vercel. Loại bỏ bất kỳ thứ gì bạn không nhận ra.
• Chạy quét bí mật như một hook của Claude Code, thực thi pre-commit mang tính quyết định ngay cả khi AI quên.
• Ghim phiên bản Next.js và theo dõi các advisory. Vercel là người quản lý chính của Next.js, nên sự cố ở đây sẽ kéo theo nhiều hệ lụy.
• Phân đoạn bí mật backend. Nếu bạn đang dùng Supabase hoặc Firebase, hãy sử dụng bảo mật cấp hàng (row-level security) và khóa service-role một cách hạn chế, vì một khóa service bị lộ đồng nghĩa với việc toàn bộ DB bị xâm phạm.

Cần Giúp Đỡ Để Khóa Chặt Hệ Thống? Techsy Có Thể Hỗ Trợ Như Thế Nào

Đây là lời đề nghị chân thành: hầu hết các nhóm nhỏ không có kỹ sư bảo mật, và việc đọc một quy trình ứng phó sự cố 60 bước lúc 2 giờ sáng không phải là cách ai cũng muốn dành cho ngày thứ Hai của mình.

Tại Techsy, chúng tôi đã thực hiện ứng phó sự cố và củng cố nền tảng cho hơn 40 ứng dụng Next.js và Node.js production trong hai năm qua. Riêng đối với sự cố Vercel, chúng tôi cung cấp:

• Ứng Phó Khẩn Cấp 72 Giờ, Chúng tôi thực hiện xoay vòng Tầng 0 / Tầng 1, quét biến env của bạn dựa trên hơn 200 chữ ký bí mật, và kiểm toán nhật ký Vercel + GitHub + cloud từ đầu đến cuối. Thời gian xử lý điển hình: một ngày làm việc.
• Kiểm Toán Củng Cố Nền tảng, Di chuyển biến nhạy cảm, xoay vòng thông tin xác thực OIDC, quét bí mật pre-commit, giới hạn phạm vi GitHub App và một cuốn sổ tay vận hành (runbook) bằng văn bản để bản thân bạn trong tương lai biết phải làm gì trong vụ vi phạm tiếp theo.
• DevSecOps Liên Tục, Xem xét OAuth hàng quý, quét bí mật liên tục và diễn tập sự cố để biến câu nói "chuyện đó sẽ không xảy ra với chúng tôi" thành một tuyên bố mà bạn thực sự có thể bảo vệ.

Chúng tôi là kỹ sư, không phải nhà cung cấp bảo mật chỉ để đối phó giấy tờ. Nếu bạn đang hoảng loạn ngay bây giờ, liên hệ để đặt cuộc gọi sàng lọc miễn phí 30 phút, chúng tôi sẽ nói thẳng với bạn liệu bạn có cần chúng tôi hay không, hay bạn có thể tự xử lý với quy trình trên.

Câu Hỏi Thường Gặp

Vụ hack Vercel là có thật hay chỉ là tin đồn?

Đã được xác nhận. Vercel đã công bố một bản tin bảo mật chính thức vào ngày 19 tháng 4 năm 2026, thừa nhận quyền truy cập trái phép thông qua một công cụ AI bên thứ ba bị xâm nhập (Context.ai) và một tài khoản Google Workspace của nhân viên bị chiếm quyền. Các biến môi trường không được đánh dấu là "nhạy cảm" đã bị truy cập. Một bài đăng riêng trên BreachForums tuyên bố đang bán dữ liệu với giá 2 triệu USD; phần này chưa được xác minh.

Tôi không nhận được email từ Vercel. Tôi có an toàn không?

Có thể, nhưng "có thể" không phải là một tư thế bảo mật. Vercel cho biết họ đã liên hệ với tập hợp con hạn chế các khách hàng bị ảnh hưởng được xác nhận. Nếu email không đến tay bạn, rủi ro của bạn thấp hơn, nhưng mọi biến env không nhạy cảm trên toàn nền tảng Vercel đều nằm trong phạm vi ảnh hưởng. Vẫn hãy thực hiện quy trình sàng lọc 10 phút ở trên.

Sự khác biệt giữa biến env "sensitive" và thông thường trong Vercel là gì?

Biến môi trường "Sensitive" sử dụng đường dẫn đọc được mã hóa riêng biệt và không thể xem được trong dashboard sau khi tạo. Các biến env thông thường có thể đọc được bởi bất kỳ ai có quyền truy cập dự án (bao gồm cả kẻ tấn công trong sự cố này). Giải pháp là miễn phí và chỉ mất một cú nhấp chuột cho mỗi biến.

Tôi có cần xoay vòng TẤT CẢ bí mật của mình, hay chỉ những cái trên Vercel?

Hãy xoay vòng mọi bí mật được lưu trữ trong biến env không nhạy cảm của Vercel. Nếu bạn đã sử dụng cùng một khóa ở nơi khác (một phản mẫu phổ biến), hãy xoay vòng nó ở khắp mọi nơi. Đừng quên .env.local trong các lần triển khai preview, các hệ thống CI như GitHub Actions và bất kỳ tham chiếu nào đã dán vào Linear hoặc Slack.

Làm thế nào để quét nhanh các biến env tìm bí mật thực tế?

Chạy vercel env pull .env.audit sau đó ggshield secret scan path .env.audit. Nếu bạn không thể cài đặt GitGuardian, hãy sử dụng lệnh grep một dòng trong Bước 2 của quy trình, nó bắt được khóa AWS, khóa Stripe, token GitHub, token npm, JWT và các khối PEM.

Tôi có nên chuyển away từ Vercel sau vụ này không?

Không chỉ vì sự cố này. Phản ứng của Vercel, các IoC công khai, dòng thời gian và hướng dẫn xoay vòng khá minh bạch. Mọi nền tảng cuối cùng đều sẽ có lúc bị vi phạm. Điều quan trọng là bạn đã thiết kế hệ thống cho tình huống đó chưa: mặc định biến nhạy cảm, thông tin xác thực ngắn hạn, môi trường phân đoạn. Nếu bạn đang cân nhắc các lựa chọn thay thế, bài viết Vercel vs Netlify và Railway vs Render vs Fly.io của chúng tôi phân tích các đánh đổi.

Tôi có bao lâu để thông báo cho khách hàng nếu bị ảnh hưởng?

GDPR cho bạn 72 giờ kể từ khi nhận thức được một vụ vi phạm phải thông báo. California (CCPA) có các kích hoạt cụ thể theo loại dữ liệu. Hợp đồng SOC 2 / ISO 27001 thường yêu cầu thông báo sớm hơn so với quy định của cơ quan quản lý. Nếu bạn có khách hàng trả phí và xác nhận dữ liệu của họ bị đánh cắp, hãy giả định bạn đang chạy đua với đồng hồ 72 giờ và tham khảo ý kiến pháp lý trước khi gửi bất kỳ thông báo nào.

Ứng dụng Next.js có thể bị tấn công thông qua lỗ hổng này ngay cả khi tôi không dùng Vercel không?

Sự cố này cụ thể đối với nền tảng Vercel. Bản thân Next.js, khi được lưu trữ ở nơi khác, không bị ảnh hưởng bởi cơ chế vi phạm này. Nhưng nếu bạn sử dụng các mẫu biến env NEXT_PUBLIC_ tương tự vô tình làm lộ bí mật, những vấn đề đó sẽ đi theo mã nguồn của bạn bất kể máy chủ nào. Dù sao cũng hãy kiểm tra đầu ra build của bạn.

Giải pháp một cú nhấp chuột nào lẽ ra đã ngăn chặn hầu hết thiệt hại?

Đánh dấu mọi biến env chứa thông tin xác thực là "Sensitive" trong Vercel ngay từ ngày đầu tiên. Đó là một ô checkbox trong dashboard. Trong sự cố này, các biến nhạy cảm đã KHÔNG bị truy cập, chỉ có các biến thông thường bị ảnh hưởng. Đó chính là giải pháp, và nó tốn 0 đô la cùng khoảng 5 phút cho mỗi dự án.

Làm thế nào để đảm bảo nhóm của tôi không bao giờ đẩy một bí mật chưa được đánh dấu nữa?

Ba lớp bảo vệ: (1) quét bí mật pre-commit với gitleaks, (2) một bước kiểm tra CI sẽ thất bại nếu một biến env được thêm vào mà không có cờ sensitive: true thông qua API Vercel, và (3) một hook của Claude Code chạy trình quét trên mỗi lần chỉnh sửa. Phòng thủ theo chiều sâu, bất kỳ lớp nào trong ba lớp này bắt được 80%, cả ba lớp cùng lúc bắt được ~99%.

Kết Luận

Vụ vi phạm Vercel tháng 4/2026 là nghiêm trọng, nhưng có thể vượt qua nếu bạn hành động trong 60 phút tới. Đóng băng triển khai, kéo biến env, chạy grep, xoay vòng theo tầng, thêm lại dưới dạng nhạy cảm và truy tìm ảnh hưởng lan truyền. Đó là toàn bộ quy trình.

Các vụ vi phạm nền tảng phơi bày mức độ chúng ta phụ thuộc vào các cài đặt mặc định. Hầu hết các nhóm bị tổn thương ở đây không làm gì sai, họ chỉ để nút "Sensitive" không được chọn vì không ai nói với họ rằng nó quan trọng. Đó là bài học thực sự cho vibecoders: mã do AI tạo ra được đẩy đi rất nhanh, nhưng các mặc định bảo mật thì không đi kèm với quá trình tạo đó.

Nếu bạn muốn có thêm một cặp mắt xem xét hệ thống của mình, hoặc bạn không muốn tự mình thực hiện quy trình này lúc 2 giờ sáng, đặt cuộc gọi sàng lọc miễn phí với đội ngũ Techsy. Nếu không, chúc may mắn, hành động nhanh và hãy đánh dấu các biến đó là nhạy cảm.