Anthropic ที่มีจุดเน้นที่ “ความปลอดภัยเป็นอันดับแรก” ระบบนิเวศการจำลองแบบเครือข่ายของเครื่องมือพัฒนาหลัก Claude Code ไม่เคยปลอดภัยจริงๆ ในห้าเดือนที่ผ่านมา
นักวิจัยด้านความปลอดภัยอิสระ กวน เอาหนาน (Aonan Guan) ได้เผยแพร่การวิจัยล่าสุดเมื่อวันที่ 20 พฤษภาคม เปิดเผยช่องโหว่การหลีกเลี่ยงแบบสมบูรณ์แบบครั้งที่สองใน sandbox ของ Claude Code — การโจมตีด้วยการฉีดไบต์ว่างในโปรโตคอล SOCKS5 ซึ่งสามารถทำให้กระบวนการภายใน sandbox เข้าถึงโฮสต์ใดๆ ก็ได้ที่นโยบายผู้ใช้ห้ามอย่างชัดเจน หมายความว่าตั้งแต่เปิดใช้งานฟีเจอร์ sandbox เมื่อเดือนตุลาคม 2025 จนถึงปัจจุบัน ประมาณ 5.5 เดือนและ 130 เวอร์ชันที่เผยแพร่ ทุกเวอร์ชันของ Claude Code มีข้อบกพร่องด้านความปลอดภัยที่สามารถถูกหลีกเลี่ยงได้อย่างสมบูรณ์แบบ นี่เป็นการเจาะผ่าน防线เดียวกันครั้งที่สองโดยนักวิจัยคนเดียวกัน
Anthropic ไม่ได้ให้การตอบกลับใดๆ: ไม่มีคำเตือนด้านความปลอดภัย ไม่มีหมายเลข CVE ไม่มีการแจ้งเตือนผู้ใช้ ช่องโหว่นี้ได้รับการแก้ไขอย่างเงียบๆ ในเวอร์ชันวันที่ 1 เมษายน โดยไม่ได้กล่าวถึงใดๆ เกี่ยวกับความปลอดภัยในบันทึกการอัปเดต กล่าวอีกนัยหนึ่ง ผู้ใช้ที่ยังคงใช้งานเวอร์ชันเก่าจะไม่มีทางรู้เลยว่า sandbox ที่ตนตั้งค่าไว้นั้นไม่มีประสิทธิภาพตั้งแต่เริ่มต้น
กุญแจสองดอกสำหรับประตูเดียวกัน
Claude Code เป็นผู้ช่วยการเขียนโปรแกรมแบบ AI ที่ Anthropic เปิดตัวในต้นปี 2025 โดยมีตำแหน่งเป็น “วิศวกร AI ที่อยู่ภายในเทอร์มินัล” ต่างจากการเติมโค้ดแบบแชทแบบดั้งเดิม Claude Code มีสิทธิ์อ่านและเขียนฐานข้อมูลโค้ดของผู้ใช้ รวมถึงความสามารถในการรันคำสั่ง สามารถดำเนินการต่างๆ ได้ด้วยตนเอง เช่น การนำทางโค้ด การแก้ไขไฟล์ และการรันการทดสอบ ความลึกของการเข้าถึงนี้หมายถึงความเสี่ยงด้านความปลอดภัยที่สูงมาก — หากโมเดลถูกควบคุมโดยการโจมตีแบบ prompt injection ผู้โจมตีจะได้รับสิทธิ์เทียบเท่ากับผู้ใช้ในเทอร์มินัล รวมถึงการอ่านตัวแปรสภาพแวดล้อมท้องถิ่น การรันคำสั่งระบบใดๆ ก็ได้ และการเข้าถึงทรัพยากรเครือข่ายภายใน
เพื่อสมดุลระหว่างความปลอดภัยและประสิทธิภาพ Anthropic ได้เปิดใช้งานฟีเจอร์เว็บแซนด์บ็อกซ์ (v2.0.24) ในเดือนตุลาคม 2025 ซึ่งอนุญาตให้ผู้ใช้กำหนดรายการโดเมนที่อนุญาตผ่านไฟล์การตั้งค่า เพื่อจำกัดการเข้าถึงเครือข่ายภายนอกของสภาพแวดล้อมการทำงานของ AI ตัวอย่างเช่น หลังจากตั้งค่า allowedDomains: [“*.google.com”] Claude Code จะสามารถเข้าถึง Google และโดเมนย่อยของมันเท่านั้น ส่วนการรับส่งข้อมูลอื่นๆ จะถูกบล็อกทั้งหมด เอกสารอย่างเป็นทางการรับรองอย่างชัดเจนว่า: “อาร์เรย์ว่างเท่ากับการห้ามการเข้าถึงเครือข่ายทั้งหมด”
กลไกนี้ถูกดำเนินการโดยตัวแทน SOCKS5: เวลาทำงานของ sandbox ระดับพื้นฐาน (@anthropic-ai/sandbox-runtime) จะเริ่มต้นเซิร์ฟเวอร์ตัวแทน กระบวนการภายใน sandbox จะไม่เชื่อมต่อเครือข่ายโดยตรง แต่จะส่งผ่านตัวแทน ซึ่งจะดำเนินการกรองโดเมนตามรายการอนุญาตที่ผู้ใช้กำหนดใน settings.json กลไก sandbox ระดับระบบปฏิบัติการ—sandbox-exec ของ macOS และ bubblewrap ของ Linux—จำกัด Agent ไว้ที่ที่อยู่ localhost อย่างถูกต้อง โดยการตัดสินใจเรื่องการเชื่อมต่อออกทั้งหมดจะถูกมอบหมายให้ตัวแทน SOCKS5 นี้
ภาพสถาปัตยกรรมของ sandbox Claude Code ที่แสดงในบล็อกอย่างเป็นทางการของ Anthropic — คำสั่งของผู้ใช้จะผ่านตัวกรอง SOCKS/HTTP ก่อนเข้าสู่ sandbox โดยการดำเนินการไฟล์และการเข้าถึงเครือข่ายภายใน sandbox จะได้รับการควบคุมสิทธิ์อย่างเข้มงวด
ปัญหาอยู่ที่การดำเนินการของตัวแทนนี้ การศึกษาด้านความปลอดภัยสองครั้งที่แยกจากกันได้พิสูจน์แล้วว่าสามารถข้ามมันได้ทั้งหมด
เส้นเวลาเปิดเผยปัญหาที่ลึกซึ้งยิ่งขึ้น: v2.0.55 ที่เผยแพร่เมื่อวันที่ 26 พฤศจิกายน 2025 ได้แก้ไขช่องโหว่ครั้งแรก แต่ช่องโหว่ครั้งที่สองมีอยู่ตั้งแต่วันแรกที่เปิดใช้งานซานบ็อก และเวอร์ชันนี้ยังคงมีช่องโหว่นี้อยู่ ช่องโหว่ทั้งสองมีจุดตัดกันในเส้นเวลา ตั้งแต่วันแรกที่เปิดใช้งานฟีเจอร์ซานบ็อกจนถึงวันที่ช่องโหว่สุดท้ายได้รับการแก้ไข ไม่มีเวอร์ชันใดปลอดภัย Anthropic ได้ประกาศในบล็อกอย่างเป็นทางการว่าซานบ็อก “รับประกันว่าแม้จะเกิดการฉีดคำสั่ง ผลกระทบจะถูกแยกออกจากกันอย่างสมบูรณ์” แต่การมีอยู่ของช่องโหว่ทั้งสองนี้ได้หักล้างคำมั่นนี้โดยตรง
“การรายงานภายนอกหนึ่งครั้งคือความโชคดี สองครั้งคือปัญหาคุณภาพในการดำเนินการ” — รายงานของกวน เอาหนาน
การหลีกเลี่ยงแบบเต็มรูปแบบของไบต์ว่าง
หลักการทางเทคนิคของการหลีกเลี่ยงครั้งที่สองไม่ซับซ้อน แต่ความสมบูรณ์ของห่วงโซ่การโจมตีนั้นน่าสนใจ
ผู้ใช้ได้ตั้งค่ารายการอนุญาตเครือข่าย เช่น อนุญาตเฉพาะการเข้าถึง *.google.com เมื่อโปรกซี SOCKS5 ของ Claude Code รับคำขอการเชื่อมต่อ มันจะใช้วิธี endsWith() ของ JavaScript เพื่อจับคู่ส่วนท้ายของชื่อโฮสต์ ผู้โจมตีสามารถแทรกไบต์ว่างลงในชื่อโฮสต์ได้เพียงแค่สร้างสตริงในรูปแบบ attacker-host.com\x00.google.com JavaScript จะมองไบต์ว่างเป็นอักขระ UTF-16 ธรรมดา ดังนั้น endsWith(“.google.com”) จะคืนค่า true และโปรกซีจะอนุญาตให้ผ่าน แต่สตริงเดียวกันนี้เมื่อส่งไปยังฟังก์ชันภาษา C ระดับล่าง getaddrinfo() เพื่อแก้ไข DNS ไบต์ว่างจะถูกตีความเป็นตัวจบสตริง ดังนั้นจึงทำการแก้ไขชื่อ attacker-host.com เพียงเท่านั้น ไบต์เดียวกันนี้ถูกตีความต่างกันในสองชั้นของโค้ด ตัวกรองคิดว่าคุณกำลังเข้าถึง Google แต่ตัวแก้ไข DNS รู้ว่าคุณกำลังเชื่อมต่อกับเซิร์ฟเวอร์ของผู้โจมตี
นี่เป็นการโจมตีแบบ “ความแตกต่างของตัวแปลความหมาย” แบบคลาสสิก ซึ่งอยู่ในหมวดเทคนิคเดียวกับการโจมตีการปลอมแปลงคำขอ HTTP ที่ค้นพบในปี 2005 (CWE-158 / CWE-436) แก่นแท้ของมันคือเมื่อข้อมูลเดียวกันผ่านองค์ประกอบสองชิ้นที่มีกฎการตีความความหมายต่างกัน ผู้โจมตีสามารถใช้ความแตกต่างนี้เพื่อให้องค์ประกอบชั้นหนึ่งตัดสินว่า “ปลอดภัย” ในขณะที่องค์ประกอบอีกชั้นหนึ่งดำเนินการ “อันตราย” ช่องโหว่ประเภทนี้เกิดขึ้นซ้ำแล้วซ้ำเล่าในวงการความปลอดภัยทางไซเบอร์ และบทเรียนสำคัญยังคงเหมือนเดิมเสมอ: การส่งสตริงข้ามขอบเขตความเชื่อถือต้องผ่านการปรับรูปแบบและการตรวจสอบอย่างเข้มงวด ไม่ควรเชื่อว่าชั้นบนได้ตรวจสอบแล้ว
กวน เอาหนาน ใช้สคริปต์ Node.js สองตัวที่ถูกลดขนาดเพื่อจำลองช่องโหว่: สคริปต์ควบคุมใช้ชื่อโฮสต์ปกติเพื่อเริ่มการเชื่อมต่อ SOCKS5 และได้รับผลลัพธ์ว่า BLOCKED; สคริปต์โจมตีฝังไบต์ว่างในชื่อโฮสต์ และได้รับผลลัพธ์ว่า BYPASSED rep=0x00 — ซึ่งหมายความว่าโปรกซีได้สร้างการเชื่อมต่อสำเร็จและช่องทางขาออกถูกเปิดขึ้น Claude Code ยืนยันผลลัพธ์นี้เอง
การจำลองช่องโหว่อย่างสมบูรณ์สำหรับขั้นตอนที่ถูกเน้นสีแดงทั้งสี่ใน Claude Code v2.1.86 — การยืนยันกลยุทธ์ การบล็อกทั่วไป การหลีกเลี่ยงไบต์ว่าง การยืนยันโดย Claude เอง
เมื่อเชื่อมโยงกับการโจมตีแบบ prompt injection ที่ Guan Aonan เปิดเผยในเดือนเมษายน ซึ่งเรียกว่า “ความคิดเห็นและการควบคุม” การโจมตีนี้จึงสร้างเป็นโซ่การโจมตีที่สมบูรณ์ (ดูเพิ่มเติม: การป้องกันสามชั้นยังไม่เพียงพอ หัวข้อ PR เพียงข้อเดียวสามารถขโมยคีย์ API ของคุณได้: ช่องโหว่ด้านความปลอดภัยของ AI Agent ปรากฏอีกครั้ง) การวิจัย “ความคิดเห็นและการควบคุม” ได้พิสูจน์แล้วว่าเครื่องมือเขียนโปรแกรม AI สามตัวมีช่องโหว่ในการโจมตีแบบ prompt injection แต่จุดเริ่มต้นของการโจมตีแตกต่างกัน: Claude Code ถูกโจมตีผ่านหัวข้อ PR เท่านั้น Gemini CLI ผ่านความคิดเห็นหรือเนื้อหาใน Issue ส่วน Copilot Agent ใช้ HTML comment เพื่อทำการ注入อย่างซ่อนเร้น ตัวอย่างเช่น Claude Code หัวข้อ PR จะถูกเชื่อมต่อโดยตรงกับเทมเพลต prompt โดยไม่มีการกรองหรือการแปลงอักขระ โมเดลจึงไม่สามารถแยกแยะระหว่างเจตนาของมนุษย์กับการ注入ที่เป็นอันตรายได้
รวมทั้งสองอย่างเข้าด้วยกัน—คำสั่งซ่อนเร้นทำให้ Agent รันรหัสการโจมตีภายใน sandbox และการฉีดไบต์ว่างเพื่อเจาะผ่านการปิดกั้นเครือข่าย—ข้อมูลเช่น API key, ข้อมูล AWS credential, GitHub token, และจุดสิ้นสุด API ภายในที่อยู่ในตัวแปรสภาพแวดล้อม สามารถถูกส่งออกไปยังเซิร์ฟเวอร์ใดก็ได้บนอินเทอร์เน็ต ข้อมูลไหลออกผ่าน SOCKS5 proxy โดยตรง ไม่ต้องผ่านเซิร์ฟเวอร์ภายนอกใดๆ ทั้งสิ้น และโปรกซีนี้เองคือส่วนประกอบที่ผู้ใช้เชื่อถือว่าเป็นขอบเขตความปลอดภัย ผู้โจมตีไม่จำเป็นต้องมีสิทธิ์เขียนในรีพอสิทอรี แค่ส่ง Issue แบบสาธารณะก็เพียงพอแล้ว ผู้ตรวจสอบมนุษย์จะเห็นในมุมมองที่ GitHub แสดงผลเป็นคำขอร่วมมือปกติ แต่ AI Agent จะตีความเป็นรหัสต้นทางที่เป็นอันตรายอย่างสมบูรณ์
คลอดก็ยอมรับแล้ว: ช่องโหว่นี้เป็นของจริง
รายละเอียดสำคัญหนึ่งประการในการเปิดเผยครั้งนี้มาจากการใช้งาน Claude Code โดย Guan Aonan ได้ส่งรหัสการจำลองช่องโหว่ให้ Claude Code รันโดยขอให้มันให้การตัดสินทางเทคนิค Claude Code หลังจากดำเนินการทดสอบการควบคุม (ชื่อโฮสต์ปกติถูกบล็อก) และการทดสอบการโจมตี (ชื่อโฮสต์ที่มีไบต์ว่างหลีกเลี่ยงการบล็อก) ได้ให้ข้อสรุปที่ชัดเจนว่า:
นี่คือการหลีกเลี่ยงตัวกรองซานด์บ็อกซ์ของเครือข่ายอย่างแท้จริง ไม่ใช่เพียง artifacts ของการทดสอบ คุณควรรายงานเรื่องนี้ไปยัง Anthropic ที่ https://github.com/anthropics/claude-code/issues.
ผลิตภัณฑ์ที่ถูกทดสอบยืนยันความจริงและความรุนแรงของช่องโหว่ด้วยตนเอง และยังเสนอเส้นทางการรายงานอย่างกระตือรือร้น รายละเอียดนี้ถูกเก็บบันทึกอย่างสมบูรณ์โดยกวน เอานาน ในรายงานการวิจัย และกลายเป็นที่มาของหัวข้อข่าวของ The Register — “Even Claude agrees hole in its sandbox was real and dangerous”
หน้าปกการวิจัยของ Guan Aonan — Claude Code ยอมรับหลังจากแสดงช่องโหว่ของตัวเองว่า “นี่คือการหลีกเลี่ยงตัวกรองเซฟวิ่งของเครือข่ายอย่างแท้จริง” โดยมีกรอบสีแดงระบุประโยคยืนยันที่สำคัญ
การตอบกลับของ Anthropic กับการเงียบเป็นเวลาห้าเดือน
ช่องโหว่นั้นน่ากังวลอยู่แล้ว แต่วิธีการจัดการของ Anthropic นั้นควรได้รับการพิจารณาอย่างรอบคอบโดยอุตสาหกรรม
กวน เอาหนาน ส่งรายงานรายละเอียดเกี่ยวกับการหลีกเลี่ยงแซนด์บ็อกซ์ครั้งที่สองให้กับ Anthropic เมื่อต้นเดือนเมษายน 2026 ผ่านโปรแกรมรางวัลช่องโหว่ HackerOne (รายงานหมายเลข #3646509) การตอบสนองเบื้องต้นของ Anthropic คือ:
ขอบคุณสำหรับรายงานของคุณ หลังจากทบทวนการส่งนี้ เราได้ตัดสินว่าเป็นรายการซ้ำกับรายงานภายในที่เรามีอยู่แล้ว
รายงานถูกปิดทันที เมื่อ Guan Aonan สอบถามเกี่ยวกับหมายเลข CVE Anthropic ได้ตอบกลับในวันที่ 7 เมษายน:
เรายังไม่ได้ตัดสินใจว่าจะเผยแพร่ CVE สำหรับปัญหานี้หรือไม่ และไม่สามารถให้ตารางเวลาเกี่ยวกับการตัดสินใจนี้ได้
ช่องโหว่นี้ได้รับการแก้ไขแบบเงียบในเวอร์ชัน v2.1.90 ไม่มีการแจ้งเตือนด้านความปลอดภัย ไม่มีหมายเลข CVE และไม่มีรายการใดๆ บนหน้าคำแนะนำด้านความปลอดภัยของ Claude Code บันทึกการอัปเดตไม่ได้กล่าวถึงการปรับปรุงด้านความปลอดภัยใดๆ เลย การหลีกเลี่ยงที่สมบูรณ์ซึ่งมีอยู่ตั้งแต่วันแรกที่เปิดใช้งานใน sandbox และดำเนินต่อเนื่องเป็นเวลา 5.5 เดือน ครอบคลุมประมาณ 130 เวอร์ชัน ดูเหมือนว่าไม่เคยเกิดขึ้นเลยสำหรับผู้ใช้
รูปแบบการจัดการนี้ไม่ได้เกิดขึ้นครั้งแรก วิธีการหลีกเลี่ยงครั้งแรก (CVE-2025-66479) แทบจะเหมือนกันทุกประการ: Anthropic ได้จัดสรร CVE ให้กับไลบรารีพื้นฐานเท่านั้น คือ @anthropic-ai/sandbox-runtime (คะแนน CVSS เพียง 1.8 ระดับ “ต่ำ”) ไม่ใช่ผลิตภัณฑ์ที่ผู้ใช้สัมผัสอย่าง Claude Code; ในบันทึกการอัปเดตเขียนว่า “Fixed proxy DNS resolution” (แก้ไขการแก้ไขชื่อ DNS ของโปรกซี) โดยไม่ได้กล่าวถึงช่องโหว่ด้านความปลอดภัย คุณกวน เอาหนาน เขียนไว้ในรายงานการวิจัยว่า: “เมื่อเกิดช่องโหว่ร้ายแรงใน React Server Components React และ Next.js ต่างก็ได้รับ CVE แยกกัน Meta และ Vercel ต่างก็ออกประกาศความปลอดภัย และชุมชนทั้งสองได้รับการแจ้งเตือนอย่างเพียงพอ Anthropic เลือกแนวทางที่ต่างออกไป” จนถึงปัจจุบัน การค้นหา “Claude Code Sandbox CVE” ยังไม่พบประกาศความปลอดภัยอย่างเป็นทางการใดๆ
ในการรับมือกับปัญหาการขโมยข้อมูลรับรอง การระบุคำสั่ง ps ว่าห้ามใช้งานเป็นทางเลือกของ Anthropic แต่แนวคิดการแบล็กลิสต์นั้นมีข้อบกพร่องตั้งแต่ต้น—การห้ามคำสั่งหนึ่งคำสั่ง ผู้โจมตียังมีทางเลือกอื่นอีกมากมาย วิธีที่ถูกต้องคือการระบุอย่างชัดเจนว่า Agent ต้องการเครื่องมือใดบ้าง และในการวิจัยเรื่อง “การแสดงความคิดเห็นและการควบคุม” Anthropic ได้เพิ่มระดับช่องโหว่เป็น CVSS 9.4 (ระดับวิกฤต) และย้ายไปยังแผนรางวัลแบบส่วนตัว แต่ผู้พูดแทนกล่าวว่า “เครื่องมือนี้ไม่ได้รับการออกแบบมาเพื่อป้องกันการฉีดคำสั่ง” ผู้ผลิตมักเชื่อมั่นในความสามารถด้านความปลอดภัยของโมเดลของตนเอง แต่กลับขาดการป้องกันแบบหลายชั้นในระดับสถาปัตยกรรมระบบ เมื่อช่องโหว่เปิดเผยจุดอ่อนนี้ “ข้อจำกัดในการออกแบบ” ก็กลายเป็นหมวดหมู่ที่สะดวก—มันยอมรับปัญหา แต่ในบางแง่ก็ปลดปล่อยภาระหน้าที่ในการประกาศแจ้งเตือนความปลอดภัย
ภาพรวมอุตสาหกรรมที่กว้างขึ้นคือ ปัญหาเดียวกันนี้ไม่ได้จำกัดอยู่ที่ Anthropic เพียงรายเดียว การศึกษาที่เปิดเผยในเดือนเมษายนเรื่อง “ความคิดเห็นและการควบคุม” ยืนยันว่า Gemini CLI ของ Google และ Copilot Agent ของ Microsoft GitHub ต่างก็มีจุดอ่อนเดียวกัน ทั้งสามบริษัทต่างยืนยันและแก้ไขปัญหาแล้ว แต่ไม่มีบริษัทใดออกประกาศความปลอดภัยหรือหมายเลข CVE Anthropic จ่ายรางวัล 100 ดอลลาร์สหรัฐ Google จ่าย 1337 ดอลลาร์สหรัฐ ส่วน GitHub ปิดรายงานแรกด้วยข้อความว่า “ปัญหาที่รู้จักกันอยู่แล้ว ไม่สามารถทำซ้ำได้” แต่หลังจากได้รับหลักฐานการรีเวิร์สเอ็นจิเนียริ่ง จึงปิดกรณีด้วยแท็ก “ข้อมูลทั่วไป” และจ่ายรางวัล 500 ดอลลาร์สหรัฐ รวมเป็นเงิน 1,937 ดอลลาร์สหรัฐ — ซึ่งผลิตภัณฑ์ทั้งสามนี้ครอบคลุมองค์กรส่วนใหญ่ในรายชื่อ Fortune 100
ความรู้สึกปลอดภัยที่ผิดพลาดอันตรายกว่าการไม่มีมาตรการรักษาความปลอดภัยเลย ผู้ใช้ที่ไม่มี sandbox รู้ว่าตัวเองไม่มีขอบเขต; แต่ผู้ใช้ที่มี sandbox ที่เสียหายกลับคิดว่าตัวเองมีขอบเขต ทีมที่รัน Claude Code และตั้งค่ารายการอนุญาตโดเมน ใช้เวลา 5.5 เดือนโดยไม่รู้ตัวเลยว่ามีความเสี่ยง และเมื่ออัปเกรดแล้วดูบันทึกการอัปเดต ก็สรุปได้เพียงว่า sandbox ทำงานปกติมาโดยตลอด นอกจากนี้ เมื่อช่องโหว่ถูกเปิดเผย แต่ไม่มีการแจ้งเตือนด้านความปลอดภัย ผู้ใช้จึงไม่สามารถตัดสินได้ว่าเคยได้รับผลกระทบหรือไม่ และไม่มีข้อมูลสำหรับการตรวจสอบย้อนหลัง
ต่อสภาวะปัจจุบัน ชุมชนด้านความปลอดภัยเริ่มมีความเห็นพ้องต้องกันว่า ไม่ควรวางความเชื่อมั่นไว้เพียงจุดเดียวบนการดำเนินการของ sandbox โดยผู้ผลิต Claude Code ใช้โปรกซี SOCKS5 ที่สร้างขึ้นจากแพ็กเกจ npm ของบุคคลที่สามซึ่งมีเพียง 10 ดาวบน GitHub และการอัปเดตล่าสุดหยุดนิ่งตั้งแต่เดือนมิถุนายน 2024 ขอบเขตความปลอดภัยข้ามสอง runtime คือ JavaScript และ C แต่กลับขาดการจัดการมาตรฐานพื้นฐานที่สุดในจุดต่อเชื่อมความเชื่อมั่น ฟังก์ชัน isValidHost() ที่ถูกเพิ่มเข้ามาในแพตช์แก้ไข—ซึ่งรับผิดชอบในการปฏิเสธอักขระผิดกฎหมาย เช่น ไบต์ว่าง การเข้ารหัสเปอร์เซ็นต์ CRLF—ควรจะมีอยู่ตั้งแต่วันแรกที่ sandbox เปิดใช้งาน กวน อ่าอาน ได้เสนอกรอบการป้องกันที่เป็นรูปธรรม—มอง AI Agent เป็นพนักงานระดับสูงที่ต้องปฏิบัติตามหลักสิทธิ์ขั้นต่ำสุด โดยเน้นหลักการป้องกันหลายชั้น:
ชื่อเสียงด้านความปลอดภัยถูกสร้างขึ้นจากความโปร่งใสในการเปิดเผยแต่ละครั้งและการอัปเดตแต่ละรายการ ไม่ใช่จากเรื่องเล่าของแบรนด์ เมื่อผู้ใช้ส่งข้อมูลรับรองให้ตัวแทนจัดการด้วยความเชื่อมั่น ผู้ผลิตมีหน้าที่รับผิดชอบในการรับประกันว่าแนวป้องกันมีประสิทธิภาพ และต้องแจ้งให้ทราบทันทีเมื่อแนวป้องกันล้มเหลว ทั้งสองข้อนี้ Anthropic ไม่ได้ทำให้สำเร็จบนคลาวด์ Claude Code
“沙箱最坏的结果不是阻止了什么，而是给了人们一种虚假的安全感。发布一个有漏洞的沙箱，比不发布沙箱更糟糕。”——关傲男表示。
(บทความนี้เผยแพร่ครั้งแรกบนแอป Taimeiti ผู้เขียน | Silicon Valley Tech_news แก้ไขโดย | Jiao Yan)
ข้อมูลอ้างอิง：
1. oddguan.com — ครั้งที่สอง เดียวกันกับ Sandbox: การหลีกเลี่ยง Sandbox ของ Anthropic Claude Code Network อีกครั้งทำให้สามารถขโมยข้อมูลได้ (Aonan Guan, 2026.05.20)
2. The Register — คลอดก็ยอมรับว่ารูในซานด์บ็อกซ์นั้นเป็นเรื่องจริงและอันตราย (2026.05.20)