การยึดเครื่องผ่านโหมดอนุมัติอัตโนมัติของ Claude Code (ส.ค. 2026)

เมื่อวันที่ 26 ส.ค. 2026 มีรายงานวิจัยที่สาธิตการยึดเครื่องผ่านผู้ช่วยเขียนโค้ด Claude Code ขณะทำงานในโหมดอนุมัติอัตโนมัติ โดยไม่ต้องหลอกให้คนกดอนุมัติอะไรเลย (embracethered · Simon Willison)

เรื่องนี้สำคัญกับคนทั่วไปเพราะโหมดอนุมัติอัตโนมัติไม่ใช่ของที่ต้องไปเปิดเองอีกแล้ว Anthropic ประกาศเมื่อวันที่ 7 ส.ค. 2026 ว่าตั้งแต่วันที่ 14 ส.ค. เซสชันใหม่บนแพ็กเกจ Pro, Max และ Team จะทำงานในโหมดนี้เป็นค่าเริ่มต้น ส่วนลูกค้าองค์กร ผู้ใช้ผ่านชุดคำสั่งโดยตรง และผู้ใช้ผ่านคลาวด์พาร์ตเนอร์ยังต้องเปิดเอง (Anthropic)

ลำดับการโจมตีทำงานอย่างไร

ขั้นแรกคือการดันให้ผู้ช่วยเปลี่ยนเครื่องมือ เซิร์ฟเวอร์ของผู้โจมตีตอบรหัส HTTP 415 ซึ่งแปลว่าไม่รองรับรูปแบบข้อมูลที่ขอมา ผู้ช่วยจึงเลิกใช้เครื่องมือดึงหน้าเว็บที่ติดมาในตัว แล้วหันไปสั่งดาวน์โหลดด้วยคำสั่งทั่วไปแทน

ขั้นที่สองคือการส่งของ เซิร์ฟเวอร์เปลี่ยนเส้นทางไปยังไฟล์บีบอัดที่ข้างในมีสามอย่าง คือข้อมูลที่เข้ารหัสไว้ ไฟล์โปรแกรมสำหรับถอดรหัส และไฟล์ที่ตั้งชื่อทับชื่อโมดูลมาตรฐานของภาษา Python

ขั้นที่สามคือจุดที่พลิก ผู้ช่วยเห็นไฟล์โปรแกรมสำหรับถอดรหัสแล้วปฏิเสธที่จะรัน ซึ่งเป็นพฤติกรรมที่ถูกต้องตามที่ถูกฝึกมา แต่แทนที่จะหยุด มันเขียนตัวถอดรหัสของตัวเองขึ้นมาแทน ผู้วิจัยชี้ว่าไฟล์โปรแกรมนั้นทำหน้าที่เป็นตัวล่อ และการตัดสินใจไม่รันมันคือสิ่งที่ผลักโมเดลเข้าสู่เขตอันตราย

ขั้นที่สี่คือการรันโค้ดโดยที่ไม่มีใครสั่งรัน ตัวถอดรหัสที่ผู้ช่วยเขียนเองเรียกใช้โมดูลมาตรฐานตัวหนึ่ง ซึ่งไปเรียกโมดูลอีกตัวต่อ และเนื่องจาก Python ใส่โฟลเดอร์ที่เพิ่งแตกไฟล์ออกมาไว้ในเส้นทางค้นหาโมดูล มันจึงหยิบไฟล์ของผู้โจมตีที่ตั้งชื่อทับไว้ขึ้นมารันแทนของจริง

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

ทำไมตัวคัดกรองถึงไม่จับ

จุดที่อธิบายเรื่องนี้ได้ดีที่สุดคือทุกขั้นตอนของลำดับนี้อยู่ในสิ่งที่โหมดอนุมัติอัตโนมัติอนุญาตไว้อยู่แล้ว เอกสารของ Claude Code ระบุว่าคำขอ HTTP แบบอ่านอย่างเดียวเป็นสิ่งที่อนุญาตโดยค่าเริ่มต้น ส่วนสิ่งที่ตัวคัดกรองบล็อกคือการดาวน์โหลดแล้วรันโค้ดในจังหวะเดียวกันแบบที่มองเห็นได้ชัด (Claude Code docs · auto mode config)

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

ผู้วิจัยสรุปจุดยืนของฝั่งผู้ผลิตไว้เองว่าลำดับการแทรกคำสั่งที่ตั้งใจทำและประกอบขึ้นจากขั้นตอนที่ดูไม่มีพิษภัย ไม่ใช่สิ่งที่ตัวคัดกรองถูกออกแบบมาให้หยุด

ตัวเลขและสิ่งที่ตัวเลขไม่ได้บอก

ผู้วิจัยรายงานอัตราความสำเร็จแยกตามรูปแบบของการโจมตีสามแบบ คือ 3 จาก 5 รอบ 3 จาก 5 รอบ และ 4 จาก 5 รอบ พร้อมระบุเองว่าเป็นกลุ่มตัวอย่างเล็ก ไม่ใช่การวัดอัตราความสำเร็จแบบครอบคลุม

ตัวเลข 80 เปอร์เซ็นต์ที่ถูกอ้างถึงในการรายงานข่าวคือรูปแบบที่ทำได้ดีที่สุดในสามแบบนั้น ไม่ใช่ค่าเฉลี่ยของทั้งชุด

สิ่งที่ผู้วิจัยเน้นมากกว่าอัตราความสำเร็จคือพฤติกรรมของตัวกันภัยเอง เขารายงานว่าในบางรอบ หลังผู้ช่วยรู้ตัวว่าถูกเจาะแล้วพยายามสั่งหยุดกระบวนการของมัลแวร์ โหมดอนุมัติอัตโนมัติกลับปฏิเสธคำสั่งล้างนั้น

ตัวเลขศูนย์ที่อยู่ร่วมกับการยึดเครื่องได้

ก่อนหน้านี้ Anthropic เคยเผยแพร่ผลประเมินที่ระบุอัตราการโจมตีสำเร็จ 0.00 เปอร์เซ็นต์สำหรับ Opus 5 ในโหมดอนุมัติอัตโนมัติ โดยผู้ประเมินคือผู้ให้บริการภายนอกที่บริษัทจ้างมา ทดสอบการแทรกคำสั่งทางอ้อม 72 สถานการณ์ สถานการณ์ละสิบครั้ง

ผู้วิจัยระบุว่าลำดับการโจมตีของเขาไม่ได้อยู่ในชุด 72 สถานการณ์นั้น ตัวเลขศูนย์บนกระดานคะแนนกับการยึดเครื่องที่ทำได้จริงจึงเป็นความจริงพร้อมกันได้ ซึ่งเป็นบทเรียนเรื่องการอ่านผลเบนช์มาร์กความปลอดภัยที่ใช้ได้กว้างกว่ากรณีนี้ คือเลขศูนย์บอกได้แค่ว่าไม่มีอะไรในชุดที่ทดสอบเจาะสำเร็จ ไม่ได้บอกว่าไม่มีอะไรเจาะได้

ผู้ผลิตตอบอย่างไร

ผู้วิจัยระบุว่าเขาส่งรายงานไปที่อีเมลรับแจ้งช่องโหว่ของโมเดลก่อนแล้วไม่ได้รับการตอบกลับ จากนั้นจึงส่งผ่านช่องทางรับแจ้งด้านความปลอดภัยและได้รับการตอบกลับอย่างรวดเร็ว

Anthropic ปิดรายงานนี้ด้วยสถานะว่าเป็นข้อมูลที่เป็นประโยชน์ และถือว่าพฤติกรรมที่พบเป็นไปตามที่ออกแบบไว้

ข้อที่ต้องแยกให้ชัดคือคำอธิบายที่ว่าโหมดนี้เป็นฟีเจอร์เพื่อความสะดวกที่มีตัวคัดกรองแบบทำเต็มที่เท่าที่ทำได้อยู่เบื้องหลัง ไม่ใช่การรับประกันความปลอดภัย และเส้นแบ่งความปลอดภัยที่แท้จริงคือการแยกระบบปฏิบัติการกับการคุมทางออกของเครือข่าย เป็นคำสรุปที่ผู้วิจัยเขียนขึ้นเองเพื่ออธิบายจุดยืนของอีกฝ่าย ไม่ใช่ถ้อยแถลงที่ผู้ผลิตเผยแพร่ออกมา

สิ่งที่ทำได้จริงเพื่อลดความเสี่ยง

ผู้วิจัยเสนอชุดมาตรการที่ตรงกับสถาปัตยกรรมของปัญหา คือรันผู้ช่วยเขียนโค้ดที่ทำงานทิ้งไว้โดยไม่มีคนดูภายในกล่องแยก เครื่องเสมือน หรือกล่องทรายของระบบปฏิบัติการ จำกัดทางออกของเครือข่าย เฝ้าดูสิ่งที่ผู้ช่วยทำ ตั้งกฎอนุญาตและกฎปฏิเสธที่ชัดเจนรอบการสร้างกระบวนการใหม่และรอบเส้นทางไฟล์ที่อ่อนไหว และอย่าให้ผู้ช่วยมองเห็นโฟลเดอร์บ้าน กุญแจเข้าระบบระยะไกล หรือรหัสผ่านของบริการคลาวด์

ข้อที่เขาสรุปไว้สั้นที่สุดและใช้เป็นหลักได้คืออย่าถือว่าการที่โหมดอนุมัติอัตโนมัติปล่อยผ่าน เป็นหลักฐานว่าโค้ดนั้นปลอดภัย

ในทางเครื่องมือ Claude Code รุ่น 2.1.248 เพิ่มโหมดจำกัดสิทธิ์ที่ถอดเครื่องมือรันโค้ดในตัวและเครื่องมือดึงหน้าเว็บออก แล้วจำกัดการอ่านเขียนไฟล์ให้อยู่ในโฟลเดอร์ที่ทำงานอยู่เท่านั้น ซึ่งตัดสองความสามารถที่ลำดับการโจมตีนี้พึ่งอยู่ (CHANGELOG)

เรื่องนี้ต่อกับอะไรในคลัง

หลักการเดียวกับที่เจอใน claude-web-fetch-exfiltration และ gitlost-github-agent-injection คือข้อความจากภายนอกที่ถูกเอามาให้โมเดลอ่าน กลายเป็นคำสั่งได้ทันทีที่โมเดลมีเครื่องมือทำตาม

การที่โหมดอนุมัติอัตโนมัติกลายเป็นค่าเริ่มต้นเป็นเรื่องที่บันทึกไว้แล้วที่ claude-code-auto-mode-default หน้านี้เป็นสิ่งที่เกิดขึ้นตามมาสามสัปดาห์หลังจากนั้น

ส่วนแบบแผนของการที่ตัวเลขบนเบนช์มาร์กไม่สะท้อนความเสี่ยงจริง เป็นเรื่องเดียวกับที่บันทึกไว้ใน benchmark-harness-fragility-2026 และ every-model-cheats-cybench

คำถามที่ยังไม่มีคำตอบ

ตัวคัดกรองของโหมดอนุมัติอัตโนมัติจะถูกปรับให้จับรูปแบบการตั้งชื่อไฟล์ทับโมดูลมาตรฐานหรือไม่

จะมีผู้ทดสอบอิสระทำซ้ำลำดับการโจมตีนี้แล้วรายงานอัตราความสำเร็จบนกลุ่มตัวอย่างที่ใหญ่กว่าห้ารอบหรือไม่

ผู้ช่วยเขียนโค้ดเจ้าอื่นที่มีโหมดทำนองเดียวกัน มีช่องแบบเดียวกันหรือเปล่า