Skip to main content
AI & Technology

Vercel โดนแฮ็คเพราะพนักงาน 1 คนติดตั้ง AI app — บทเรียน Supply Chain Attack ปี 2026 ที่ทุกบริษัทต้องเรียนรู้

20 เมษายน 2026 Vercel ประกาศโดนแฮ็ค — ข้อมูลลูกค้า API keys source code database credentials รั่ว ต้นเหตุ พนักงาน 1 คนติดตั้ง AI app จาก Context AI ที่ถูกแฮ็คก่อนหน้า แล้วเชื่อม Google account ผ่าน OAuth บทความนี้รวม anatomy ของการโจมตี 7 บทเรียนสำหรับทุกบริษัทที่ใช้ SaaS และเชื่อมโยงกับ PDPA ไทย

21 เม.ย. 202612 นาที
CybersecuritySupply Chain AttackVercelOAuthSaaS SecurityPDPAData BreachIncident Response

สรุปสั้นก่อนเริ่ม

วันที่ 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

  1. Vendor risk assessment — ประเมินทุก third-party ที่ process ข้อมูลแทนเรา (ไม่ใช่แค่ direct vendor — รวมถึง app ที่พนักงานใช้ด้วย)

  2. Data Processing Agreement (DPA) — ทำสัญญา DPA กับทุก vendor ระบุชัดเรื่อง:

    • มาตรฐาน security ที่ต้องทำ
    • Breach notification ภายในกี่ชั่วโมง
    • ขอบเขตความรับผิด
    • สิทธิ audit

  3. Breach notification ภายใน 72 ชั่วโมง — กฎหมาย PDPA กำหนด ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงหลังรู้เหตุ

  4. 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 ที่ใช้อยู่ — ติดต่อเราเพื่อปรึกษา ได้ทุกเวลา

กลับไปหน้า Insights

บทความที่เกี่ยวข้อง

AEO + SEO — คู่มือเอาตัวรอดเมื่อ AI กลืนกิน Google Search

Gartner ทำนาย Search Volume จะลด 25% ภายในปี 2026 และ 50% ภายในปี 2028 — Zero-click search พุ่ง 65% เว็บไซต์ที่ไม่ปรับตัวจะหายไปจากสายตาลูกค้า บทความนี้คือคู่มือฉบับสมบูรณ์สำหรับธุรกิจไทย

AEO vs GEO — เจาะลึกสองกลยุทธ์ที่ตัดสินว่า AI จะ "เห็น" หรือ "ข้าม" เว็บไซต์คุณ

Web Mentions สัมพันธ์กับ AI Citations สูงกว่า Backlinks ถึง 3 เท่า, AI referral traffic โต 527% YoY, เว็บที่มี Schema มีโอกาสถูก AI อ้างอิงมากกว่า 2.5 เท่า — คู่มือเชิงลึก AEO vs GEO พร้อมวิธีตรวจสอบและปรับเว็บไซต์

Agentic AI ในองค์กร — จาก 5% สู่ 40% ภายในปี 2026: โอกาสและความเสี่ยงที่ผู้บริหารต้องรู้

ตลาด Agentic AI โตจาก $1B สู่ $9B+ ใน 2 ปี Gartner คาด 40% ของแอปองค์กรจะมี AI Agent ภายในสิ้นปี 2026 แต่กว่า 40% ของโปรเจกต์อาจถูกยกเลิก — บทความนี้วิเคราะห์โอกาส ความเสี่ยง และกลยุทธ์สำหรับองค์กรไทย

"Empowering Innovation,
Transforming Futures."

บอกเราว่างานส่วนไหนที่คุณต้องการปรับ