แคช Artifactory ที่ใช้ร่วมกัน กลายเป็นช่องทางลับข้ามบัญชี ChatGPT ได้อย่างไร

การบล็อกการเชื่อมต่อเครือข่ายโดยตรงไม่ได้หมายความว่าแซนด์บ็อกซ์จะแยกผู้ใช้ได้จริงเสมอไป หากทุกแซนด์บ็อกซ์ยังเข้าถึงบริการภายในตัวเดียวกันที่เขียนข้อมูลได้ นั่นคือข้อค้นพบหลักจากรายงานของ Check Point Research เกี่ยวกับปัญหาในระบบรันโค้ดของ ChatGPT ซึ่งเปิดเผยต่อ OpenAI ช่วงปลายเดือนมิถุนายน 2026 และเผยแพร่เมื่อ 8 กันยายน โดยช่องทางดังกล่าวถูกปิดไปแล้ว 56

จุดบกพร่อง: เมทาดาทาแพ็กเกจทำหน้าที่เหมือนกล่องข้อความ

Check Point ระบุว่า คอนเทนเนอร์สำหรับรันโค้ดของ ChatGPT ถูกออกแบบให้แยกจากกัน รวมถึงแยกจากอินเทอร์เน็ตสาธารณะ แต่คอนเทนเนอร์เหล่านี้ยังเข้าถึง JFrog Artifactory ภายในที่ใช้ส่งมอบแพ็กเกจได้ 6

ปัญหาไม่ได้อยู่แค่ว่า Artifactory เข้าถึงได้ แต่ Item Management API ของบริการนี้เปิดให้คอนเทนเนอร์อ่านและแก้ไขเมทาดาทาที่เปลี่ยนแปลงได้ของรายการในแคช จึงเกิด “สถานะร่วม” ที่ข้ามบัญชีได้ กล่าวคือ

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

ในทางปฏิบัติ บริการแพ็กเกจจึงถูกเปลี่ยนสภาพเป็น “คลิปบอร์ดร่วม” แบบสองทาง เป็นเส้นทางสั่งงานและส่งผลลัพธ์ระหว่างบัญชีที่ควรจะแยกออกจากกัน 619

เมื่อ prompt injection เปลี่ยนช่องทางนี้ให้เป็นทางนำข้อมูลออก

บริการร่วมเพียงอย่างเดียวไม่ได้ให้สิทธิ์เข้าถึงแอปของเหยื่อ การโจมตีที่รายงานยังต้องอาศัยการฝังคำสั่งของผู้โจมตีไว้ในบริบท ChatGPT ของเหยื่อ เช่น พรอมป์ต์อันตราย บทสนทนาที่แชร์ หรือคำสั่งที่ซ่อนไว้ใน Custom GPT 46

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

ในการพิสูจน์แนวคิดของ Check Point เซสชัน ChatGPT ของเหยื่อดึงข้อมูลจาก Gmail ที่เชื่อมต่ออยู่ ส่งผลผ่านช่องทาง Artifactory และทำให้ผู้โจมตีในอีกบัญชีหนึ่งเข้าถึงข้อมูลได้ ขณะที่เหยื่อยังได้รับคำตอบปกติสำหรับคำถามที่มองเห็น และตามรายงาน เหยื่อไม่เห็นทั้งคำสั่งที่ถูกแทรกหรือเนื้อหาที่ถูกส่งออก 36

รายงานระบุว่า สัญญาณที่เห็นได้มีเพียงป้ายเล็ก ๆ ว่า “Talked to Gmail” ซึ่งแสดงว่า Gmail ถูกเข้าถึงแล้ว นี่เป็นร่องรอยตรวจสอบหลังเกิดการทำงาน ไม่ใช่หลักฐานว่าผู้ใช้ได้รับหน้าต่างอนุมัติแบบละเอียดสำหรับการดึงหรือส่งต่อข้อมูลแต่ละครั้ง 3

OpenAI ดำเนินการอย่างไร

นักวิจัยแจ้งปัญหาให้ OpenAI ทราบในช่วงปลายเดือนมิถุนายน รายงานข่าวที่อ้างอิงการเปิดเผยระบุว่า บริการ Artifactory ที่ได้รับผลกระทบถูกปลดระวางแล้ว และช่องโหว่ถูกปิดเรียบร้อย 5

ข้อมูลสาธารณะที่มีเป็นการพิสูจน์แนวคิดจากงานวิจัย จึงไม่ควรตีความว่าเป็นหลักฐานว่าการดึงข้อมูล Gmail ตามตัวอย่างเกิดขึ้นอย่างแพร่หลายกับผู้ใช้ทั่วไปจริง 56

ต่างจากช่องทาง DNS ที่ Check Point เคยพบอย่างไร

ก่อนหน้านี้ Check Point เคยรายงานจุดอ่อนอีกแบบหนึ่งในสภาพแวดล้อมรันโค้ดของ ChatGPT นั่นคือมีเส้นทางส่งข้อมูลออกสู่อินเทอร์เน็ตสาธารณะที่ซ่อนอยู่ โดยรายงานที่เกี่ยวข้องอธิบายว่าเกี่ยวข้องกับ DNS 1516

กลไกของสองกรณีต่างกันดังนี้

กรณี	เส้นทางสื่อสาร	ผลกระทบด้านความปลอดภัย
ปัญหาช่องทางออกก่อนหน้า	ทางออกจาก runtime สู่อินเทอร์เน็ตสาธารณะ	ข้อมูลอ่อนไหวอาจถูกส่งออกนอกสภาพแวดล้อมได้ 1516
ช่องทางลับผ่าน Artifactory	สถานะร่วมที่แก้ไขได้ในบริการแพ็กเกจภายใน	บัญชีแยกกันสามารถแลกเปลี่ยนงานและผลลัพธ์ได้ แม้แซนด์บ็อกซ์ควรถูกแยกออกจากกัน 6

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

เกี่ยวข้องกับเหตุการณ์ Hugging Face อย่างไร

ช่องทาง Artifactory ที่ Check Point อธิบายไม่ใช่การโจมตีเดียวกับเหตุการณ์ที่เกี่ยวข้องกับเอเจนต์ประเมินผลของ OpenAI และ Hugging Face แต่รายงานเชื่อมโยงสองเหตุการณ์เข้าด้วยกันในภาพใหญ่ของ Artifactory และโครงสร้างพื้นฐานที่เกี่ยวข้อง ซึ่งเป็นบริการที่เข้าถึงได้จากสภาพแวดล้อมที่มีข้อจำกัด 5

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

จุดอ่อนเชิงสถาปัตยกรรม: การแยกต้องครอบคลุมถึงบริการพึ่งพา

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

สำหรับระบบ AI ที่ทำตามคำสั่งจากเนื้อหาที่ไม่น่าเชื่อถือและเรียกใช้เครื่องมือที่เชื่อมต่ออยู่ ลำดับความสำคัญด้านการป้องกันมีดังนี้

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

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