OAuth ของ AI ตัวเดียว ทำ Vercel แตก env vars ลูกค้าหลุดเป็นกอง
ถ้าคุณ deploy (เอาโค้ดขึ้นใช้งานจริง) โปรเจกต์ไว้บน Vercel แล้วไม่เคยกด sensitive ตอนใส่ API key ข่าวนี้กระทบคุณตรงๆ
เมื่อวันที่ 19 เมษายน 2026 Vercel ออกมายอมรับว่าระบบภายในโดนเจาะ คนร้ายเข้าไปได้ถึง environment variables ของลูกค้าบางส่วน ที่หลุดมีทั้ง API key, database password, OAuth token ของโปรเจกต์ที่ฝากไว้ในแพลตฟอร์ม
ที่แสบกว่านั้นคือ Vercel ไม่ได้โดนแฮกตรงๆ คนร้ายเดินผ่าน OAuth ของ AI tool ตัวหนึ่งชื่อ Context.ai เข้าไปในบัญชี Google Workspace ของพนักงาน Vercel แล้วค่อยไต่เข้า production ของบริษัท
สรุปสั้นๆ ใครโดน ใครต้องทำอะไร
Vercel บอกเองว่าลูกค้าที่ได้รับผลกระทบเป็น "limited subset" คือไม่ใช่ทุกคน แต่ก็ไม่บอกตัวเลขว่ากี่ราย ใครอยู่ในกลุ่มนั้นจะได้รับการแจ้งโดยตรงจาก Vercel
ถ้าคุณเป็น dev ที่ใช้ Vercel ตอนนี้ทำสามอย่างนี้ก่อน เปิด MFA ทุกบัญชีให้ครบ หมุน env vars ที่ไม่ได้ติด sensitive flag ทันที และเข้าไปดู audit log ว่ามีคนเข้ามาทำอะไรแปลกๆ ในโปรเจกต์ไหม
คนที่ไม่ได้ใช้ Vercel โดยตรงก็เกี่ยวนะ เพราะ pattern ของการเจาะแบบนี้ใช้ได้กับทุกแพลตฟอร์มที่คุณ grant OAuth ให้ tool ภายนอก
เรื่องเริ่มที่ Context.ai ไม่ใช่ Vercel
นี่คือจุดที่น่าสนใจที่สุดของเคสนี้ Vercel ไม่ได้โดน zero-day ไม่ได้ถูก phish พนักงานตรงๆ ไม่มีใครทิ้ง credentials ไว้ใน GitHub
คนร้ายเริ่มจากการเจาะ Context.ai ซึ่งเป็น AI platform ที่ผู้ใช้เชื่อมต่อกับ Google Workspace ผ่าน OAuth (ระบบให้สิทธิ์เข้าถึงบัญชีโดยไม่ต้องบอก password) ทันทีที่ Context.ai ถูกควบคุม คนร้ายก็ใช้สิทธิ์ OAuth ที่พนักงาน Vercel เคยกดอนุญาตไว้ เข้าไปอ่าน Google Workspace ของคนนั้นได้เลย
จากตรงนั้นก็ lateral movement ตามตำรา CEO Guillermo Rauch อธิบายว่าคนร้าย "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems" คือไม่ได้สุ่มเดิน รู้ดีว่าจะไปไหน
analogy ที่อธิบายได้ดีที่สุดคือ คุณให้กุญแจบ้านกับคนเดินสุนัข แล้วคนเดินสุนัขเอาไปทำสำเนาให้ผู้ช่วย ผู้ช่วยทำหายไว้ที่บาร์ โจรไม่ได้แงะกุญแจคุณ มันแค่เดินเข้าบ้านด้วยกุญแจของจริง ที่คุณให้คนที่คุณไว้ใจ
Sensitive flag คือคันโยกที่ไม่มีใครจำได้ว่าต้องดึง
ใน Vercel ตอนใส่ env var คุณจะมีตัวเลือกเล็กๆ ที่ติ๊กได้ว่าตัวนี้เป็น sensitive ไหม ถ้าติ๊ก ระบบ encrypt at rest ให้ ถ้าไม่ติ๊ก ระบบเก็บเป็น plaintext
Default คือไม่ติ๊ก
คุณคงเดาผลของ default นี้ออกแล้ว เวลาคนร้ายเข้าไปอยู่ใน internal system ของ Vercel ได้ env vars ที่ติด sensitive flag คือกล่องที่ล็อกกุญแจไว้ Vercel เช็กแล้วบอกว่าไม่มีหลักฐานว่าโดนเปิด ส่วน env vars ที่ไม่ติด sensitive คืออ่านได้ตรงๆ เลย
ลองคิดดู ตอนคุณใส่ DATABASE_URL หรือ STRIPE_SECRET_KEY ครั้งล่าสุด คุณกด sensitive ไหมล่ะ ผมเองยอมรับว่าใส่แบบเร่งๆ ไม่กี่ครั้งก็ลืม กดบ้างไม่กดบ้าง เพราะ default เป็น off ก็แปลว่าต้องคิดเองทุกครั้ง
design choice แบบนี้แหละที่กลายเป็น attack amplifier UI เล็กๆ ที่ดู optional กลับเป็นตัวกำหนดว่าวันที่บริษัทโดนแฮก ลูกค้าจะหลุดแค่ไหน
ข่าวดีคือหลังเหตุการณ์นี้ Vercel เปลี่ยน default แล้ว env vars ใหม่ที่สร้างขึ้นมาจะเป็น sensitive โดยอัตโนมัติ ข่าวร้ายคือของเก่าที่คุณใส่ไว้แล้ว ยังเป็นแบบเดิม ต้องไปกดเปิดเองนะ
Vercel ยืนยันว่าสามอย่างนี้ปลอดภัย
เพื่อตัด FUD ก่อน Vercel บอกชัดว่าสามอย่างนี้ไม่ถูกแตะ
หนึ่ง npm packages ที่ Vercel ดูแลไม่มีการแก้ไข supply chain ฝั่งนั้นยังสะอาด คนที่ใช้ Next.js หรือ package อื่นของ Vercel ผ่าน npm ไม่ต้องกังวลว่ามีโค้ดแปลกแฝงเข้ามาในเวอร์ชันใหม่
สอง GitHub repositories ของ Vercel ไม่มีร่องรอยถูกแก้ไข source code ของ open source projects ยังเป็นของเดิม
สาม collaboration กับ Microsoft (เช่น integrations ระดับ enterprise) ไม่ถูกกระทบ
แล้วก็ deployments, builds, runtime ของลูกค้าก็ไม่ได้ down ไม่มีหลักฐานว่าโค้ดที่คุณ deploy ไปแล้วถูกแก้
มีคนอ้างเป็น ShinyHunters แต่ของจริงรึเปล่ายังไม่แน่
BleepingComputer รายงานว่ามีคนโพสต์อ้างว่าเป็น affiliate ของกลุ่ม ShinyHunters พร้อมเสนอขายของหลายอย่าง ทั้ง access keys, source code, database data, internal deployment access ไปจนถึง NPM และ GitHub tokens
ตัวเลขที่อ้างคือ 580 employee records พร้อม dashboard screenshots และเรียกค่าไถ่ 2 ล้านเหรียญผ่าน Telegram
แต่ที่ต้องฟังหูไว้หูคือ BleepingComputer ระบุเองว่าสมาชิก ShinyHunters คนอื่นที่ติดต่อไป ปฏิเสธว่าไม่เกี่ยวกับเหตุการณ์นี้ การ attribution เลยยังไม่นิ่ง อาจมีคนอ้างชื่อกลุ่มเพื่อให้ดูใหญ่ก็ได้ ตอนนี้ที่แน่ๆ มีของหลุดจริง แต่ใครเป็นคนเอาออก ยังเป็นคำถาม
Vercel เองได้จ้าง Mandiant เข้ามา response และทำงานร่วมกับ law enforcement และบริษัท security เพิ่มเติม รายละเอียดที่ลึกกว่านี้น่าจะค่อยๆ ออกมาในอีกไม่กี่สัปดาห์
ถ้าคุณใช้ Vercel ทำสี่อย่างนี้คืนนี้
ไม่ต้องรอ email จาก Vercel เพราะถึงคุณไม่ได้อยู่ในกลุ่มที่ได้รับผลกระทบ pattern นี้ก็สอนให้เราต้อง hygiene อยู่แล้ว
หนึ่ง เปิด MFA ทุกที่ ทั้ง Vercel, GitHub, Google Workspace ที่ใช้ login เข้า dashboard ถ้าใครใน team ยังไม่เปิด นี่คือเหตุผลให้เปิดวันนี้
สอง rotate env vars ที่ไม่ได้ติด sensitive flag เข้าไปที่ project settings ของแต่ละโปรเจกต์ ดูว่ามี variable ตัวไหนเป็น API key, database credential, หรือ signing key ที่ยังเป็น plain non-sensitive อยู่ ตัดสินใจเปลี่ยน secret ที่ผู้ให้บริการต้นทาง (เช่น Stripe, Supabase, OpenAI) แล้วใส่ค่าใหม่ใน Vercel โดยกด sensitive flag คราวนี้
สาม audit OAuth integrations ทั้งหมด ทั้งใน Google Workspace ของคุณและของทีม เข้าไปที่ Security > Third-party access ดูว่ามี app อะไรที่คุณ grant ไว้แล้วลืม ถ้าไม่ได้ใช้แล้วถอดออก ถ้าเป็น tool ที่ scope กว้างเกิน (เช่น read all email) ลองหาตัวที่ scope แคบกว่ามาแทน
สี่ ดู audit log ของ Vercel เข้าไปที่ team settings > activity log ดูย้อนหลังว่ามี deployment, env var change, หรือ team member activity ที่คุณไม่ได้เป็นคนทำไหม โดยเฉพาะช่วงก่อนวันที่ 19 เมษายน 2026
OAuth คือ supply chain ที่ทุกคนลืมว่ามี
เคสนี้ทำให้เห็นภาพใหญ่ที่หลายคนมองข้าม
เวลาเราพูดถึง supply chain attack คนส่วนใหญ่จะนึกถึง npm package ที่โดน inject โค้ด หรือ dependency ที่ถูกซื้อต่อจาก maintainer เก่า แต่ OAuth ก็คือ supply chain อีกแบบหนึ่ง คุณ delegate สิทธิ์เข้าบัญชีของคุณให้กับ third-party app ทุกครั้งที่กด Allow
ลองนับในหัวคุณตอนนี้ คุณกด allow ให้ tool อะไรไปแล้วบ้างใน Google account ของคุณ Notion plugin, Calendly, Loom, AI summarizer ตัวไหนสักตัว, productivity bot, อีกสารพัด แต่ละตัวคือ key ที่คุณส่งให้คนอื่นถือ ถ้า vendor ตัวไหนโดนแฮก key ของคุณก็โดนด้วย
ที่น่ากลัวกว่าคือคุณมักไม่รู้ว่า vendor นั้นเก็บ token ของคุณยังไง encrypt หรือเปล่า มี rotation policy ไหม มี logging ดีพอไหม คุณ trust by default เพราะ UI มันให้คุณ trust
วิธีจัดการที่พอทำได้ตอนนี้คือลด attack surface เข้าไปที่ Google Account > Security > Third-party apps with account access ทุก 3 เดือน ตัดทุก app ที่ไม่ได้ใช้ออก
สำหรับ app ที่ยังใช้ ดูว่า scope ที่ขอมันสมเหตุสมผลกับสิ่งที่ทำไหม ถ้า to-do app ขอ read all email อันนั้นไม่โอเค
สำหรับ team setting ถ้าคุณเป็น admin ของ Google Workspace ลองเปิด context-aware access และ block third-party apps ที่ไม่ได้ approved รายตัว ใช้เวลา setup สักวัน แต่ตัด attack vector แบบที่ Vercel โดนได้เยอะเลย
บทเรียนที่ใช้กับทุก stack ไม่ใช่แค่ Vercel
ถ้าตัด brand ออกจากเรื่องนี้ ที่เหลือคือ pattern ที่ใช้ได้กับทุก hosting platform หรือ SaaS ใดๆ ที่เก็บ secret ของคุณ
หนึ่ง encryption at rest ต้องเป็น default ไม่ใช่ option ถ้าแพลตฟอร์มไหนยังให้คุณเลือกเอง สมมติไว้เลยว่ามีคนลืมแน่นอน เพราะคนจะลืม
สอง least-privilege OAuth scopes สำคัญพอๆ กับการตั้ง password ดีๆ ถ้า app ขอเยอะเกินไป ปฏิเสธ หรือหา alternative
สาม rotation ไม่ใช่เรื่องที่ทำตอนเกิดเหตุ ถ้าคุณตั้ง schedule rotate ทุก 90 วันอัตโนมัติด้วย secret manager (เช่น AWS Secrets Manager, Doppler, Infisical) วันที่ vendor ของคุณโดนแฮก ผลกระทบจะเล็กลงมาก เพราะ secret ที่หลุดอาจหมดอายุไปแล้ว
สี่ assume breach mindset ต้องคิดว่าทุก vendor มีโอกาสโดนแฮกได้ทุกวัน ถ้า threat model ของคุณยังเป็น "เราไว้ใจ vendor นี้" คุณกำลังเดิมพันบนสิ่งที่ควบคุมไม่ได้
คำถามที่ Vercel ยังไม่ตอบ
มีหลายเรื่องที่ Vercel ยังไม่เปิด ลูกค้าและคนใน community ก็รอข้อมูลอยู่
คนร้ายอยู่ในระบบนานแค่ไหนก่อนถูกพบ Vercel ยังไม่เปิด dwell time มี search snippet อ้างถึงตัวเลข 22 เดือน แต่ตัวเลขนั้นยังไม่ได้รับการยืนยันโดยตรงจาก Vercel หรือจาก incident response report ที่เปิดเผย
"limited subset" คือกี่ราย Vercel เลือกที่จะไม่บอกตัวเลข อาจเพราะยังคำนวณไม่จบ หรือเพราะ legal advise ไม่ให้บอก แต่แปลว่าเรายังประเมิน blast radius ที่แท้จริงไม่ได้
มี secondary breach ที่เกิดจากตรงนี้แล้วหรือยัง เช่น ถ้า API key ของลูกค้า A หลุดและคนร้ายใช้ key นั้นไปเข้า Stripe หรือ AWS ของลูกค้า A ต่อ ผลกระทบจริงอาจไม่จบที่ Vercel
คำถามสุดท้ายที่ใหญ่กว่า brand เดียวคือ มี vendor อีกกี่เจ้าที่ stack ของเราพึ่งพา ใช้ OAuth model คล้ายกัน และ default ปลอดภัยพอแค่ไหน คำตอบที่ตรงไปตรงมาคือ คุณต้องเช็กเอง ไม่มีใครเช็กแทนคุณได้
แหล่งอ้างอิง
บทความที่เกี่ยวข้อง
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!