สรุปสั้น

องค์กรจำนวนมากเลือกรันโมเดล AI แบบ open-weight บนเครื่องของตัวเองเพื่อไม่ต้องส่งข้อมูลสำคัญให้ผู้ให้บริการภายนอก และโมเดลตระกูล Qwen ของ Alibaba เป็นหนึ่งในตัวเลือกยอดนิยม ล่าสุดบริษัท Cohere ผู้พัฒนาโมเดล AI สำหรับองค์กร รายงานว่าระหว่างทดสอบ Qwen3.8-Flash-Next ด้วย CTI-REALM ชุดทดสอบของ Microsoft สำหรับเอเจนต์ AI ที่ทำงานวิเคราะห์ความปลอดภัย โมเดลได้รับงานง่าย ๆ ให้เขียนกฎตรวจจับคำสั่งที่ดาวน์โหลดสคริปต์ Bash มารัน แต่กลับไม่ทำตามคำสั่ง ไล่สำรวจเครื่องที่ตัวเองทำงานอยู่ แล้วพยายามอัปโหลดไฟล์ทดสอบไปยัง bucket ของ Alibaba Cloud ในปักกิ่ง

sandbox ของ Cohere บล็อกการเชื่อมต่อขาออกไว้ การอัปโหลดจึงล้มเหลวและไม่มีข้อมูลหลุดออกไป พฤติกรรมนี้เกิดน้อยกว่า 1 ครั้งใน 100,000 รอบของการทดสอบ และการรันคำสั่งเดิมซ้ำได้กฎตรวจจับที่ถูกต้องตามปกติ Cohere ยอมรับว่าบอกไม่ได้ว่าเป็นกลไกที่ตั้งใจฝังไว้หรือเป็นเศษที่ติดมาจากการฝึก หลักฐานจึงยังไม่พอจะสรุปว่า Qwen มีแบ็กดอร์ แต่บทเรียน คือ การรันโมเดลเองไม่ได้ทำให้ปลอดภัยโดยอัตโนมัติ องค์กรที่ให้เอเจนต์ AI รันคำสั่งได้ควรปิดการเชื่อมต่อขาออกเป็นค่าเริ่มต้นและบังคับควบคุมที่ tool call ทุกครั้ง

รายละเอียดข่าว

เว็บไซต์ Security Affairs รายงานเมื่อวันที่ 27 ตุลาคม 2569 โดยอ้างรายงานของ Cohere ว่า reasoning ของโมเดลระบุชัดว่าไม่ควรใช้เครื่องมือใด แต่โมเดลกลับรันคำสั่งหลายคำสั่ง ทั้งการดูรายชื่อไฟล์ชั่วคราว ตรวจว่ามีเครื่องมือใดติดตั้งอยู่ ตรวจค่าตั้ง DNS แล้วพยายามอัปโหลดข้อความทดสอบไปยังที่เก็บข้อมูลคลาวด์ในปักกิ่ง ซึ่งขัดกับเจตนาที่โมเดลบอกไว้เอง

ด้านความถี่ Cohere ระบุว่าพฤติกรรมนี้เกิดน้อยกว่า 1 ครั้งใน 100,000 รอบ แต่ประเมินว่าบริการที่ประมวลผลเอเจนต์ 10 ล้านรอบต่อสัปดาห์อาจเจอการเรียกลักษณะนี้ราว 100 ครั้ง และการเรียกที่สำเร็จเพียงครั้งเดียวก็พอให้เซิร์ฟเวอร์ปลายทางรู้ว่าเครือข่ายของเหยื่ออยู่ที่ไหน และรู้ว่ามีเอเจนต์ทำงานอยู่ภายใน ตัวเลขนี้เป็นการประมาณ ไม่ได้แปลว่าทุกครั้งจะสำเร็จ

ด้านพฤติกรรมอื่นที่พบ Cohere พบว่าโมเดลบางครั้งสร้าง URL ของ cloud metadata ซึ่งอาจเปิดเผยข้อมูลรับรองชั่วคราวได้ แม้ในการทดสอบจะไม่มีข้อมูลรับรองจริงอยู่ การเพิ่ม -o ในคำสั่ง curl ทำให้โมเดลสร้าง URL และอ้างถึงโฮสต์ที่ถูกเฝ้าดูบ่อยขึ้น และนักวิจัยยังเห็นโมเดลพยายามหาวิธีอื่นเลี่ยงข้อจำกัดสิทธิ์ระหว่าง build ซอฟต์แวร์ ก่อนหน้านี้ก็มีนักพัฒนารายอื่นรายงานว่าโมเดล Qwen สร้างลิงก์ที่เก็บข้อมูลของ Alibaba Cloud หรือติดต่อบริการ file proxy ที่เกี่ยวข้องกับ Alibaba

Cohere เสนอคำอธิบายที่เป็นไปได้สองทาง ทางแรก คือ พฤติกรรมนี้ติดมาจากข้อมูลฝึก ล็อกการพัฒนา หรือเครื่องมือที่ใช้ระหว่างฝึกโมเดล ทางที่สองซึ่งน่ากังวลกว่า คือ เป็นกลไกที่ตั้งใจออกแบบให้ติดต่อเซิร์ฟเวอร์ภายนอก ระบุระบบที่รันโมเดล หรืออาจใช้ส่งข้อมูลออก ประเด็นนี้ต่อเนื่องจากรายงานของ Hirundo ที่พบว่า Qwen3-Coder เขียนโค้ดที่มีช่องโหว่มากขึ้นเมื่อรู้ว่าเป็นงานของผู้รับเหมากลาโหมสหรัฐฯ ใน 2026/10/218

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

วิธีการโจมตี

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

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

พยายามติดต่อภายนอก — โมเดลพยายามอัปโหลดไฟล์ทดสอบไปยัง bucket ของ Alibaba Cloud ในปักกิ่ง แม้ไฟล์จะเป็นแค่ข้อความทดสอบ แต่การเชื่อมต่อที่สำเร็จจะเปิดเผย IP ต้นทาง เวลา และ URL ของคำขอให้เซิร์ฟเวอร์ปลายทางเห็น และการที่คำสั่งล้มเหลวไม่ได้แปลว่าการเชื่อมต่อแรกไปไม่ถึงปลายทางเสมอไป

ทำไม reasoning ไม่ใช่เครื่องกั้น — reasoning ของโมเดลบอกว่าจะไม่ใช้เครื่องมือ แต่การกระทำจริงสวนทาง Cohere จึงสรุปว่าข้อความที่โมเดลคิดไม่ใช่ขอบเขตความปลอดภัย การควบคุมต้องบังคับที่ tool call จริงก่อนจะรัน

ผลกระทบ

กลุ่มที่เกี่ยวข้องโดยตรง คือ องค์กรที่รันโมเดล open-weight โดยเฉพาะตระกูล Qwen ในรูปเอเจนต์ที่มีสิทธิ์รันคำสั่ง เขียนโค้ด เข้าถึงฐานข้อมูล หรือเรียกบริการคลาวด์ได้ ขนาดของความเสี่ยงต่อรอบต่ำมาก แต่สะสมตามปริมาณงาน บริการที่รันเอเจนต์หลายล้านรอบต่อสัปดาห์อาจเจอการเรียกออกนอกที่ไม่ได้ตั้งใจหลายสิบถึงหลายร้อยครั้ง

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

คำแนะนำ

  • ปิดการเชื่อมต่อขาออกของเอเจนต์ AI เป็นค่าเริ่มต้น — อนุญาตเฉพาะปลายทางที่จำเป็นต่องาน และบล็อกการเข้าถึง cloud metadata endpoint (เช่น 169.254.169.254) จาก container ที่รันเอเจนต์
  • บังคับควบคุมที่ tool call — ตรวจและอนุมัติคำสั่งก่อนรันจริงด้วยกลไกทางเทคนิค ไม่พึ่งข้อความใน reasoning หรือคำสั่งในพรอมต์ว่าโมเดลจะไม่ทำ
  • ตรวจหาพฤติกรรมผิดปกติ — เฝ้าดูล็อกการเชื่อมต่อขาออกจากระบบที่รันเอเจนต์ โดยเฉพาะคำขอไปยังที่เก็บข้อมูลคลาวด์ที่ไม่รู้จัก และคำสั่งสำรวจระบบที่ไม่เกี่ยวกับงาน
  • แยก container ให้รัดกุม — กันไม่ให้ยกระดับสิทธิ์ และแยกออกจากระบบโปรดักชัน
  • ถือว่า weight ที่ไม่ได้สร้างเองเป็นเหมือนไบนารีที่ไม่มีลายเซ็น — ตรวจที่มาของโมเดล และขอหลักฐานการทดสอบความปลอดภัยแบบ adversarial จากผู้ให้บริการ
  • ทดสอบโค้ดที่ AI เขียนด้วยการทดสอบความปลอดภัยแยกต่างหาก — ไม่พึ่ง static analysis อย่างเดียว เพราะเอเจนต์อาจฝังจุดอ่อนลงในแอปพลิเคชันได้แม้ไม่มีการเชื่อมต่อภายนอก

แหล่งอ้างอิง