สรุปสั้นก่อนเริ่ม
วันที่ 20 เมษายน 2026 Vercel — บริษัท cloud hosting ยักษ์ใหญ่ เจ้าของ Next.js framework ที่เว็บระดับ production ทั่วโลกใช้งาน — ออกมายืนยันว่า โดนแฮ็ค
ต้นเหตุไม่ได้มาจาก zero-day exploit หรือฝีมือ state-sponsored hackers ขั้นเทพ
มันมาจาก พนักงาน 1 คน ที่ไปดาวน์โหลด AI app ชื่อ Context AI มาใช้ส่วนตัว แล้วเชื่อม app นั้นกับ corporate Google account ผ่าน OAuth
Context AI โดนแฮ็คไปก่อนหน้านี้ตั้งแต่เดือนมีนาคม — hackers ใช้ OAuth token ที่เก็บไว้ยึด Google account ของพนักงาน Vercel แล้วเดินเข้า Vercel internal systems ทีละขั้น จนเจอ credentials ที่ไม่ได้ encrypt แล้วยกระดับสิทธิ์ต่อ
ผลลัพธ์คือ:
- Customer API keys รั่ว
- Source code ของลูกค้าหลายรายถูกขโมย
- Database credentials ถูกเข้าถึง
- Deployment credentials ถูกอ้างว่าเข้าถึงได้ (Vercel บอกว่า "non-sensitive")
- อาจกระทบ "hundreds of users across many organizations"
Next.js และ Turbopack ซึ่งเป็น open-source ไม่ได้รับผลกระทบ ตามที่ Vercel แถลง
แต่สำหรับทุกบริษัทที่ใช้ SaaS (แปลว่า ทุกบริษัท) นี่คือเคสที่ต้องเรียนรู้ก่อนจะเจอกับตัว
เพราะเรื่องนี้ไม่ได้เกี่ยวกับ Vercel คนเดียว — มันคือ systemic risk ของยุค AI + OAuth + SaaS ที่ทุกองค์กรกำลังว่ายอยู่
อ่านต่อ ผมจะอธิบาย attack chain ทีละขั้น แล้วสรุปเป็น 7 บทเรียนที่คุณเอาไปใช้ได้พรุ่งนี้เช้า
เรื่องเริ่มจากพนักงาน 1 คนติดตั้ง AI app
เรื่องนี้ไม่ได้เริ่มจาก Vercel
มันเริ่มจาก Context AI — consumer app สำหรับเพิ่ม productivity ในงาน office ที่มีผู้ใช้ทั่วโลก
เดือนมีนาคม 2026 Context AI โดนแฮ็ค แต่ข่าวไม่ได้แพร่หลาย เพราะ Context AI เป็น consumer product ที่ไม่มี public-facing enterprise commitment มาก
แต่ปัญหาคือ — พนักงาน Vercel 1 คน เคยดาวน์โหลด Context AI มาใช้งาน
และตอนติดตั้ง เขาเลือก "Sign in with Google" — ใช้ corporate Google account ของ Vercel เชื่อมต่อ app ผ่าน OAuth
ทำไมถึงเลือก corporate account? เหตุผลเดียวกับที่เราทุกคนทำ:
- สะดวก
- ไม่อยาก manage password หลายที่
- ไม่คิดว่ามันเป็น "ของจริงจัง" — แค่ AI app ตัวเล็กๆ
จังหวะคลิก "Allow" นั้น คือจังหวะที่ Vercel แพ้เกมแล้ว — แต่ยังไม่มีใครรู้
เพราะ OAuth grant ไม่ได้แค่ให้ app อ่าน profile — ขึ้นอยู่กับ scope ที่ขอ มันอาจได้ permission:
- อ่าน email
- เข้าถึง Google Drive
- อ่าน calendar
- หรือถ้า scope กว้างมาก — refresh token ที่ใช้เข้าถึง account ได้เรื่อยๆ
แล้วเมื่อ Context AI โดนแฮ็ค OAuth tokens ที่เก็บไว้ในระบบ Context AI ทั้งหมด ก็ตกเป็นของ hackers
ของพนักงาน Vercel ด้วย
Timeline ที่ต้องรู้
เรียงเหตุการณ์แบบเข้าใจง่าย:
มีนาคม 2026 — Context AI ถูกแฮ็ค (ต้นน้ำของเรื่องทั้งหมด)
ระหว่าง มี.ค. — เม.ย. — hackers เริ่มใช้ OAuth tokens ที่ได้จาก Context AI ไล่เจาะบริษัทที่มีพนักงานใช้ Context AI หนึ่งในนั้นคือ Vercel
20 เมษายน 2026 — Vercel ประกาศ security incident ต่อสาธารณะ ผ่าน TechCrunch และ changelog ของตัวเอง ยืนยันว่าข้อมูลลูกค้าถูกขโมย
ระยะเวลาจาก Context AI โดนแฮ็ค → Vercel ประกาศ = อย่างน้อย 1 เดือน
นี่คือสิ่งที่ในวงการเรียกว่า attack dwell time — เวลาที่ hackers อยู่ในระบบก่อนถูกจับได้ สถิติเฉลี่ยของ dwell time ทั่วโลกอยู่ที่หลักหลายสิบถึงร้อยวัน
ความหมายคือ:
- เมื่อคุณรู้ว่าโดนแฮ็ค — hackers อยู่ในระบบมาแล้วหลายสัปดาห์
- Incident response ช้า = ความเสียหายทวีคูณ
- Forensics กลับหลังยาก เพราะ log อาจถูกลบไปแล้ว
สำหรับ Vercel การที่ประกาศภายใน 1 เดือนถือว่าเร็ว — แต่ก็ไม่ได้แปลว่า 1 เดือนนั้นไม่เกิดความเสียหาย
ทำไมเรื่องนี้สำคัญ — มากกว่าข่าวธรรมดา
ลองนึกภาพว่า Vercel คืออะไร:
- Cloud platform ที่โฮสต์เว็บ production หลักล้านเว็บ
- เจ้าของ Next.js framework ที่ Fortune 500 ใช้
- Infrastructure layer ที่เว็บของคุณอาจพึ่งพาอยู่โดยไม่รู้ตัว
การที่ Vercel โดนแฮ็ค = cascading impact — ลูกค้า Vercel โดนกระทบไปด้วย, ลูกค้าของลูกค้าก็อาจโดนไปด้วย
นี่คือ pattern ที่วงการ security เรียกว่า supply chain attack — โจมตี 1 จุดเพื่อกระทบไปหลายร้อยหลายพันองค์กรพร้อมกัน
ถ้าใครจำได้ เคสที่คนพูดถึงมากสุดในทศวรรษที่ผ่านมาคือ SolarWinds ปี 2020 — hackers แฝง malware ใน software update ของ SolarWinds แล้วกระทบลูกค้ารวมถึงหน่วยงานรัฐบาลสหรัฐฯ หลายแห่ง
เคส Vercel 2026 ไม่เหมือน SolarWinds 100% — แต่ pattern เดียวกัน:
- จุดเดียวถูกเจาะ
- ผลกระทบแพร่กระจายข้ามองค์กร
- การป้องกันระดับบริษัทไม่พอ — ต้องป้องกันระดับ ecosystem
ผมเรียกเคสนี้ว่า "SolarWinds moment ของยุค AI + OAuth" — เพราะมันเกิดในช่วงที่ทุกคนเร่งใช้ AI tools โดยไม่มี governance framework ที่ทันเกม
Attack Anatomy: ทุกขั้นตอนที่ผิด
แยกออกมาเป็น 6 ขั้นเพื่อให้เห็นภาพ:
1. Pre-attack — พนักงานดาวน์โหลด AI app ไม่ผ่าน review
ไม่มี policy ว่าต้องขออนุญาตก่อนติดตั้ง app ที่เชื่อมกับ corporate account
จุดที่ผิด: ไม่มี application install control
2. OAuth grant — ให้สิทธิ์เข้า corporate Google account
พนักงานกด "Allow" โดยไม่อ่าน scope ละเอียด หรืออ่านแล้วไม่เข้าใจว่า implication คืออะไร
จุดที่ผิด: OAuth scope กว้างเกินจำเป็น + ไม่มี admin review
3. Upstream breach — Context AI เองถูกแฮ็ค
Third-party vendor โดนโจมตี — เราควบคุมไม่ได้โดยตรง
จุดที่ผิด: ไม่มี vendor risk assessment ว่า app ที่พนักงานใช้ มีมาตรฐาน security ระดับไหน
4. Token theft — hackers ใช้ OAuth token/refresh ที่มีอยู่
Token ยังไม่หมดอายุ หรือมี refresh token ที่ขอ access token ใหม่ได้เรื่อยๆ
จุดที่ผิด: Token lifetime ยาวเกินไป + ไม่มี proactive revocation เมื่อ vendor เกิดเหตุ
5. Lateral movement — จาก Google account เดินเข้า Vercel internal
Account เดียวเข้าระบบหลายอย่างได้ (SSO + integrated tools) = ประตูเดียวเจาะได้ทั้งบ้าน
จุดที่ผิด: Segmentation อ่อน + ไม่มี step-up authentication สำหรับ sensitive actions
6. Credential sprawl — เจอ credentials ที่ไม่ได้ encrypt
ในระบบ Vercel internal hackers เจอ credentials เก็บไว้แบบไม่ได้ encrypt → ใช้ยกระดับสิทธิ์ต่อเข้าระบบลูกค้า
จุดที่ผิด: Credential hygiene อ่อน — ของใหญ่ขนาดนี้ยังมี plaintext secrets
6 จุดผิด ถ้าปิด 1 จุดได้ → attack chain ขาด เรื่องไม่ไปถึงลูกค้า
บทเรียนสำหรับทุกบริษัทที่ใช้ SaaS — 7 ข้อ
1. OAuth Audit ทุกไตรมาส
ถามตัวเองตอนนี้: คุณรู้ไหม ว่าพนักงานของคุณให้สิทธิ์ OAuth กี่ app ไปแล้ว?
ส่วนใหญ่ตอบไม่ได้
Google Workspace มี "Third-party apps with account access" ใน admin console — ลิสต์ครบว่า app ไหนเข้าถึงอะไรได้
Microsoft 365 มี Enterprise Applications ใน Entra ID — ระบุ permission ทั้งหมด
Action: ทำ audit ทุกไตรมาส ตัด app ที่ไม่ได้ใช้ + บริษัทไม่รู้จัก ออกให้หมด
2. Least Privilege สำหรับ OAuth scopes
อย่าให้ email.read ถ้าต้องการแค่ profile
อย่าให้ drive.full ถ้าต้องการอ่านแค่ folder เดียว
กฎเหล็ก: OAuth scope ที่เผลอให้ = สิทธิ์ที่ hackers จะได้ ถ้า vendor โดนแฮ็ค
Action: ตั้ง policy ให้ admin review OAuth scope ก่อน approve app สำหรับทั้งบริษัท
3. Employee Application Control Policy
ห้ามหรือ require approval สำหรับ app install ที่เชื่อมกับ corporate account
ประเด็นไม่ใช่ "ไม่เชื่อใจพนักงาน" — ประเด็นคือ supply chain risk ไม่ใช่สิ่งที่พนักงานคนเดียวประเมินเองได้
Action: สร้าง allowlist ของ app ที่ผ่าน security review แล้ว + process ขออนุมัติสำหรับ app อื่น
4. Credential Hygiene
Internal credentials ต้อง encrypted at rest เสมอ
ใช้ secret management tool: HashiCorp Vault, AWS Secrets Manager, 1Password for Teams, Azure Key Vault
Rule of thumb:
- ไม่มี hardcode secret ใน source code
- ไม่มี plaintext secret ใน config file
- Secret rotate อัตโนมัติอย่างน้อยทุกไตรมาส
- Access log ทุกครั้งที่มีคนดึง secret
ถ้า Vercel มีอันนี้แน่นหนา hackers เจอ internal system ก็ยัง escalate ต่อไม่ได้
5. MFA ที่แข็งแรงพอ
SMS MFA ไม่พอ — SIM swap attack พิสูจน์มาหลายเคสแล้ว
ใช้:
- Hardware security key (Yubikey)
- Passkey (มาตรฐาน FIDO2)
- Authenticator app ที่มี phishing-resistance
แต่ต้องเข้าใจ: MFA ไม่ป้องกัน OAuth token abuse — เพราะ token ออกแล้ว ถูกขโมย แล้วใช้ได้เลย โดยไม่ต้อง MFA ซ้ำ
Action: ตั้ง token lifetime สั้น (เช่น 1 ชั่วโมง) + require re-auth สำหรับ sensitive scope
6. Anomaly Detection
Login จากประเทศแปลก, เวลาแปลก, device ไม่รู้จัก = ต้องเด้ง alert
ใช้ SIEM tool: Microsoft Sentinel, Datadog Cloud SIEM, Splunk, Elastic Security, Wazuh (open-source)
Google Workspace และ Microsoft 365 มี alerting built-in อยู่แล้ว — แค่เปิดใช้และตั้งค่าให้ถูก
Action: ตั้ง alert สำหรับ
- Login impossible travel
- Login นอกเวลาทำการที่ไม่เคยมี pattern
- OAuth grant ใหม่ใน corporate account
- Admin privilege escalation
7. Incident Response Plan ที่ซ้อมจริง
แผนเฉยๆ บนกระดาษไม่พอ
ต้อง tabletop exercise — สมมติสถานการณ์แล้วซ้อมรับมือจริง อย่างน้อยปีละ 2-4 ครั้ง
ครอบคลุม:
- ใครเป็น incident commander?
- ติดต่อ legal ภายในกี่ชั่วโมง?
- Communication plan สำหรับลูกค้า (ต้องเตรียม ก่อน เกิดเหตุ ไม่ใช่ตอนเกิด)
- Forensics preservation — log ต้องไม่ rotate ออกก่อน investigation
- Regulatory notification — PDPA 72 ชั่วโมง, GDPR 72 ชั่วโมง
Action: อย่างน้อยปีหน้า ต้องซ้อม 1 ครั้ง จดบทเรียน ปรับแผน
สำหรับธุรกิจไทย — เชื่อมโยง PDPA
PDPA ไม่ใช่เรื่องของอนาคต — ปี 2026 PDPA เริ่ม enforcement จริงจังแล้ว (เราเคยเขียนไว้ใน บทความรวม 5 คดี PDPA)
ถ้าบริษัทไทยเจอเคสแบบ Vercel — ข้อมูลลูกค้ารั่วเพราะ supply chain breach — โดนปรับตาม PDPA ได้เต็มๆ
หน้าที่ของ DPO ในบริบท supply chain
Vendor risk assessment — ประเมินทุก third-party ที่ process ข้อมูลแทนเรา (ไม่ใช่แค่ direct vendor — รวมถึง app ที่พนักงานใช้ด้วย)
Data Processing Agreement (DPA) — ทำสัญญา DPA กับทุก vendor ระบุชัดเรื่อง:
- มาตรฐาน security ที่ต้องทำ
- Breach notification ภายในกี่ชั่วโมง
- ขอบเขตความรับผิด
- สิทธิ audit
Breach notification ภายใน 72 ชั่วโมง — กฎหมาย PDPA กำหนด ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงหลังรู้เหตุ
Record of Processing Activities (RoPA) — ต้องมี log ว่าใครเข้าถึงข้อมูลอะไรบ้าง เมื่อเกิดเหตุ จะสอบสวนย้อนหลังได้
ค่าปรับ ≠ ความเสียหายเดียว
PDPA มีโทษปรับสูงสุด 5 ล้านบาทต่อเหตุ + ชดใช้ผู้เสียหาย
แต่ค่าปรับเป็นแค่ tip of iceberg:
- Reputation damage — ลูกค้าเก่าไม่กลับมา, ลูกค้าใหม่ไม่เลือกเรา
- Churn — B2B clients ย้าย vendor เพราะ compliance requirement
- Insurance premium เพิ่ม — cyber insurance ขึ้นราคาหลังเคลม
- Legal cost — ค่าทนาย, ค่า forensics, ค่า customer notification
เคส Vercel นี้ สหรัฐฯ ไม่มี PDPA แต่มี CCPA, SOC2, GDPR (สำหรับลูกค้า EU) ที่เข้ามาเกี่ยวหมด
ธุรกิจไทยที่มีลูกค้าต่างประเทศด้วย — compliance ทับซ้อน ซับซ้อนกว่าเดิม
เครื่องมือที่ใช้ได้ — แนะนำแบบกลางๆ
ผมไม่มี preference ว่าต้องใช้ brand ไหน เพราะแต่ละที่มี trade-off ต่างกัน ขึ้นกับขนาดบริษัท budget และ tech stack ที่มีอยู่
- OAuth audit / IAM: Google Admin Console, Microsoft Entra ID, Okta, JumpCloud
- Secret management: HashiCorp Vault, AWS Secrets Manager / Azure Key Vault / GCP Secret Manager, 1Password for Teams, Doppler, Infisical
- SIEM: Microsoft Sentinel, Datadog Cloud SIEM, Splunk, Elastic Security, Wazuh (open-source)
- Hardware key / Passkey: Yubikey, Google Titan, Platform Passkey
- Endpoint protection: CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Sophos
เลือกตามบริบท — ไม่ใช่ตามว่าใครดังสุด
สำหรับทีม Enersys — วิธีคิดของเราเรื่องนี้
Enersys เป็น Software House ที่สร้างระบบ Odoo, Enterprise AI solutions, และที่ปรึกษา PDPA ให้ลูกค้า
เมื่อเราส่งมอบระบบให้ลูกค้า — ความรับผิดชอบของเราไม่ได้จบที่ "code run ได้"
Supply chain risk คือ first-class concern ของเรา:
Odoo deployments — ทุก third-party module ที่แนะนำให้ลูกค้า ต้องผ่าน review ว่า:
- มาจาก official Odoo partner หรือ audited community module
- Dependencies ไม่มี known CVE
- Update frequency เหมาะสม ไม่ใช่ abandoned project
AI integrations — ก่อน deploy tool/plugin/model ใดๆ ให้ลูกค้า เรา review:
- Data flow ว่าข้อมูลลูกค้าวิ่งไปไหนบ้าง
- OAuth scope ขั้นต่ำที่ต้องใช้
- Storage location (สำคัญมากสำหรับ PDPA)
- Incident response commitment ของ vendor
PDPA assessments — ครอบคลุม supply chain risk ไม่ใช่แค่ direct data handling
- มี vendor inventory
- มี DPA template ที่ใช้ได้จริง
- มี breach notification playbook
ผมไม่ได้บอกว่าเราสมบูรณ์แบบ — security ไม่มีสมบูรณ์แบบ มีแต่ "ดีขึ้นทุกวัน"
แต่ ทีมที่ไม่คิดเรื่องนี้เลย = ทีมที่กำลังรอเจอเคสแบบ Vercel
สรุป — Trust is built, then broken, then rebuilt
เคส Vercel สอน 3 เรื่อง:
1. No one is too big to fail
Vercel มี team security engineer เก่งๆ มี budget มหาศาล มี process ที่ดีกว่าบริษัทส่วนใหญ่ — ยัง โดนแฮ็ค
บริษัทเล็ก = ต้องระวังยิ่งกว่า เพราะ resource น้อยกว่า
2. Supply chain attack ≠ "bad luck"
มันคือ systemic risk ของยุค SaaS + AI + OAuth
ถ้าไม่ invest ในการป้องกัน = รอเจอกับตัว
3. การป้องกัน = culture + tooling + discipline
ซื้อเครื่องมือแพงๆ อย่างเดียวไม่พอ
ต้องมี culture ที่พนักงานรู้ว่าอะไรคือ risk
ต้องมี discipline ที่ไม่ปล่อย security ไว้ใน "งานรอง"
เคส Vercel จบได้ด้วย patch + advisory — แต่ความเชื่อมั่นที่หายไป ต้องใช้เวลาเป็นปีสร้างคืน
สำหรับธุรกิจไทยที่อ่านอยู่ — ถ้าเรื่องนี้เกิดกับคุณพรุ่งนี้ คุณพร้อมไหม?
ไม่พร้อม = เริ่มวันนี้ได้
แหล่งข้อมูล
บทความนี้เขียนโดยทีม Enersys — Software House ที่ให้บริการ Odoo ERP implementation, Enterprise AI solutions, และที่ปรึกษา PDPA สำหรับธุรกิจไทย ถ้าคุณกังวลเรื่อง supply chain risk ในระบบ SaaS ที่ใช้อยู่ — ติดต่อเราเพื่อปรึกษา ได้ทุกเวลา
