Vụ xâm nhập Vercel: Tấn công OAuth phơi bày rủi ro tiềm ẩn của biến môi trường trên nền tảng

• Xâm nhập chuỗi cung ứng OAuth đã dẫn đến việc truy cập vào hệ thống nội bộ của Vercel, làm lộ biến môi trường của một số lượng hạn chế dự án khách hàng
• Điểm khởi đầu là việc một nhân viên Context.ai bị nhiễm Lumma Stealer, và token OAuth Google Workspace bị rò rỉ đã được dùng để truy cập tài khoản nhân viên Vercel cùng các hệ thống nội bộ
• Kẻ tấn công đã có được quyền liệt kê biến môi trường của các dự án khách hàng, đặc biệt là các biến được đánh dấu là non-sensitive, từ đó làm tăng khả năng lộ thông tin xác thực của các dịch vụ hạ nguồn
• Theo các tình tiết đã được công khai, trong ít nhất một trường hợp đã có phát hiện khóa API bị rò rỉ trước khi Vercel công bố, và độ trễ giữa phát hiện với thông báo nổi lên như một yếu tố rủi ro chính
• Vụ xâm nhập này cho thấy mối quan hệ tin cậy OAuth và cách nền tảng lưu trữ biến môi trường có thể cùng nhau dẫn đến sự lan rộng thông tin xác thực trên toàn bộ chuỗi cung ứng

---

Hàm ý chính

• Xác nhận hiệu ứng khuếch đại của OAuth
  • Một mối quan hệ tin cậy OAuth bị xâm phạm đã mở rộng theo chuỗi từ vendor tới hệ thống nội bộ của Vercel
  • Ngay cả biến môi trường của các dự án khách hàng không có quan hệ trực tiếp với vendor bị xâm phạm cũng bị lộ ở mức độ hạn chế
• Khả năng có hành vi tấn công được AI tăng tốc
  • CEO đã công khai nhận định rằng tốc độ bất thường của kẻ tấn công có liên quan tới việc được AI hỗ trợ
  • Tuy nhiên, đánh giá này chỉ là phát biểu công khai, không phải kết luận pháp y chính thức
• Độ trễ từ phát hiện đến công bố được nhấn mạnh
  • Trong ít nhất một báo cáo công khai từ khách hàng, có dấu hiệu cho thấy khóa bị rò rỉ đã được phát hiện 9 ngày trước khi Vercel công bố
  • Trong các vụ xâm nhập nền tảng, độ trễ giữa phát hiện và thông báo được chỉ ra là một yếu tố rủi ro quan trọng
• Liên hệ với mô hình rộng hơn của năm 2026
  • Cùng với LiteLLM, Axios, Codecov và CircleCI, vụ việc này khớp với làn sóng chuỗi cung ứng nhắm vào thông tin xác thực được lưu bởi nhà phát triển

Dòng thời gian sự cố

• Khoảng tháng 2/2026, một nhân viên Context.ai bị nhiễm Lumma Stealer, làm rò rỉ thông tin xác thực doanh nghiệp, token phiên và token OAuth
• Khoảng tháng 3/2026, kẻ tấn công truy cập môi trường AWS của Context.ai và đánh cắp token OAuth dành cho người dùng tiêu dùng
  • Trong đó có token Google Workspace của một nhân viên Vercel
• Tháng 3/2026, tài khoản Google Workspace của một nhân viên Vercel bị truy cập bằng token OAuth bị đánh cắp
• Từ tháng 3 đến tháng 4/2026, sau khi di chuyển vào hệ thống nội bộ của Vercel, kẻ tấn công bắt đầu liệt kê các biến môi trường của khách hàng
• Khoảng tháng 4/2026, xuất hiện tuyên bố rằng tác nhân liên kết với ShinyHunters đã bắt đầu rao bán dữ liệu Vercel
• Ngày 10/4/2026, một khách hàng Vercel công khai đề cập việc nhận được thông báo từ OpenAI về khóa API bị rò rỉ
• Ngày 19/4/2026, Vercel đăng thông báo bảo mật và công bố thread trên X
• Sau ngày 19/4/2026, việc thông báo cho khách hàng, hướng dẫn xoay vòng thông tin xác thực và triển khai thay đổi trên dashboard được tiến hành
• Dù thời gian hiện diện tương đối ngắn khoảng 2 tháng, tốc độ từ việc vendor bên thứ ba bị nhiễm đến rò rỉ biến môi trường khách hàng vẫn được xác nhận
• Thời gian lưu mặc định của log kiểm toán OAuth trên Google Workspace là 6 tháng ở nhiều gói dịch vụ
  • Khoảng thời gian hiện diện gần 2 tháng lần này có khả năng vẫn nằm trong cửa sổ lưu trữ
  • Đồng thời cũng có chỉ ra rằng các vụ xâm nhập tương tự kéo dài hơn có thể vượt quá thời gian lưu mặc định

Chuỗi tấn công

• Giai đoạn 1: Xâm phạm OAuth bên thứ ba

  • Context.ai sở hữu một ứng dụng OAuth Google Workspace đã được nhân viên Vercel phê duyệt
  • Việc ứng dụng này bị xâm phạm được lần theo tới việc một nhân viên Context.ai bị nhiễm Lumma Stealer vào khoảng tháng 2/2026
  • Theo Hudson Rock và CyberScoop, nhân viên này được cho là đã bị nhiễm sau khi tải xuống một script exploit cho game Roblox
  • Với thông tin xác thực bị đánh cắp, kẻ tấn công đã truy cập môi trường AWS của Context.ai và làm rò rỉ token OAuth cho người dùng tiêu dùng của Context AI Office Suite, ra mắt vào tháng 6/2025
  • Context.ai thông báo đã phát hiện và chặn truy cập trái phép vào môi trường AWS trong tháng 3/2026
  • Tuy nhiên, công ty cũng nêu rõ rằng bản thân việc rò rỉ token OAuth không được nhận diện cho đến khi Vercel điều tra
  • Ứng dụng OAuth đã được phê duyệt có các đặc tính sau
    • Không cần mật khẩu người dùng
    • Có thể tiếp tục tồn tại ngay cả sau khi đổi mật khẩu
    • Thường có phạm vi quyền rộng đối với email, Drive, Calendar và hơn thế nữa
    • Hiếm khi được kiểm toán sau khi đã được phê duyệt ban đầu

• Giai đoạn 2: Chiếm đoạt tài khoản Workspace

  • Từ quyền truy cập vào ứng dụng OAuth đã bị xâm phạm, kẻ tấn công di chuyển sang tài khoản Google Workspace của một nhân viên Vercel
  • Qua đó, chúng có được khả năng truy cập email, tài liệu nội bộ trên Google Drive, khả năng nhìn thấy Calendar và tài nguyên liên kết, cũng như khả năng truy cập các dịch vụ khác có kết nối OAuth

• Giai đoạn 3: Truy cập hệ thống nội bộ

  • Từ tài khoản Workspace đã bị xâm phạm, kẻ tấn công tiếp tục di chuyển sâu hơn vào hệ thống nội bộ của Vercel
  • Rauch cho biết quá trình leo thang diễn ra thông qua một chuỗi thao tác bắt đầu từ tài khoản Google Workspace Vercel bị xâm phạm của một đồng nghiệp
  • Kỹ thuật di chuyển ngang cụ thể không được công bố
    • Tích hợp SSO
    • Thông tin xác thực thu thập từ email hoặc Drive
    • Các công cụ nội bộ khác được kết nối bằng OAuth
    • Chưa công bố là thuộc trường hợp nào ở trên

• Giai đoạn 4: Liệt kê biến môi trường

  • Kẻ tấn công đã truy cập được vào hệ thống nội bộ của Vercel với mức quyền đủ để liệt kê biến môi trường của các dự án khách hàng
  • Vercel cung cấp tính năng đánh dấu biến môi trường là “non-sensitive” khi lưu trữ
  • Theo các phát biểu công khai, không phải tất cả biến môi trường của khách hàng đều được bảo vệ theo cùng một cách, và việc liệt kê các biến không được đánh dấu là nhạy cảm đã giúp đạt được thêm quyền truy cập

• Giai đoạn 5: Khả năng lạm dụng dịch vụ hạ nguồn

  • Các biến môi trường bị lộ thường chứa thông tin xác thực của các dịch vụ hạ nguồn
  • Theo báo cáo công khai ngày 19/4/2026 của Andrey Zagoruiko, người này đã nhận được cảnh báo từ OpenAI về khóa bị rò rỉ vào ngày 10/4
  • Theo tuyên bố của người báo cáo, khóa đó không tồn tại ở đâu ngoài Vercel
  • Tình tiết này đặt ra khả năng rằng ít nhất một thông tin xác thực bị lộ đã bị phát hiện từ bên ngoài trước khi Vercel công bố

Khoảng trống 9 ngày tại thời điểm công bố

• Trong phần trả lời trên thread X ngày 19/4 của Guillermo Rauch, khách hàng Andrey Zagoruiko công khai việc đã nhận được thông báo của OpenAI về khóa bị rò rỉ vào ngày 10/4/2026
• Cơ chế phát hiện thông tin xác thực bị rò rỉ của OpenAI thường hoạt động khi chúng được tìm thấy tại các vị trí công khai như GitHub, các trang paste và tương tự
• Bài viết đánh giá rằng đường đi từ biến môi trường trên Vercel đến thông báo của OpenAI không hề đơn giản
• Xét theo mốc thời gian, tồn tại một cửa sổ 9 ngày giữa bằng chứng công khai sớm nhất về việc lộ thông tin và thời điểm Vercel công bố

• Khoảng trống 9 ngày này có ý nghĩa gì và không có ý nghĩa gì

  • Đây là một báo cáo công khai đơn lẻ, không phải kết quả pháp y đã được xác nhận
  • Không nên diễn giải đây là bằng chứng cho thấy Vercel đã biết về vụ xâm nhập từ ngày 10/4
  • Mặt khác, nó có ý nghĩa như một dấu hiệu cho thấy ít nhất một thông tin xác thực đã bị phát hiện từ bên ngoài trước khi khách hàng nhận được thông báo thay thế bí mật

• Hàm ý theo từng bên liên quan

  • Cơ quan quản lý
    • Theo GDPR, đồng hồ 72 giờ thông báo bắt đầu từ thời điểm bên kiểm soát nhận thức được vụ xâm nhập
    • Thời điểm Vercel nhận biết vụ việc đang nổi lên thành một điểm tranh luận công khai
  • Kiểm toán viên
    • Các đơn vị đánh giá SOC 2 và ISO 27001 có thể xem xét độ trễ phát hiện-thông báo như bằng chứng về giám sát liên tục
  • Khách hàng
    • Không thể giả định rằng cửa sổ lộ dữ liệu chỉ bắt đầu vào ngày 19/4
    • Bài viết cho rằng có khả năng việc lạm dụng tích cực đã diễn ra từ trước đó
  • Các cảnh báo thông tin xác thực bị rò rỉ do nhà cung cấp gửi đi đang trở nên quan trọng hơn như một kênh cảnh báo sớm
  • Bao gồm các ví dụ như OpenAI, Anthropic, GitHub, AWS và Stripe

Hoạt động tấn công được tăng tốc bằng AI

• Guillermo Rauch phát biểu trên X ngày 19 tháng 4 năm 2026 rằng ông rất nghi ngờ nhóm tấn công có mức độ tinh vi rất cao và đã được AI tăng tốc đáng kể
• Bài viết xem phát biểu này là đánh giá được ghi nhận công khai của CEO nền tảng bị ảnh hưởng và nhắc đến sự cần thiết phải xem xét một cách thận trọng

• Những dấu hiệu có thể kỳ vọng từ bằng chứng pháp y

  • Tốc độ liệt kê vượt quá tốc độ làm thủ công
    • Một phần có thể được giải thích chỉ bằng scripting
    • Trinh sát dựa trên LLM có thể song song hóa việc khám phá schema, thăm dò endpoint và nhận diện định dạng thông tin xác thực
  • Xây dựng truy vấn có nhận thức ngữ cảnh
    • Các truy vấn dường như biết thuật ngữ riêng của Vercel, project slug, tên mục tiêu triển khai và quy ước đặt tên env var ngay cả khi không có dấu hiệu trinh sát trước đó rõ ràng
  • Khả năng thích ứng khi xử lý lỗi
    • Việc thay đổi chiến lược sau lỗi API và rate limit linh hoạt hơn so với script tĩnh
  • Sản phẩm social engineering có vẻ được bản địa hóa
    • Câu dụ phishing, commit message và support ticket có chất lượng gần với ngữ cảnh địa phương hơn là bản dịch hay mẫu dựng sẵn

• Tầm quan trọng vượt ra ngoài sự cố Vercel

  • Bất kể đánh giá này có được duy trì trong quá trình pháp y chính thức hay không, phạm trù vận hành tấn công được AI tăng cường không còn chỉ là suy đoán thuần túy nữa
  • Trong công bố tháng 4 năm 2026, Microsoft đã ghi nhận các trường hợp device-code phishing dựa trên AI, sinh mã động, mồi nhử siêu cá nhân hóa và điều phối tự động hóa backend
  • Bài viết chỉ ra rằng các baseline telemetry được thiết kế theo chuẩn tốc độ của con người có thể tạo ra false negative trước các tác nhân vận hành được AI tăng tốc

• Hàm ý đối với kỹ thuật phát hiện

  • Nếu xảy ra hiện tượng nén liệt kê và di chuyển ngang, các quy tắc hiện có dựa trên ngưỡng thời gian lưu lại và tốc độ có thể cảnh báo thiếu
  • Cần xem xét lại các hạng mục sau
    • Tốc độ liệt kê tài nguyên duy nhất trên mỗi phiên
    • Đường cong phục hồi thành công so với lỗi
    • Mức độ đa dạng của mẫu truy vấn trong thời gian ngắn

Điểm yếu cốt lõi trong thiết kế biến môi trường

• Khía cạnh nghiêm trọng nhất trong bài viết không phải bản thân vector truy cập ban đầu mà là mô hình độ nhạy của biến môi trường của Vercel

• Cách biến môi trường của Vercel hoạt động vào thời điểm đó

  • Dự án chèn biến môi trường vào serverless function và quy trình build
  • Có cờ sensitive cho từng biến
  • Giá trị mặc định là non-sensitive
  • Sensitive cần được kích hoạt rõ ràng
  • Biến non-sensitive được hiển thị trên dashboard
  • Biến sensitive bị che sau khi tạo
  • Có thể truy cập qua API nội bộ với biến non-sensitive, còn sensitive thì bị hạn chế
  • Theo các phát biểu công khai, lưu trữ mã hóa không áp dụng cho non-sensitive, còn sensitive thì được áp dụng kèm các hạn chế bổ sung
  • Trong vụ xâm nhập này, đối tượng mà kẻ tấn công có thể truy cập được được đánh dấu là non-sensitive

• Lựa chọn thiết kế mang tính quyết định

  • Cờ sensitive bị tắt theo mặc định
  • Mọi DATABASE_URL, API_KEY, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY mà nhà phát triển không bật rõ ràng đều được lưu dưới dạng không mã hóa trong mô hình truy cập nội bộ của Vercel
  • Bài viết đánh giá rằng biện pháp kiểm soát bảo mật yêu cầu opt-in rõ ràng cho từng bí mật riêng lẻ, không có bảo vệ mặc định và guardrail, sẽ có tỷ lệ triển khai thực tế thấp

• Phản hồi của Vercel

  • Đã xác nhận triển khai cải tiến cho trang tổng quan biến môi trường và UI tạo/quản lý biến nhạy cảm
  • Có cải thiện về khả năng hiển thị, nhưng tính đến thời điểm bài viết chưa thay đổi giá trị mặc định
  • Vẫn cần opt-in cho từng biến
  • Việc có chuyển đổi mặc định hay không vẫn là câu hỏi công khai

• So sánh trong ngành

  • Ngành đang chuyển sang kho lưu trữ bí mật chuyên dụng như Vault, AWS Secrets Manager, Doppler và Infisical
  • Bài viết đánh giá rằng sự cố này củng cố lựa chọn kiến trúc quản lý bí mật chuyên dụng khi so với cách tiếp cận dựa trên biến môi trường của Vercel
  • Theo bảng so sánh
    • Vercel có mặc định non-sensitive, không có tự động phát hiện
    • AWS SSM Parameter Store hỗ trợ SecureString
    • HashiCorp Vault cung cấp mã hóa cho mọi bí mật và ACL
    • GitHub Actions che log cho mọi bí mật
    • Netlify dùng cách tiếp cận biến môi trường với secret toggle

Credential fan-out và rủi ro hạ nguồn

• Credential fan-out là hiện tượng một vụ xâm nhập trên một nền tảng dẫn đến việc phơi lộ dây chuyền sang mọi dịch vụ hạ nguồn được xác thực bằng các thông tin xác thực được lưu trên nền tảng đó
• Tổng hợp các mục thường có trong biến môi trường của dự án Vercel và tác động hạ nguồn
  • Cơ sở dữ liệu
    • DATABASE_URL, POSTGRES_PASSWORD
    • Khả năng truy cập toàn bộ dữ liệu
  • Cloud
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • Khả năng xâm nhập tài khoản cloud
  • Thanh toán
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • Rủi ro dữ liệu tài chính và gian lận hoàn tiền
  • Xác thực
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • Khả năng giả mạo phiên, chiếm đoạt tài khoản
  • Gửi mail
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • Khả năng phishing dựa trên domain đáng tin cậy
  • Giám sát
    • DATADOG_API_KEY, SENTRY_DSN
    • Khả năng thao túng telemetry
  • Mã nguồn và package
    • GITHUB_TOKEN, NPM_TOKEN
    • Khả năng chèn vào chuỗi cung ứng
  • AI/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • Khả năng lạm dụng API, phát sinh chi phí
• Một dự án Vercel đơn lẻ thường chứa 10~30 biến môi trường
• Ở quy mô tổ chức, danh mục 50 dự án có thể khiến 500~1.500 thông tin xác thực tồn tại trên nền tảng
• Dù bài viết cho biết chỉ có một phần nhỏ dự án khách hàng bị truy cập, mỗi thông tin xác thực bị lộ đều có thể trở thành điểm di chuyển sang một hệ thống riêng biệt khác
• Bài viết định nghĩa điểm này là không xem xâm nhập nền tảng như một sự cố bảo mật thông tin đơn thuần mà là hiệu ứng nhân bội lan rộng ra toàn bộ chuỗi cung ứng phần mềm

Quan hệ tin cậy OAuth và việc né tránh phòng thủ theo ranh giới

• Xâm nhập dựa trên OAuth né tránh nhiều biện pháp kiểm soát vốn dùng để phát hiện và chặn các cuộc tấn công truyền thống dựa trên thông tin xác thực
• Bài viết có câu nhắc đến khoảng 22 tháng, nhưng phần đính chính ở đầu đã sửa thời gian lưu lại thành khoảng 2 tháng
• Bài viết mô tả rằng các biện pháp kiểm soát phòng thủ mà đội ngũ bảo mật dựa vào ở cột bên trái trở nên vô nghĩa hoặc đã được thỏa mãn sẵn trong đường xâm nhập qua ứng dụng OAuth
• Chính sự bất đối xứng này khiến quản trị OAuth nổi lên như một lĩnh vực bảo mật tách biệt với IAM

• Quản trị OAuth là một chức năng rủi ro nhà cung cấp

  • Nhiều tổ chức coi việc phê duyệt OAuth là vấn đề self-service của nhà phát triển
  • Chỉ dừng ở việc phê duyệt công cụ cần thiết cho từng nhân viên với mức rà soát tập trung tối thiểu
  • Sự cố này được đưa ra như cơ sở để xem ứng dụng OAuth đã được phê duyệt là nhà cung cấp bên thứ ba có quyền truy cập thường trực
  • Cần thẩm định nhà cung cấp, tái phê duyệt định kỳ và giám sát việc sử dụng bất thường

Tuyên bố của tác nhân đe dọa và quy kết

• Tiền đề là các tuyên bố của tác nhân đe dọa trên các diễn đàn ngầm về bản chất rất khó tin cậy
• Thông tin ở đây được sắp xếp nhằm nhận diện và theo dõi, không phải là sự thật đã được xác nhận

• Tuyên bố liên quan đến ShinyHunters

  • Người đăng trên BreachForums tuyên bố có liên hệ với ShinyHunters và nói rằng đang nắm giữ dữ liệu của Vercel
  • Các hạng mục dữ liệu được tuyên bố gồm
    • khoảng 580 bản ghi nhân viên
    • kho lưu trữ mã nguồn
    • khóa API và token nội bộ
    • token GitHub và NPM
    • liên lạc nội bộ
    • quyền truy cập workspace Linear
  • Tất cả số lượng và phạm vi nêu trên đều chưa được kiểm chứng

• Các yếu tố khiến việc quy kết trở nên khó khăn

  • Thành viên ShinyHunters đã được biết đến phủ nhận liên quan với BleepingComputer
  • Có tuyên bố cho rằng đã có yêu cầu tiền chuộc 2 triệu USD qua Telegram
  • Thương hiệu ShinyHunters kể từ sau chiến dịch ban đầu đã bị nhiều tác nhân khác, hoặc không liên quan, sử dụng
  • Thông báo bảo mật của Vercel không nhắc đến các tuyên bố trên diễn đàn đó
  • Chuỗi bài của Rauch đề cập chuỗi tấn công nhưng không trực tiếp nói về bài đăng trên diễn đàn

• Lập trường của Vercel về đường phát hành chuỗi cung ứng

  • Rauch cho biết đã phân tích chuỗi cung ứng của Next.js, Turbopack và nhiều dự án mã nguồn mở, đồng thời nói với cộng đồng rằng chúng an toàn
  • Tại thời điểm viết bài, việc kiểm chứng độc lập vẫn đang diễn ra
  • Các tổ chức sử dụng Next.js, Turbopack và các mã nguồn mở khác của Vercel được khuyến nghị tiếp tục kiểm tra các tín hiệu toàn vẹn gói như checksum, chữ ký và provenance attestation
  • Do không có kiểm chứng độc lập đối với dữ liệu mà diễn đàn tuyên bố, cần xem đó là thông tin chưa được xác nhận
  • Đánh giá cho rằng chỉ riêng chuỗi tấn công dựa trên OAuth mà Vercel công bố cũng đã đủ để vụ việc có cơ sở kỹ thuật, và không nhất thiết phải có phạm vi truy cập rộng như người đăng diễn đàn tuyên bố

Ánh xạ MITRE ATT&CK

• Chuỗi tấn công đã được xác nhận có thể được ánh xạ tự nhiên vào các kỹ thuật MITRE ATT&CK hiện có
• Các mục ánh xạ
  • Initial Access / Trusted Relationship / T1199
    • Sử dụng ứng dụng OAuth của Context.ai như một bên thứ ba đáng tin cậy
  • Persistence / Application Access Token / T1550.001
    • Token OAuth vẫn tồn tại ngay cả sau khi đổi mật khẩu
  • Credential Access / Valid Accounts / T1078
    • Thông tin xác thực workspace của nhân viên bị xâm phạm
  • Discovery / Account Discovery / T1087
    • Liệt kê hệ thống nội bộ và dự án
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • Có thể truy cập biến môi trường non-sensitive
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • Khả năng sử dụng thông tin xác thực đám mây bị lộ
  • Collection / Data from Information Repositories / T1213
    • Liệt kê biến môi trường trên toàn bộ các dự án
• Điểm phát hiện có giá trị nhất trong ánh xạ này là giai đoạn chuyển từ quyền truy cập ứng dụng OAuth sang quyền truy cập hệ thống nội bộ
• Các tổ chức cần theo dõi hành vi bất thường của ứng dụng OAuth truy cập tài nguyên ngoài phạm vi kỳ vọng hoặc từ các dải IP không được dự kiến

Thế bao vây chuỗi cung ứng: LiteLLM, Axios, Vercel

• Sự cố Vercel không phải là một vụ việc đơn lẻ mà nằm trong làn sóng tấn công chuỗi cung ứng tập trung vào tháng 3~4 năm 2026
• Bài viết nêu rằng đây có thể là một chiến dịch phối hợp, hoặc theo cách diễn giải có khả năng cao hơn, là kết quả của việc nhiều kẻ tấn công cùng phát hiện ra một điểm yếu cấu trúc giống nhau: ranh giới tin cậy giữa kho gói, CI/CD, nhà cung cấp OAuth và nền tảng triển khai

• 24 tháng 3 năm 2026: Xâm phạm chuỗi cung ứng LiteLLM trên PyPI

  • Đăng các gói PyPI độc hại litellm 1.82.7, 1.82.8
  • Sử dụng thông tin xác thực triển khai CI/CD bị đánh cắp từ Trivy, trình quét lỗ hổng của Aqua Security
  • LiteLLM là proxy LLM có khoảng 3,4 triệu lượt tải mỗi ngày
  • Backdoor 3 giai đoạn nhắm vào hơn 50 loại thông tin xác thực trên các nhà cung cấp đám mây lớn
  • Bao gồm cơ chế duy trì Kubernetes DaemonSet
  • Thời gian lưu lại trước khi bị phát hiện và gỡ bỏ là khoảng 40 phút~3 giờ
  • CVE liên quan là CVE-2026-33634

• 31 tháng 3 năm 2026: Xâm phạm chuỗi cung ứng Axios trên npm

  • Gói npm axios có quy mô 70 triệu~100 triệu lượt tải mỗi tuần
  • Các phiên bản độc hại 1.14.1, 0.30.4 được phát hành sau khi tài khoản maintainer bị chiếm đoạt
  • Chèn phụ thuộc plain-crypto-js@4.2.1, bao gồm RAT đa nền tảng
  • Phát hiện 135 endpoint bị nhiễm đã liên lạc với C2 của kẻ tấn công
  • Thời gian lưu lại là 2~3 giờ
  • Microsoft quy kết vụ tấn công này cho tác nhân đe dọa được nhà nước Triều Tiên hậu thuẫn Sapphire Sleet

• Mẫu hội tụ

  • 3 vụ tấn công trong 3 tuần
  • Vector khác nhau
  • Mục tiêu chung là thông tin xác thực và bí mật mà nhà phát triển lưu trong toolchain
  • Tóm tắt trong bảng nêu ra như sau
    • LiteLLM: đánh cắp thông tin xác thực CI/CD → PyPI, thông tin xác thực nhà phát triển và khóa API, 40 phút~3 giờ
    • Axios: chiếm đoạt tài khoản maintainer → npm, RAT trên máy trạm nhà phát triển, 2~3 giờ
    • Vercel: xâm phạm ứng dụng OAuth → nền tảng, biến môi trường của khách hàng, bảng ghi khoảng 22 tháng nhưng phần đính chính phía trên và nội dung chính đã sửa thành khoảng 2 tháng

Mẫu hình chung với các vụ xâm phạm nền tảng trước đây

• Vụ xâm nhập Vercel gắn với một mẫu lặp lại, trong đó xâm phạm ở cấp nền tảng làm lộ bí mật của khách hàng

• Vụ xâm phạm Codecov Bash Uploader, tháng 1~4 năm 2021

  • Kẻ tấn công sửa đổi script Bash Uploader để làm rò rỉ biến môi trường trong môi trường CI của khách hàng
  • Không bị phát hiện trong khoảng 2 tháng
  • Có khả năng ảnh hưởng hơn 29.000 khách hàng, gồm Twitch, HashiCorp và Confluent
  • Điểm chung với Vercel là lộ biến môi trường khách hàng thông qua xâm phạm nền tảng

• Sự cố bảo mật CircleCI, tháng 1 năm 2023

  • Mã độc trên thiết bị cá nhân đánh cắp token phiên SSO của nhân viên
  • Sau khi truy cập hệ thống nội bộ, bí mật của khách hàng và khóa mã hóa đã bị rò rỉ
  • CircleCI khuyến nghị mọi khách hàng xoay vòng toàn bộ bí mật được lưu trên nền tảng
  • Cấu trúc gần như giống hệt Vercel
    • xâm phạm tài khoản nhân viên
    • truy cập hệ thống nội bộ
    • rò rỉ bí mật khách hàng

• Tấn công thông tin xác thực khách hàng Snowflake, tháng 5~6 năm 2024

  • UNC5537 sử dụng thông tin xác thực do infostealer thu được và các tài khoản không bật MFA
  • Ảnh hưởng hơn 165 tổ chức
  • Bao gồm Ticketmaster, Santander Bank và AT&T

• Vụ xâm phạm hệ thống hỗ trợ của Okta, tháng 10 năm 2023

  • Truy cập hệ thống quản lý case hỗ trợ khách hàng bằng thông tin xác thực bị đánh cắp
  • Xem token phiên trong các tệp HAR
  • Ảnh hưởng đến các khách hàng gồm Cloudflare, 1Password và BeyondTrust

• Tóm tắt mẫu hình

  • Truy cập ban đầu thông qua quan hệ tin cậy hoặc thông tin xác thực
  • Di chuyển ngang sang hệ thống nội bộ
  • Rò rỉ bí mật khách hàng
  • Phạm vi mục tiêu dao động từ một số mục tiêu cụ thể đến toàn bộ nền tảng
  • Bảng tóm tắt vector ban đầu, tài sản bị lộ và độ trễ phát hiện của từng sự cố
    • Codecov khoảng 2 tháng
    • Okta vài tuần
    • CircleCI vài tuần
    • Snowflake vài tháng
    • Vercel khoảng 2 tháng

Những điều vẫn chưa được công khai

• Dù đã có nhiều đưa tin công khai và phát biểu từ lãnh đạo, những khoảng trống then chốt vẫn còn tồn tại
• Các câu hỏi chưa được giải đáp trong hồ sơ công khai
  • Thời điểm Vercel lần đầu phát hiện hoạt động bất thường
  • Lý do cho khoảng cách 9 ngày giữa bằng chứng sớm nhất về việc lạm dụng thông tin xác thực được công khai và thời điểm công bố
  • Số lượng khách hàng bị ảnh hưởng
    • Rauch nói là “quite limited” nhưng không công bố con số cụ thể
  • Liệu các tuyên bố trên diễn đàn ShinyHunters có phải do cùng một kẻ tấn công đưa ra hay không
  • Tình trạng hiện tại của Context.ai và việc thông báo cho khách hàng hạ nguồn hay chưa
  • Toàn bộ phạm vi truy cập nội bộ của Vercel
    • số đội bị ảnh hưởng, số dự án, số biến môi trường đều chưa được công bố
    • ngoài biến môi trường của khách hàng, việc có truy cập vào các hệ thống nội bộ khác hay không cũng chưa được xác nhận
• Bài viết nhấn mạnh rằng để phân tích một cách nghiêm ngặt, cần không chỉ nêu các sự thật đã biết mà còn thừa nhận rõ ràng những gì chưa được công khai

Hướng dẫn phát hiện và săn tìm

• Hành động tức thì dành cho khách hàng Vercel

  • Cần kiểm tra toàn bộ biến môi trường của mọi dự án
  • Bài viết có kèm các ví dụ CLI sau
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • CLI hiện không trực tiếp hiển thị cờ sensitive, vì vậy cần kiểm tra qua dashboard hoặc API

• Tìm kiếm việc sử dụng trái phép các thông tin xác thực bị lộ

  • Tìm trong log kiểm toán của nhà cung cấp đám mây
    • AWS CloudTrail
      • Bộ lọc eventSource bao gồm sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
      • Tìm userIdentity.accessKeyId khớp với access key Vercel đã được xoay vòng
      • Phát hiện sourceIPAddress ngoài CIDR đã biết của tổ chức, userAgent như python-requests, curl, Go-http-client, hoặc các chuỗi tự động hóa lạ
      • Khoảng thời gian từ tháng 2 năm 2026 đến hiện tại
    • GCP Audit Logs
      • Tìm protoPayload.authenticationInfo.principalEmail của tài khoản dịch vụ dùng khóa được lưu trong Vercel
      • callerIp ngoài phạm vi đã biết
      • Kiểm tra các phương thức như storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create
    • Azure Activity Logs
      • Lọc theo application ID hoặc service principal từng có trong Vercel env vars
      • callerIpAddress ngoài phạm vi dự kiến
      • Ưu tiên kiểm tra Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write
  • Tìm trong log truy cập cơ sở dữ liệu
    • Mọi DB có chuỗi kết nối từng nằm trong biến môi trường Vercel
    • Phân tích toàn bộ khoảng thời gian từ tháng 2 đến tháng 4 năm 2026
    • Kiểm tra IP ngoài các phạm vi egress đã biết như Vercel edge IP, VPN, văn phòng
    • Phát hiện các kết nối dùng thông tin xác thực bị lộ ngoài cửa sổ triển khai bình thường
    • Với PostgreSQL, dùng pg_stat_activity, log_connections
    • Với MySQL, dùng general log hoặc audit plugin
    • Với MongoDB Atlas, kiểm tra các sự kiện DATA_EXPLORER, CONNECT trong Project Activity Feed
  • Tìm trong log xử lý thanh toán
    • Stripe Dashboard → Developers → Logs
    • source_ip ngoài các máy chủ dự kiến
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • Kiểm tra log tương đương của Braintree, Adyen
    • Ưu tiên các API key được lưu trong non-sensitive env var mà chưa được xoay vòng
    • Cũng cần kiểm tra các đợt gửi bất thường trong log dịch vụ gửi email
  • Cần kiểm tra thông báo rò rỉ thông tin xác thực không tự nguyện từ OpenAI, Anthropic, GitHub, AWS, Stripe, v.v.

• Cần xoay vòng và tái triển khai đồng thời

  • Theo tài liệu Vercel, chỉ xoay vòng biến môi trường sẽ không vô hiệu hóa giá trị thông tin xác thực cũ trong các bản triển khai trước đó
  • Các bản triển khai cũ sẽ tiếp tục dùng thông tin xác thực cũ cho đến khi được tái triển khai
  • Vì vậy, mọi lần xoay vòng đều cần tái triển khai tất cả môi trường dùng biến đó hoặc vô hiệu hóa rõ ràng các bản triển khai cũ
  • Thứ tự ưu tiên như sau
    • Thông tin xác thực của nhà cung cấp đám mây
    • Chuỗi kết nối cơ sở dữ liệu
    • Khóa xử lý thanh toán
    • Bí mật xác thực
    • API key của bên thứ ba
    • Token giám sát và ghi log

• Ứng phó chủ động dành cho đội bảo mật

  • Trong Google Workspace Admin Console → Security → API Controls → Third-party app access, rà soát toàn bộ ứng dụng OAuth đã được phê duyệt
  • Đánh dấu các ứng dụng có scope rộng như Drive, Gmail, Calendar
  • Điều tra các ứng dụng của nhà cung cấp không còn quan hệ kinh doanh đang hoạt động
  • Giám sát việc sử dụng OAuth token từ các dải IP ngoài phạm vi dự kiến
  • Cần tìm kiếm OAuth Client ID độc hại đã biết
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Logic phát hiện SIEM

• Dấu hiệu bất thường của ứng dụng OAuth, giai đoạn 1~2

  • Cảnh báo ngay lập tức với các sự kiện refresh token hoặc authorization liên quan đến OAuth Client ID độc hại đã biết
  • Đối chiếu các sự kiện cấp quyền scope rộng như toàn quyền truy cập mail, đọc/ghi Drive, truy cập calendar với danh sách nhà cung cấp hiện tại
  • Các ứng dụng không còn được dùng cho hoạt động kinh doanh phải thuộc diện thu hồi
  • Nếu việc dùng token của ứng dụng OAuth đã được phê duyệt phát sinh từ IP ngoài phạm vi CIDR dự kiến của doanh nghiệp và nhà cung cấp, cần điều tra

• Truy cập hệ thống nội bộ và di chuyển ngang, giai đoạn 3

  • Sự kiện xác thực SSO/SAML bất thường
    • Trường hợp tài khoản Workspace bị xâm phạm đăng nhập vào ứng dụng nội bộ từ IP, khu vực hoặc dấu vân tay thiết bị chưa từng thấy
  • Thu thập thông tin xác thực qua email và Drive
    • Tìm kiếm hàng loạt các từ khóa như API key, secret, token, password, .env
    • Truy cập kho lưu trữ thông tin xác thực dùng chung, runbook kỹ thuật và tài liệu hạ tầng
    • Tạo quy tắc chuyển tiếp email
  • Truy cập công cụ nội bộ qua kết nối OAuth
    • Tạo phiên hoặc hoạt động API trên Slack, Jira, GitHub, dashboard nội bộ, v.v. vào thời điểm hoặc từ hạ tầng khác thường
  • Cố gắng leo thang đặc quyền
    • Tham gia nhóm hoặc vai trò mới
    • Truy cập admin console vốn không dùng
    • Giám sát các lệnh gọi Directory API của Google Workspace, thay đổi ủy quyền, hoặc nỗ lực liệt kê OAuth token của người dùng khác

• Liệt kê biến môi trường, giai đoạn 4

  • Phát hiện các mẫu bất thường về khối lượng và tần suất lớn của các lệnh gọi kiểu env read, list, decrypt trong log kiểm toán đội Vercel
  • Trước tiên cần thiết lập baseline cho thời điểm build CI/CD bình thường
  • Sau đó cảnh báo các truy cập có khối lượng, thời điểm hoặc chủ thể nguồn lệch khỏi baseline
  • Chú ý đến truy cập từ tài khoản người dùng thay vì service account, hoặc từ tài khoản trước đây không tương tác với dự án đó

• Lạm dụng thông tin xác thực ở hệ thống hạ nguồn, giai đoạn 5

  • Trong khoảng thời gian tháng 2 đến tháng 4 năm 2026, kiểm tra log của mọi dịch vụ đích có thông tin xác thực từng được lưu trong non-sensitive Vercel environment variables
  • Với AWS, tìm trong CloudTrail theo access key ID cụ thể
  • Với GCP và Azure, tìm log kiểm toán theo service account hoặc application ID
  • Với các SaaS API như Stripe, OpenAI, Anthropic, SendGrid, Twilio, kiểm tra trên dashboard hoặc API log xem có sử dụng từ IP không nhận diện được hoặc vào khung giờ không hoạt động hay không
  • Bất kỳ hoạt động sử dụng nào không thể quy về hạ tầng của chính bạn phải được coi ngay là thông tin xác thực đã bị xâm phạm, cần xoay vòng và điều tra hành vi

• Cảnh báo rò rỉ thông tin xác thực từ bên thứ ba

  • Cần theo dõi các cảnh báo quét bí mật tự động như GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud
  • Cảnh báo đối với khóa chỉ từng tồn tại trên nền tảng triển khai không phải là cảnh báo vệ sinh đơn thuần mà cần được xem là chỉ dấu xâm phạm nền tảng

Quy trình săn tìm mối đe dọa thủ công

• Tìm kiếm thủ công trong Google Workspace Admin Console

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai hoặc Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Khoảng thời gian từ tháng 2 năm 2026 đến nay
  • Nếu có kết quả, cần thu hồi quyền ngay lập tức và điều tra sự cố

• Kiểm tra ứng dụng OAuth bên thứ ba có phạm vi quyền rộng

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • Sắp xếp các ứng dụng có App access là Unrestricted
  • Các mục cần kiểm tra với từng ứng dụng
    • Có tồn tại quan hệ với nhà cung cấp đang hoạt động hay không
    • Tính chính đáng về mặt nghiệp vụ của phạm vi quyền
    • Ngày sử dụng gần nhất
  • Các ứng dụng không được sử dụng trong hơn 90 ngày là đối tượng cần thu hồi

Khuyến nghị phòng vệ

• Hành động ngay, 0~48 giờ

  • Xoay vòng tất cả biến môi trường Vercel không được đánh dấu là sensitive
  • Triển khai lại toàn bộ môi trường sau khi xoay vòng
  • Bật cờ sensitive cho mọi biến môi trường chứa thông tin xác thực, token, khóa và secret
  • Kiểm tra nhật ký phê duyệt ứng dụng OAuth trong bảng điều khiển quản trị Google Workspace hoặc Microsoft Entra
  • Thu hồi quyền truy cập của các ứng dụng không còn được sử dụng tích cực
  • Rà soát nhật ký truy cập của mọi dịch vụ đã dùng thông tin xác thực từng được lưu trong biến môi trường Vercel, trong giai đoạn từ tháng 2 năm 2026 đến nay

• Tăng cường ngắn hạn, 1~4 tuần

  • Chuyển sang dùng trình quản lý bí mật chuyên dụng như HashiCorp Vault, AWS Secrets Manager, Doppler, Infisical
  • Dùng phương thức inject lúc runtime thay vì lưu trong biến môi trường của nền tảng
  • Ở những nơi được hỗ trợ, loại bỏ thông tin xác thực dài hạn bằng xác thực dựa trên OIDC
  • Triển khai giám sát ứng dụng OAuth
    • Nudge Security, Grip Security, Valence Security hoặc các tính năng quản trị mặc định của Google Workspace
  • Xây dựng tự động hóa xoay vòng thông tin xác thực
    • Đề xuất chu kỳ 30~90 ngày
  • Đưa phê duyệt OAuth vào kiểm kê rủi ro bên thứ ba như với các nhà cung cấp theo hợp đồng

• Thay đổi mang tính cấu trúc, 1~6 tháng

  • Áp dụng tư thế Zero Trust đối với biến môi trường
    • Giả định rằng mọi bí mật được lưu trên nền tảng triển khai đều có thể bị lộ nếu nền tảng bị xâm nhập
  • Áp dụng phạm vi đặc quyền tối thiểu
    • Quyền tối thiểu cho tài khoản DB
    • Giới hạn phạm vi thao tác của API key
    • Với thông tin xác thực đám mây, dùng thông tin xác thực tạm thời dựa trên vai trò thay cho access key dài hạn
  • Thực hiện đánh giá bảo mật bên thứ ba và tái đánh giá định kỳ với mọi ứng dụng OAuth và tích hợp truy cập vào hệ thống danh tính doanh nghiệp
  • Đưa nền tảng PaaS vào kiểm kê SBOM/ASPM
    • Cần coi đây không phải là dịch vụ bên ngoài mà là phụ thuộc chuỗi cung ứng hạng nhất

• Giám sát được khuyến nghị

  • Kiểm tra Client ID OAuth nói trên trong Google Workspace Admin Console
  • Giám sát các lệnh gọi API env.read, env.list bất ngờ trong nhật ký kiểm toán của Vercel
  • Kiểm tra trong CloudTrail, GCP Audit Logs, Azure Activity Logs xem có việc sử dụng IP hoặc user agent bất thường đối với thông tin xác thực được lưu trong biến môi trường Vercel trong giai đoạn tháng 2~4 năm 2026 hay không
  • Nếu cây phụ thuộc có LiteLLM hoặc Axios, hãy cùng giám sát các IOC được nêu trong từng khuyến nghị
  • Theo dõi cảnh báo về thông tin xác thực bị rò rỉ ngoài ý muốn từ các nhà cung cấp API chính trong thời gian phơi lộ

Tác động về quy định và tuân thủ

• Các tổ chức có thể đã bị lộ thông tin xác thực do vụ xâm nhập này cần đánh giá các nghĩa vụ sau

• GDPR

  • Nếu thông tin xác thực bị lộ cho phép truy cập vào các hệ thống có dữ liệu cá nhân của EU, mốc thời gian thông báo 72 giờ có thể bắt đầu từ thời điểm xác nhận phơi lộ
  • Thông báo của OpenAI ngày 10 tháng 4 đặt ra câu hỏi liệu thời điểm nhận biết của một số tổ chức có thể sớm hơn mốc công khai ngày 19 tháng 4 hay không

• CCPA/CPRA

  • Việc lộ thông tin xác thực cấp quyền truy cập dữ liệu người tiêu dùng có thể kích hoạt nghĩa vụ thông báo

• PCI DSS

  • Nếu lộ thông tin xác thực xử lý thanh toán như Stripe, Braintree, Adyen, có thể phát sinh yêu cầu về quy trình ứng phó sự cố và điều tra pháp chứng

• SOC 2

  • Cần phản ánh hồ sơ sự cố, hành động xoay vòng thông tin xác thực và các kiểm soát đã cập nhật vào bằng chứng giám sát liên tục

• SEC Cybersecurity Rules 8-K

  • Các công ty niêm yết đánh giá là trọng yếu có nghĩa vụ công bố trong vòng 4 ngày làm việc
  • Bài viết chỉ ra rằng ngay cả khi chưa biết liệu đã có hành vi sử dụng truy cập trái phép thực tế hay chưa, nhiều khung quy định vẫn có thể vận hành dựa trên bản thân việc phơi lộ, chứ không phải việc xác nhận bị khai thác

Chỉ dấu xâm nhập

• IoC đã được xác nhận

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Giá trị liên kết với ứng dụng OAuth Context.ai đã bị xâm phạm

[GN⁺]

Ý kiến trên Hacker News

• Điều này khiến tôi nhớ lại thời điểm Vercel lần đầu đưa ra UI cho biến môi trường thì thậm chí còn chưa có tùy chọn sensitive. Phải mất gần hơn 2 năm tính năng đó mới xuất hiện. Các thảo luận liên quan vẫn còn trong GitHub discussion và Vercel changelog

  • Theo tôi, ngay cả khi gắn cờ sensitive trong UI thì runtime cũng không thay đổi. Một khi nó đã vào process.env ở thời điểm build, bất kỳ dependency nào muốn quét đều có thể đọc được. Vấn đề thực sự là cấu trúc dồn mọi secret vào một túi env duy nhất rồi chuyển nguyên gói cho công cụ build. Cloudflare với scoped bindings hay Fly đã tách biệt từ lâu, còn các nền tảng khác thì có vẻ chậm hơn
  • Tôi cho rằng sensitive không có nghĩa là không thể đọc được, mà chỉ mang ý nghĩa không hiển thị trên UI. Chỉ cần trả về props hơi quá tay trong action function hay route là cũng có thể rò rỉ dễ dàng. Muốn chặn kiểu vấn đề này thì cuối cùng vẫn phải mã hóa giá trị môi trường bằng khóa riêng của mình, và vì không có nhiều cách để tách biệt nên cũng có thể lách bằng cách baked-in một số secret vào source. Khi đó kẻ tấn công không chỉ cần đọc giá trị môi trường mà còn phải tải artifact build xuống để tìm cả khóa giải mã, nên rào cản sẽ cao hơn một chút. Không lý tưởng nhưng có vẻ vẫn dùng được như biện pháp tạm thời

• Vụ này thực sự tạo cảm giác như một sự cố đáng xấu hổ. Nếu đúng như trích dẫn, việc Lumma Stealer lây nhiễm bắt đầu từ chuyện một nhân viên Context.ai tải về Roblox exploit script thì càng khó đỡ hơn

• Đoạn CEO công khai quy cho việc kẻ tấn công di chuyển nhanh là do kỹ thuật tấn công được AI tăng tốc, theo tôi gần như không thấy có căn cứ gì. Vì vậy tôi có cảm giác thực tế cũng chẳng lộ ra thêm bao nhiêu thông tin

  • Dạo này AI dường như còn đang làm rung chuyển cả thị trường ngụy biện nhảm nhí, và báo chí thì có vẻ cứ lặp lại điều đó mà không kiểm chứng
  • Mặt khác, điều này cũng khiến tôi nhớ đến việc các giải pháp vibe coded thường hay khuyến nghị Vercel. Cảm giác khá giống với làn sóng ngày xưa cái gì cũng khuyên dùng Axios

• Tôi không thật sự hiểu phần giải thích về Stage 2. Nếu ứng dụng ContextAI yêu cầu toàn bộ các quyền như Google mail, drive, calendar thì tôi thấy là quá mức. Đây đâu phải công ty nhỏ, nên thật khó tin là họ lại đồng ý chạy thứ như vậy ngoài môi trường của chính mình. Dù vậy, đọc bài cập nhật bảo mật của Context.ai thì có vẻ như một nhân viên Vercel đã tự mình cấp quyền truy cập toàn bộ Google Workspace cá nhân của họ

• Tôi vẫn chưa hình dung rõ luồng này vận hành chính xác ra sao. Tôi tự hỏi OAuth token ở đây có phải là token nhận được sau Sign in with Google hay không. Bình thường thứ đó chẳng phải sẽ gắn với client id và client secret của một Google App cụ thể sao. Dù kẻ tấn công có biết OAuth token của người dùng và cả thông tin client thì tôi vẫn hiểu được phần truy cập Drive v.v., nhưng từ đó làm sao lại dẫn đến đăng nhập vào control plane của Vercel thì tôi chưa thấy thuyết phục. Không biết rốt cuộc họ tìm được thông tin xác thực trong Google Drive hay sao

  • Tôi thấy báo cáo không nói rõ phần đó. Vì vậy lại càng khiến người ta đoán rằng có thể đã có một sai lầm đáng xấu hổ nào đó hơn nữa và họ đang che đi. Có thể là mật khẩu nằm trong Drive hay Gmail, hoặc như một bình luận khác nói, có thể là passwordless login link
  • Sau khi hoàn tất quy trình OAuth thì cuối cùng bạn vẫn nhận được session token, và có thể dùng nó để gửi request API. Có vẻ điểm mấu chốt là token được cấp nhiều khả năng còn có quyền truy cập inbox của nạn nhân, và kẻ tấn công đã đọc email để lấy mật khẩu dùng một lần, magic link hoặc thông tin nhạy cảm khác
  • Tôi cũng thấy rối. Tôi muốn biết liệu có phải ứng dụng OAuth của Context.ai thật sự bị xâm phạm, và vì thế kẻ tấn công cũng có được đúng mức độ hiển thị vào mọi workspace khách hàng mà Context.ai đang thấy hay không. Nhưng nếu vậy thì tại sao trách nhiệm lại dồn vào đúng một nhân viên cụ thể. Có vẻ điểm cốt lõi là nhân viên Vercel đó có cấp quyền cho Context.ai đọc toàn bộ workspace của Vercel hay không

• Tôi đồng ý với nhận định rằng “cần đối xử với ứng dụng OAuth như nhà cung cấp bên thứ ba, loại bỏ secret nền tảng dài hạn, và thiết kế với giả định provider-side compromise”, nhưng cũng cảm thấy việc thiết kế trên giả định phía nhà cung cấp bị xâm phạm là thật sự rất khó. Ngay từ đầu niềm tin đã là điểm xuất phát của hệ thống rồi

  • Vì chúng tôi cũng đang đau đầu về ứng dụng OAuth trong SaaS của mình nên tôi càng thấy đây là bài toán cực khó. Tôi cũng tự hỏi liệu có marketplace nào giải quyết tốt chuyện này không. Sau sự cố Salesloft, Cloudflare từng đề xuất proxy toàn bộ OAuth và lưu lượng API bên thứ ba qua họ, nhưng điều đó cũng giống như chuyển vector đe dọa sang chỗ khác. Ngoài các nguyên tắc cơ bản như tối thiểu hóa scope, rút ngắn thời hạn, xoay client secret, tôi cũng không rõ còn có thể làm thêm gì. Chỉ nghĩ ra allowlist IP nguồn request theo từng client
  • Nhìn các trường hợp như vậy, tôi có cảm giác zero-trust từ trước đến nay phần lớn chỉ là ngôn ngữ marketing. Nếu thật sự là security by design thì ngay từ đầu phải đưa giả định rằng nhà cung cấp ở tầng trên có thể bị xuyên thủng hoàn toàn bởi tấn công chuỗi cung ứng

• Tôi nghĩ những sự cố kiểu này rồi sẽ xuất hiện nhiều hơn rất nhiều. Dù là tập đoàn lớn hay công ty nhỏ, toàn bộ nền kinh tế IT giờ đang muộn màng hứng chịu nợ rủi ro từ việc thử nghiệm rộng rãi các công cụ AI. Vì vậy tôi đọc vụ này không phải như “AI-enabled tradecraft”, mà là hệ quả của việc lãnh đạo công ty lấy lý do tốc độ để ép cả tổ chức cài đặt và thử nghiệm công cụ AI. Bản thân kiểu tấn công này quá đỗi bình thường, và hầu như công ty nào không có allowlist bắt buộc cho cài đặt AI đều đang phơi bày rủi ro. Nếu hỏi bộ phận IT xem các công cụ như Context đang được cài ở local và toàn bộ SaaS nhiều đến mức nào thì có lẽ con số sẽ khá lớn. Vấn đề là các công cụ này trên thực tế có quyền truy cập vào gần như mọi thứ, còn hệ sinh thái vendor bảo mật hay RBAC để kiểm soát chúng thì có lẽ phải 18~24 tháng nữa mới thực sự thành hình. Vercel trông giống như chim hoàng yến trong mỏ than, và tôi không tin chỉ riêng Context là bị nhắm tới. Đây có vẻ là một vector đe dọa đã được biết đến nhưng bị phớt lờ, kiểu chỉ cần một nơi vỡ ra là những nơi khác cũng sẽ lộ theo dây chuyền. 6 tháng tới có thể sẽ đặc biệt khó khăn, và mọi người либо đang audit tình trạng cài đặt AI ngay bây giờ, либо nên làm điều đó, trong khi kẻ tấn công sẽ tranh thủ di chuyển bằng quyền truy cập chúng đang có trước khi bị chặn. Nhân tiện, tôi là người phụ trách an ninh trong ngành tech

  • Tôi cũng đã nói vài năm nay rằng sẽ còn nhiều sự cố bảo mật kỳ quái lên mặt báo
  • Tôi cũng nhìn nhận như vậy. Cảm giác đây là một giai đoạn khá đáng chú ý đang mở ra

• Nhìn bản tóm tắt kiểu “quan hệ tin cậy OAuth lan thành lộ toàn bộ nền tảng, CEO đổ tốc độ tấn công cho AI, và độ trễ từ phát hiện đến công bố cũng gây nghi vấn”, với tôi những thất bại cốt lõi hiện ra rất điển hình. Có một tài khoản người dùng với quyền quá mức, và có thể còn nhiều tài khoản tương tự khác. Nhiều khả năng cũng không có 2FA hay ZeroTrust, hoặc chỉ áp dụng rất hạn chế. Tổng thể vệ sinh bảo mật cũng không được tốt

  • Tôi nghĩ sắp tới việc đổ lỗi cho AI sẽ trở thành một kiểu cái cớ vạn năng cho sự cố bảo mật, giống như trước đây website cứ sập là đổ cho DDoS

• Có một điểm mà mọi người hay bỏ sót. Trên Vercel, ngay cả khi rotate biến môi trường thì các bản deploy cũ cũng không tự động bị vô hiệu hóa, nên deploy trước đó vẫn tiếp tục chạy bằng thông tin xác thực cũ cho tới khi redeploy hoặc xóa đi. Vì vậy kể cả đã thay khóa sau thông báo, nếu chưa redeploy lại toàn bộ thì các giá trị bị lộ vẫn có thể còn sống. Và tôi nghĩ cũng nên kiểm tra luôn các mục cấp quyền OAuth trong Google Workspace. Vào Admin Console > Security > API Controls > Third-party app access sẽ thấy có khả năng một ứng dụng từng được phê duyệt cho buổi demo 2 năm trước vẫn đang giữ quyền toàn bộ Mail và Drive

  • Vì lý do này mà chúng tôi tách riêng nhiều tài khoản Google. Nhưng nhiều tổ chức không làm được vậy vì chi phí Google Workspace tính theo từng người dùng. Ở công ty cũ tôi cũng từng đề xuất cấp các quyền OAuth kiểu này bằng tài khoản riêng thay vì tài khoản chính, nhưng đã không thành công
  • Thông thường nói đến credential rotation thì tôi nghĩ phải bao gồm cả vô hiệu hóa thông tin xác thực cũ. Cách chỉ tạo cái mới rồi để cái cũ tiếp tục sống thì tôi gần như chưa từng nghe thấy
  • Câu đó trong báo cáo cũng làm tôi khá bối rối. Việc deploy cũ dùng env var cũ tự nó không quyết định thông tin xác thực đó còn hiệu lực hay không. Tôi thấy đây gần với một footgun ảnh hưởng đến tính sẵn sàng hơn là tính bí mật. Phần “Environment variable enumeration (Stage 4)” trong báo cáo cũng đọc khá lạ. Đặc biệt đoạn “hãy xem có truy cập biến môi trường từ user account thay vì service account, hoặc từ account vốn không tương tác với dự án đó hay không”, làm tôi ngạc nhiên rằng chẳng lẽ mọi người thực sự đang lấy credential từ env var của Vercel để đem dùng ở hệ thống khác sao
  • Preview deploy còn nghiêm trọng hơn. Mỗi PR lại sinh ra một cái dùng cùng env var, và chẳng ai dọn dẹp chúng. Dù bạn có xoay khóa và redeploy prod, vẫn có thể còn hàng trăm preview zombie chứa giá trị cũ
  • Khi rotation thì dĩ nhiên phải làm hết hạn biến cũ nữa

• Một số chi tiết trong báo cáo này, đặc biệt là mốc thời gian bắt đầu từ 2024~2025, khiến tôi cảm giác đó không phải thông tin được đưa tin rộng rãi ở nơi khác. Ví dụ như “cuối 2024 đến đầu 2025 kẻ tấn công pivot từ quyền truy cập OAuth của Context.ai sang tài khoản Google Workspace của nhân viên Vercel”, hay “đầu đến giữa 2025 bắt đầu truy cập hệ thống nội bộ Vercel và liệt kê biến môi trường khách hàng”, tôi tự hỏi những ngày tháng đó lấy từ đâu ra

  • Theo tôi thì toàn bộ những mốc đó đều là nội dung bịa ra, rất có thể là hallucination