งานวิจัยชี้ช่องโหว่ encrypted reasoning ของ Anthropic OpenAI และ Google — ถอดรหัสได้ด้วยการยัดเข้าโมเดลที่อ่อนกว่า พบรหัสผ่านหลุด 182 ชุด

งานวิจัยชื่อ “Stealing Reasoning Traces from Proprietary LLM APIs” (arXiv:2608.09867) ที่ส่งขึ้น arXiv เมื่อ 10 สิงหาคม 2026 ชี้ช่องโหว่เชิงสถาปัตยกรรมในวิธีที่แล็บใหญ่ทั้งสามเจ้า — Anthropic, OpenAI และ Google — จัดการกับ encrypted reasoning trace หรือกระบวนการคิดที่เข้ารหัสไว้ไม่ให้ผู้ใช้อ่าน

ทีมวิจัยประกอบด้วย Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping และ Maksym Andriushchenko จาก ELLIS Institute Tübingen และ Max Planck Institute for Intelligent Systems — ไม่ใช่รายงานจากบล็อกความปลอดภัยเชิงพาณิชย์ แต่เป็นงานวิชาการที่ผ่านการแจ้งเจ้าของระบบตามกระบวนการ responsible disclosure แล้ว

ช่องโหว่คืออะไร

เวลาโมเดล reasoning ทำงานหลายรอบในบทสนทนาเดียว ผู้ให้บริการจะส่ง บล็อกข้อความเข้ารหัส ของกระบวนการคิดกลับมาให้ client เก็บไว้ แล้วให้ client ส่งกลับไปพร้อม request ถัดไป เพื่อให้โมเดลจำได้ว่ารอบก่อนคิดอะไรไว้ โดยที่ผู้ใช้เองอ่านไม่ออก — เป็นการออกแบบที่ตั้งใจปกป้องทั้ง IP ของแล็บและกันไม่ให้เนื้อหาดิบใน chain-of-thought หลุดออกมา

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

ผลที่ตามมาคือการโจมตีที่ทีมวิจัยเรียกว่า scalable decryption jailbreak วิธีการเรียบง่ายจนน่าตกใจ: เอาบล็อกที่เข้ารหัสจากโมเดลตัวเก่งไป ยัดใส่โมเดลตัวที่อ่อนกว่าและมีการ์ดน้อยกว่าของค่ายเดียวกัน แล้วบังคับให้มันถอดออกมาเป็นข้อความธรรมดาแบบคำต่อคำ — โดยไม่ต้องเจาะโมเดลตัวเก่งเลยแม้แต่นิดเดียว

สี่รูปแบบการใช้ประโยชน์

งานวิจัยสาธิตผลกระทบสี่ทาง:

1. ทะลุการป้องกัน distillation — การเข้ารหัส reasoning เป็นหนึ่งในวิธีหลักที่แล็บใช้กันคู่แข่งเอา chain-of-thought ไปกลั่นเป็นโมเดลตัวเอง เมื่อถอดได้ ด่านนี้ก็หายไปทั้งสามค่าย
2. ดูดข้อมูลส่วนตัวจาก repo สาธารณะ — ทีมวิจัยถอดบล็อก 315,320 ชิ้น ที่ scrape มาจาก repository สาธารณะ แล้วกู้ PII ได้ 367 รายการ และ credential ได้ 182 ชุด นี่คือส่วนที่ควรทำให้นักพัฒนาหนาว
3. เผยเนื้อหาอันตรายที่ซ่อนอยู่ในกระบวนการคิด — สิ่งที่โมเดลคิดแต่ถูกกรองก่อนตอบ กลับอ่านได้
4. prompt injection ที่มองไม่เห็น — ฝังคำสั่งไว้ในบล็อกเข้ารหัส ซึ่งมนุษย์และเครื่องมือตรวจสอบทั่วไปอ่านไม่ออก

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

จุดที่กระทบนักพัฒนาโดยตรง

ข้อ 2 คือข้อที่ควรลงมือทำอะไรวันนี้เลย ตัวเลข 182 credential ไม่ได้มาจากการเจาะระบบใคร — มันมาจาก log ของ agent ที่นักพัฒนา commit ขึ้น repo สาธารณะเอง ด้วยความเข้าใจว่าบล็อกเข้ารหัสนั้นอ่านไม่ออก จึงไม่เป็นไร

สมมติฐานนั้นเพิ่งถูกหักล้าง ถ้าโปรเจกต์ของคุณ:

• เก็บ conversation log ของ agent ที่มี reasoning block ลง git
• แนบ trace เต็มไว้ในรายงานบั๊กหรือ issue สาธารณะ
• ส่ง trace ดิบเข้าระบบ observability ที่บุคคลที่สามเข้าถึงได้

…ให้ถือว่าเนื้อหาในบล็อกเหล่านั้น เป็นข้อความธรรมดาที่อ่านได้ และตรวจย้อนหลังว่าเคยมี API key, token หรือข้อมูลลูกค้าไหลผ่านกระบวนการคิดของโมเดลหรือไม่

มุมมอง AI Curator

สิ่งที่งานนี้เปิดโปงไม่ใช่บั๊กของการเข้ารหัส แต่คือ ช่องว่างระหว่างสิ่งที่ผู้ใช้เข้าใจกับสิ่งที่ระบบรับประกันจริง คำว่า “encrypted” ทำให้นักพัฒนาทั้งอุตสาหกรรมเชื่อว่าบล็อกนั้นเป็นกล่องดำที่ปลอดภัย ทั้งที่กลไกนี้ถูกออกแบบมาเพื่อ ปกป้อง IP ของผู้ให้บริการ ไม่ใช่เพื่อ ปกป้องความลับของผู้ใช้ — และเมื่อวัตถุประสงค์สองอย่างนี้ไม่ตรงกัน ผู้ใช้คือฝ่ายที่แบกความเสี่ยงโดยไม่รู้ตัว บทเรียนที่ใช้ได้ทั่วไปคือ อย่าอนุมานสมบัติด้านความปลอดภัยจากคำศัพท์ที่ผู้ขายเลือกใช้ ให้อ่านว่าเขารับประกันอะไรไว้เป็นลายลักษณ์อักษร

น่าสนใจว่าช่องโหว่นี้เกิดพร้อมกันทั้งสามค่าย ซึ่งบอกว่าไม่ใช่ความพลาดของทีมวิศวกรรมทีมใดทีมหนึ่ง แต่เป็น รูปแบบการออกแบบร่วม ที่ทุกคนลอกกันมาเพราะมันแก้ปัญหา stateless API ได้ง่ายที่สุด การผูกบล็อกกับเซสชันแปลว่าต้องเก็บ state ฝั่งเซิร์ฟเวอร์ ซึ่งแพงกว่าและสเกลยากกว่า — เป็นการแลกที่ทั้งอุตสาหกรรมเลือกไปทางเดียวกันโดยไม่มีใครออกมาบอกผู้ใช้

สำหรับบริบทไทย จุดที่ควรกังวลที่สุดคือข้อ 4 — prompt injection ที่ซ่อนในบล็อกเข้ารหัส เพราะองค์กรไทยจำนวนมากกำลังวาง agent ไว้ในสายงานที่แตะข้อมูลลูกค้าจริง ทั้งคอลเซ็นเตอร์ ธนาคาร และระบบราชการ กระบวนการตรวจสอบด้านความปลอดภัยที่ใช้กันอยู่ — ให้คนอ่าน log แล้วดูว่ามีอะไรผิดปกติไหม — ใช้ไม่ได้เลยกับเนื้อหาที่มนุษย์อ่านไม่ออก และในแง่ PDPA การที่ trace เข้ารหัสซึ่งบรรจุข้อมูลส่วนบุคคลถูกส่งไปกลับข้ามพรมแดนโดยที่องค์กรตรวจสอบเนื้อหาเองไม่ได้ เป็นคำถามที่ยังไม่มีใครในไทยตอบไว้ชัด ๆ ว่าจะจัดการอย่างไร

ข้อดีคืองานนี้ผ่าน responsible disclosure มาแล้วและเสนอทางแก้ไว้ครบ ดังนั้นสิ่งที่ควรทำในระยะสั้นคือรอดูว่าแล็บทั้งสามจะประกาศแก้เมื่อไร และระหว่างนี้ให้ปฏิบัติกับ reasoning trace เหมือนเป็นข้อมูลอ่อนไหวที่อ่านออกได้ — ไม่ใช่ข้อมูลที่เข้ารหัสแล้ว

แหล่งข่าว

• Stealing Reasoning Traces from Proprietary LLM APIs — arXiv:2608.09867
• Paper page: Stealing Reasoning Traces from Proprietary LLM APIs — Hugging Face
• การอภิปรายบน Hacker News (467 คะแนน)