19 thg 4, 2026

Một AI Tool Tôi Chưa Từng Nghe Tên Vừa Cạy Tung Vercel

Ngày 19/4 Vercel công bố breach. Kẻ tấn công đi vào qua OAuth app của một third-party AI tool — và stack của bạn cũng đang tin tưởng cả tá tool như vậy.

Bảo mật

Thẻ (5)

# vercel # supply-chain # oauth # incident-response # security

Tôi đang uống dở ly cà phê sáng Chủ Nhật thì security bulletin của Vercel rơi xuống. Internal systems bị xâm nhập. Một “limited subset” khách hàng đang được liên hệ riêng. Việc cần làm: rotate mọi environment variable không được mark là sensitive. Nguyên nhân? Một AI tool tôi chưa từng nghe tên, đứng cách tài khoản Google Workspace của một nhân viên Vercel đúng một cú click “Allow OAuth”.

Cái phần cuối đó là phần đáng để bạn mất ngủ.

Cái gì đã được xác nhận và cái gì chỉ là tin đồn

Tuyên bố từ threat actor và disclosure từ vendor di chuyển ở hai tốc độ khác hẳn nhau. Trộn lẫn chúng là cách tin đồn biến thành “sự thật”. Đây là phiên bản đã được lọc, cập nhật đến ngày 20/4.

Vercel mô tả attacker là “highly sophisticated based on their operational velocity and detailed understanding of Vercel’s systems.” Mandiant và một số firm khác đang vào cuộc. Đó là kiểu ngôn ngữ vendor dùng khi biết chắc post-mortem sẽ kéo dài hàng tuần.

Kill chain trong năm bước

Cuộc tấn công không xuyên qua perimeter của Vercel. Nó đi thẳng vào cửa chính bằng một chiếc chìa mượn — chiếc chìa mà chính một nhân viên Vercel đã đưa cho một AI vendor nhỏ vài tuần hoặc vài tháng trước đó.

flowchart TD
  A[Attacker] -->|Compromise| B[OAuth app cua Context.ai]
  B -->|Workspace tokens| C[Tai khoan Google nhan vien Vercel]
  C -->|SSO / session| D[Vercel internal env]
  D -->|Read API| E[Env vars khong sensitive]
  D -.->|Bi chan: write-only| F[Sensitive env vars]
  E -.->|Blast radius| G[DB, API, cloud cua khach hang]

IOC mà Vercel công bố đủ cụ thể để hành động ngay hôm nay. Nếu Google Workspace tenant của bạn từng grant cho app này, hãy coi nó như đã bị compromise.

“Sensitive” env vars là lý do mọi chuyện chưa tệ hơn

Chi tiết âm thầm cứu rất nhiều khách hàng là một feature đa số team chưa từng buồn bật lên: mode sensitive environment variable của Vercel. Phần lớn secret trong phần lớn project được lưu dạng env var thường, nghĩa là dashboard có một endpoint trả về plaintext. Tiện cho bạn. Cũng tiện cho kẻ vừa phish được đúng tài khoản Google.

# Regular env var: readable in dashboard, readable via API,
# readable by anyone who can borrow your session
vercel env add DATABASE_URL production

# Sensitive env var: write-once, no read-back endpoint,
# decrypted only at build/runtime injection
vercel env add DATABASE_URL production --sensitive

Cái flag --sensitive không phải mỹ phẩm UI — nó là một storage path khác hẳn. Khi đã ghi xong, không một người hay API call nào lấy lại được plaintext từ Vercel. Attacker, cầm trong tay một session hoàn toàn hợp lệ, gọi API env vars và nhận về đúng cái API được thiết kế để trả: toàn bộ giá trị non-sensitive ở dạng plaintext.

Lỗi kinh điển: coi “encrypted at rest” là từ đồng nghĩa với “an toàn.” Không phải. Encryption at rest bảo vệ bạn khi ai đó cuỗm cái ổ cứng. Nó không làm gì được khi attacker đang đăng nhập như chính bạn.

Encryption at rest không phải access control

Một ví dụ cụ thể, vì điểm này hay làm vấp ngã cả những team cẩn thận.

# Wrong mental model: "the secret is encrypted, so the breach is contained"
def get_db_url():
    blob = vault.fetch_encrypted("DATABASE_URL")  # encrypted at rest, fine
    return aes_decrypt(blob, key=kms.get_key())   # legitimate decrypt path

# Reality: any caller authorized to invoke get_db_url() gets plaintext.
# A hijacked session is, by definition, an authorized caller.

Decrypt xảy ra khi một identity được cấp quyền yêu cầu. Nếu attacker trở thành identity đó — qua một OAuth grant bị chiếm, một session cookie bị đánh cắp, một SSO login bị phish — thì layer encryption đang làm đúng nhiệm vụ của nó: decrypt và đưa plaintext cho hắn. Control bạn thực sự cần nằm ở phía authorization: ai được phép gọi decrypt, trong điều kiện gì, và để lại audit trail nào.

Mode --sensitive của Vercel hiệu quả vì nó loại bỏ hoàn toàn code path “authorized read.” Không có endpoint “decrypt rồi return” để abuse — chỉ có “decrypt rồi inject vào build container.” Threat model khác, code path khác, blast radius khác.

Pattern lặp lại: AI tool nhỏ, OAuth scope to

Vercel không phải vụ đầu tiên trong năm nay, và sẽ không phải vụ cuối. Hình dạng cứ lặp đi lặp lại.

• Salesloft Drift (2025) — OAuth token cho một vendor chat/lead. Attacker dùng nó để hút data Salesforce trên hàng trăm tenant downstream.
• Snowflake customer breaches (2024) — credential dùng đi dùng lại, thiếu MFA, blast radius lan tới khách hàng của khách hàng.
• Vercel qua Context.ai (2026) — một AI tool nhỏ với workspace OAuth scope. Vendor được cho là chỉ có vài trăm user; một trong số đó tình cờ là nhân viên Vercel có đúng quyền truy cập.

Pattern không phải “AI tool vốn dĩ nguy hiểm.” Pattern là trust transference. Mỗi cú click “Allow” cho một OAuth grant là bạn đang nới biên giới tin cậy của mình ra đến tận security posture của bất kỳ ai đang vận hành integration đó. Một SaaS nhỏ với ba engineer và không có SOC thừa hưởng đúng mức tin cậy như IdP của bạn — chỉ có user của bạn không biết chuyện đó.

Cái bẫy tôi gặp suốt: team rà soát kỹ vendor trực tiếp nhưng không bao giờ nhìn vào cái đuôi dài các tool “AI productivity” đã âm thầm tích lũy gmail.modify, drive.readonly, và admin.directory.user.readonly suốt năm qua. Cái đuôi dài đó giờ là cái chợ initial-access hào phóng nhất trên internet.

Cần làm gì trong một giờ tới

Nếu bạn đang ship lên Vercel, đây là danh sách ngắn. Đừng đợi email báo bạn nằm trong “limited subset.”

# 1. Pull the activity log and grep for anything you didn't initiate
vercel activity --json | jq '.[] | select(.createdAt > "2026-04-12")'

# 2. Re-issue every non-sensitive env var, then mark the new value sensitive
vercel env rm DATABASE_URL production
vercel env add DATABASE_URL production --sensitive

# 3. Audit recent deployments — anything you didn't push gets deleted
vercel ls --scope=your-team

Sau đó vào Google Workspace admin console: tìm OAuth app ID ở trên, revoke nếu có, và review mọi third-party app đang giữ scope mail.*, drive.*, hoặc admin.*. Đa số team sẽ tìm thấy ít nhất một app không ai còn nhớ là đã grant.

Với credential đang lưu trong Vercel: rotate ở nguồn trước (RDS password, GitHub token, Stripe key), rồi cập nhật giá trị mới ở dạng --sensitive trong Vercel, rồi redeploy. Làm sai thứ tự sẽ để hở một khoảng thời gian mà key cũ vẫn còn sống ở đâu đó trong tầm tay người lạ.

Bài học đáng giữ lại

Đối xử với OAuth grant của bạn như cách bạn đối xử với database credential: rotate, thu hẹp scope, audit, và mặc định rằng bất kỳ vendor nào đang giữ token từ bạn đều cách “trở thành vấn đề của bạn” đúng một tuần xui xẻo. Vụ Vercel không phải câu chuyện về Vercel. Đó là câu chuyện về phần bụng mềm của mọi SaaS stack hiện đại — cái tool third-party có ba engineer, một OAuth scope đáng lẽ không được phép xin, và một calendar invite từ CISO của bạn mà họ sẽ chẳng bao giờ thấy.

Dành hai mươi phút hôm nay vào Google Workspace admin console. Bạn của tương lai sẽ cảm ơn bạn của hiện tại trong cái lần security bulletin tiếp theo rơi xuống vào sáng Chủ Nhật.

Nguồn tham khảo

• Vercel April 2026 security incident — bulletin chính thức
• Vercel confirms security incident as hackers claim to sell internal access — CyberInsider
• Vercel confirms breach as hackers claim to be selling stolen data — BleepingComputer
• The Vercel Breach: What Actually Happened — dev.to/freerave
• Sensitive environment variables — Vercel docs
• Context.ai security update