แยกชิ้นส่วน Zapocalypse: เมื่อ 5 จุดอ่อนที่รู้กันดี รวมร่างเป็นหายนะซัพพลายเชนครั้งใหญ่ของ Zapier

ในช่วงปลายเดือนพฤษภาคม 2026, ทีมวิจัยจาก Token Security ได้เปิดเผยห่วงโซ่การโจมตี (Exploit Chain) 5 ขั้นตอนที่พวกเขาตั้งชื่ออย่างติดตลกว่า "Zapocalypse" ซึ่งแสดงให้เห็นว่า การนำจุดอ่อนที่รู้กันดี (Anti-patterns) หลายๆ จุดมาเรียงต่อกัน สามารถเปลี่ยนจากบัญชี Zapier ฟรีๆ บัญชีเดียว ไปสู่การมีสิทธิ์เขียน (Write Access) บนแพ็คเกจ SDK สาธารณะและแพ็คเกจภายในทั้งหมดของ Zapier บน NPM ได้อย่างไร

หัวใจสำคัญของเรื่องนี้ไม่ใช่ช่องโหว่ 0-day ใหม่เอี่ยมอะไร แต่มันคือ "องค์ประกอบ" (Composition) ของจุดที่แต่ละทีมมองว่าปลอดภัยดีแล้ว เมื่อนำมาวางเรียงต่อกันข้ามระบบของหลายๆ ทีม มันกลายเป็นเส้นทางการโจมตีที่ร้ายแรง ซึ่งไม่มีใครเคยนึกถึงมาก่อน

5 ขั้นตอนแห่ง Zapocalypse: จากเมล็ดทรายสู่หายนะ

ขั้นที่ 1: แหกคุก Sandbox ด้วยการคุ้ยขยะในความทรงจำ

ทุกอย่างเริ่มต้นจากฟีเจอร์ Code by Zapier ที่ให้ผู้ใช้เขียนโค้ด Python และ JavaScript สั่งงานได้ ซึ่งโค้ดพวกนี้จะถูกรันอยู่ภายในคอนเทนเนอร์ AWS Lambda ปกติแล้ว Lambda handler ของ Zapier จะพยายามล้างข้อมูล AWS credentials ออกจาก environment variables โดยใช้คำสั่ง

del os.environ[k]

แต่เทคนิคนี้มีช่องโหว่ตรงที่มันเรียกใช้แค่ unsetenv ของ libc ซึ่งจะลบตัวชี้ (pointer) ออกจากตาราง environment แต่ไม่ได้เขียนทับหรือทำให้ข้อมูลในหน่วยความจำ (heap) สูญหายไปจริงๆ นักวิจัยใช้ประโยชน์จากตรงนี้ด้วยการอ่านไฟล์ /proc/self/mem และใช้รูปแบบ regex สี่แบบเพื่อสแกนหาข้อมูลในพื้นที่หน่วยความจำที่อ่านได้

ผลลัพธ์คือพวกเขาสามารถกู้คืน AWS STS session token จริง ของบทบาท IAM ของ Lambda นั้นกลับมาได้สำเร็จ เป็นการหลบหนีออกจาก sandbox ที่สมบูรณ์แบบ

ขั้นที่ 2: สแกน ECR ด้วยสิทธิ์ที่น้อยนิดแต่มหาศาล

บทบาท AWS ที่กู้คืนมาได้นั้นมีชื่อว่า allow_nothing_role ซึ่งฟังดูเหมือนแทบไม่มีสิทธิ์อะไรเลย แต่ชื่อมันหลอกตา เพราะจริงๆ แล้วบทบาทนี้มีสิทธิ์ในการเข้าถึง Elastic Container Registry (ECR) สี่อย่างที่สำคัญมาก:

• ecr:DescribeRepositories
• ecr:ListImages
• ecr:BatchGetImage
• ecr:GetDownloadUrlForLayer

สิทธิ์แค่สี่ตัวนี้กลับเพียงพอที่จะดึงอิมเมจคอนเทนเนอร์ (Container Images) ทั้งหมดผ่าน AWS API โดยตรง โดยที่ไม่ต้องขอ Docker registry authentication token ด้วยซ้ำ นักวิจัยใช้สิทธิ์นี้ในการสำรวจและระบุ คลังเก็บอิมเมจในระบบที่ใช้งานจริงถึง 1,111 แห่ง และเริ่มดึงอิมเมจออกมาได้สำเร็จ

ขั้นที่ 3: งมเข็ม NPM Token ในประวัติของอิมเมจ

ภายในหนึ่งในอิมเมจที่ถูกดึงออกมา นักวิจัยค้นพบ NPM publish token ที่หลุดเข้าไปอยู่ในประวัติการตั้งค่า (configuration history) ของอิมเมจ โดย token นี้ถูกส่งเข้าไปยังกระบวนการ build ผ่านคำสั่ง ARG ใน Dockerfile

การส่งค่าเป็น build argument นั้นถูกบันทึกไว้อย่างถาวรในฟิลด์ history[] ของอิมเมจ หมายความว่าใครก็ตามที่สามารถดึงอิมเมจนี้ได้ก็จะสามารถอ่าน token ดังกล่าวได้ย้อนหลัง

ขั้นที่ 4: สิทธิ์เผยแพร่บน NPM แบบข้ามการยืนยันตัวตน 2 ชั้น (2FA)

NPM token ที่กู้คืนมาได้นั้นมีคุณสมบัติสามอย่างที่อันตรายที่สุด :

1. action: write

   : มีสิทธิ์เขียน

2. name: null

   : ไม่จำกัดชื่อแพ็คเกจ

3. bypass_2fa: true

   : ข้ามการยืนยันตัวตนสองชั้น (2FA)

ด้วยการตั้งค่านี้ นักวิจัยสามารถใช้ token ดังกล่าวเพื่อเผยแพร่โค้ดใหม่ไปยังทุกแพ็คเกจที่บัญชี NPM นั้นมีสิทธิ์เข้าถึงได้ โดยไม่ต้องผ่านการยืนยันตัวตนใดๆ เลย ซึ่งรวมถึงแพ็คเกจสำคัญของ Zapier อย่าง zapier-platform-core, zapier-platform-cli, และ zapier-design-system

ขั้นที่ 5: จุดยึดในซัพพลายเชน สู่การรันโค้ดในเบราว์เซอร์ของผู้ใช้ทุกคน

แพ็คเกจที่อันตรายที่สุดในห่วงโซ่นี้คือ zapier-design-system เพราะมันถูกโหลดในทุกๆ เซสชั่นที่ล็อกอินเข้าใช้งานบนเว็บไซต์ zapier.com นักวิจัยได้ตรวจสอบเส้นทางการโหลดนี้ผ่านเครื่องมือนักพัฒนาของเบราว์เซอร์ (DevTools) และหยุดการทดสอบไว้เพียงเท่านี้ โดยพวกเขาไม่ได้เผยแพร่โค้ดอันตรายใดๆ ออกไปจริง

หากผู้ไม่ประสงค์ดีทำการเผยแพร่แพ็คเกจที่ถูกวางยาพิษ, พวกเขาจะสามารถรัน JavaScript ที่ควบคุมได้ภายใน origin ของ zapier.com ในเซสชั่นที่ผู้ใช้ล็อกอินอยู่ทันทีเมื่อมีการอัปเดตครั้งถัดไป จากจุดนั้น, ผู้โจมตีสามารถสร้าง Zaps, Tables, MCP Servers ใหม่, หรือขับเคลื่อนระบบผสานการทำงาน (Integration) ที่มีอยู่เดิมในนามของผู้ใช้ที่ล็อกอินอยู่ได้ แม้ว่า OAuth tokens และ API keys ของบริการที่เชื่อมต่อกันจะยังคงเก็บอยู่ฝั่งเซิร์ฟเวอร์และไม่หลุดไปยังเบราว์เซอร์โดยตรง แต่ผลกระทบในทางปฏิบัติก็ยังคงร้ายแรงมาก

การตอบสนองของ Zapier และรางวัลบั๊ก

• 12 กุมภาพันธ์ 2026: Token Security ส่งรายงานให้กับ Zapier
• ภายใน 4 วัน: Zapier ทำการคัดแยก (Triage) รายงาน, เพิกถอน NPM token ที่รั่วไหล, และจำกัดสิทธิ์ของบทบาท AWS ที่เกี่ยวข้อง
• 5 มีนาคม 2026: Zapier ยืนยันว่าการแก้ไขเสร็จสมบูรณ์
• Zapier รายงานว่าไม่พบหลักฐานว่ามีการใช้ช่องโหว่นี้ในการโจมตีจริงแต่อย่างใด
• นักวิจัยได้รับเงินรางวัลสูงสุดของโปรแกรมในขณะนั้นเป็นจำนวน $3,000 (ประมาณ 100,000 บาท) และ Zapier ให้คำมั่นว่าจะพิจารณาเพดานเงินรางวัลนี้อีกครั้งในการทบทวนโปรแกรมครั้งถัดไป

หมายเหตุ: เหตุการณ์นี้เป็นคนละเหตุการณ์กับการโจมตีซัพพลายเชนจริงที่เกิดขึ้นเมื่อวันที่ 24 พฤศจิกายน 2025 ซึ่งบัญชี NPM ของ Zapier ถูกเวิร์ม Shai Hulud 2.0 โจมตีและทำให้แพ็คเกจ 425 ชุดติดมัลแวร์

บทเรียนใหญ่หลวง: ช่องโหว่ที่ตกอยู่ระหว่างรอยต่อของแต่ละทีม

Yair Balilti, หัวหน้าทีมวิจัยความปลอดภัยของ Token Security, ได้สรุปแก่นของเรื่องนี้ไว้อย่างน่าสนใจ :

"ทุกข้อต่อในห่วงโซ่นี้คือรูปแบบที่รู้กันดีทั้งนั้น (Known Pattern) ช่องโหว่ที่แท้จริงคือ 'การประกอบร่าง' ต่างหาก และการประกอบร่างนี่แหละคือสิ่งที่มักจะตกหล่นระหว่างรอยต่อของแต่ละทีม ระบบ Lambda sandbox, ECR และ IAM, token ของ GitLab CI, การเผยแพร่ NPM, ตัวเบราว์เซอร์ — แต่ละอย่างมีทีมที่ดูแลกันคนละกลุ่ม และแต่ละทีมก็สามารถมองแค่ส่วนของตัวเองแล้วสรุปได้อย่างมีเหตุผลว่ามันโอเคดี ความเสี่ยงจะปรากฏก็ต่อเมื่อคุณลากเส้นทางเดินของการโจมตีให้ทะลุผ่านทั้งหมดนี้เท่านั้น"

ข้อคิดที่ได้คือไม่มีทีมไหนเป็นเจ้าของช่องโหว่เพียงลำพัง :

• ทีม Lambda sandbox มองว่าการขุดคุ้ยข้อมูลในความทรงจำไม่ใช่ปัญหา เพราะ token พวกนั้นไม่ควรอยู่ตรงนั้นตั้งแต่แรก
• ทีม IAM เห็นแค่บทบาทที่จำกัดสิทธิ์ให้อ่าน ECR ได้
• ทีม CI/build ส่ง NPM token ผ่าน build argument ซึ่งเป็นเรื่องปกติ
• ทีม NPM ก็แค่จัดการ token ตัวหนึ่งที่มีสิทธิ์เขียน
• ทีมเบราว์เซอร์ก็แค่โหลดแพ็คเกจ design-system

การตัดสินใจแต่ละอย่างของแต่ละทีมนั้น "สมเหตุสมผล" ในมุมมองของตัวเอง แต่เมื่อร้อยเรียงเข้าด้วยกันเป็นเส้นทางการโจมตีข้ามทั้ง 5 ระบบ มันคือหายนะชัดๆ

สิ่งนี้ตอกย้ำให้เห็นว่า การตรวจสอบเรื่องตัวตนและการเข้าถึง (Identity and Access Reviews) จำเป็นต้องมองตามแนวเส้นทางการโจมตีที่ตัดผ่านขอบเขตของระบบต่างๆ ไม่ใช่แค่ตรวจสอบสิทธิ์ของแต่ละส่วนประกอบแบบแยกส่วน องค์กรจำเป็นต้องมีการตรวจสอบความปลอดภัยข้ามทีม เพื่อหาจุดที่การตั้งค่าที่ดูไม่มีพิษภัยของแต่ละทีม เมื่อนำมาประกอบรวมกันแล้ว จะกลายเป็นห่วงโซ่การโจมตีที่ร้ายแรงได้อย่างไร