สรุปสั้น

ลิงก์แชร์บทสนทนาของ ChatGPT คือ ลิงก์สาธารณะที่ใครก็เปิดดูแชตที่ถูกแชร์ได้ และถูกส่งต่อกันทั่วไปทางอีเมล แชต ตั๋วซัพพอร์ต และโซเชียลมีเดีย นักวิจัยของบริษัทความปลอดภัย Parameter แสดงว่าลิงก์แชร์ที่สร้างมาเฉพาะสามารถรันโค้ดของผู้โจมตีภายในเซสชันที่ล็อกอินอยู่ของใครก็ตามที่เปิด โดยมีสิทธิ์เท่ากับเว็บ ChatGPT ตัวจริง โค้ดนั้นเรียกรายการแชตล่าสุดของเหยื่อ เปิดแชตส่วนตัวที่ไม่เคยแชร์ และส่งเนื้อหาออกไปได้ ในเวอร์ชันที่เสถียรที่สุดเหยื่อเปิดลิงก์แล้วกดปุ่ม Preview ครั้งเดียว และในเวอร์ชันหลังแค่เปิดลิงก์ก็พอ

Parameter รายงานผ่านโครงการ bug bounty ของ OpenAI เมื่อ 18 ตุลาคม 2569 OpenAI แก้ภายใน 8 วัน ยกระดับความรุนแรงเป็น P1 ซึ่งร้ายแรงที่สุด และจ่ายค่าตอบแทนรวม 5,000 ดอลลาร์ ต้นเหตุไม่ใช่ sandbox ที่แตก แต่เป็นตัวรับข้อความของไลบรารีคณิตศาสตร์ในหน้าหลักที่ไม่ตรวจว่าใครส่งมา ยังไม่มีรายงานว่าถูกใช้โจมตีจริง และผู้ใช้ไม่ต้องทำอะไรเพิ่ม แต่ข่าวนี้เป็นบทเรียนสำหรับทีมที่สร้างแอปซึ่งแสดงเนื้อหาที่ผู้ใช้สร้างเองคู่กับข้อมูลส่วนตัว

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 31 ตุลาคม 2569 ว่า Parameter เผยแพร่บทวิเคราะห์เมื่อ 28 ตุลาคม หลังการแก้ไขเสร็จแล้ว ไทม์ไลน์ คือ รายงานเมื่อ 18 ตุลาคม OpenAI ทำซ้ำได้ทั้งการรันโค้ดและการอ่านแชตส่วนตัว ยกความรุนแรงจาก P2 เป็น P1 แล้วทยอยแก้ใน frontend ของเว็บ ChatGPT 2 เวอร์ชัน จนวันที่ 26 ตุลาคม ทั้งสองเวอร์ชันปฏิเสธข้อความที่การโจมตีพึ่งพาแล้ว

เหยื่อไม่ต้องติดตั้งอะไร ไม่ต้องเข้าร่วม workspace และไม่ต้องล็อกอินผ่านผู้โจมตี โค้ดของผู้โจมตีเรียก API ของ ChatGPT ที่ใช้สิทธิ์ผู้ล็อกอินโดยตรง ไม่ได้แค่คัดลอกสิ่งที่อยู่บนหน้าจอ นักวิจัยเขียนว่าโดยพื้นฐานแล้ว “เราทำทุกอย่างแทนบัญชี ChatGPT ของเหยื่อได้”

ข้อจำกัดของหลักฐาน คือ งานนี้เป็นการทดสอบแบบควบคุม Parameter ทดลองอ่านแชตส่วนตัวระหว่างบัญชีที่แยกกันเอง ไม่ได้ทำกับผู้ใช้จริง และส่งเนื้อหาแชตเพียงส่วนเล็กไปยังเซิร์ฟเวอร์ของนักวิจัย ไม่มีรายงานการใช้ช่องโหว่ในโลกจริง (กรณีลิงก์แชร์ ChatGPT ถูกใช้เป็นเครื่องมือหลอกลวงอ่านได้ที่ 2026/05/086 )

Shared chatbot conversation link breaking out of a sandboxed preview frame into the main site

รายละเอียดช่องโหว่

จุดเริ่ม: Preview ใน sandbox ที่แข็งแรงดี — ChatGPT เปลี่ยนบล็อก HTML ในแชตเป็นหน้าเว็บเล็ก ๆ ผ่านฟีเจอร์ Preview เนื่องจากหน้านี้มีโค้ดอะไรก็ได้ ChatGPT จึงรันมันในเฟรมที่ล็อกไว้บนโดเมนแยก ซึ่งอ่านหน้า ChatGPT หลักรอบ ๆ ไม่ได้ Parameter ยืนยันว่า sandbox นี้ไม่แตก ทางเข้ามาจากฟีเจอร์ที่สองในแชตเดียวกัน

ตัวรับข้อความที่ไม่ตรวจผู้ส่ง — แชตที่แชร์มีกราฟแบบโต้ตอบด้วย การวาดกราฟโหลดไลบรารีคณิตศาสตร์ MathLive เข้าไปในหน้า ChatGPT หลัก และ MathLive ทิ้งตัวรับข้อความ (message listener) ที่รับคำสั่งเกี่ยวกับแป้นพิมพ์บนจอไว้ ข้อความที่ส่งข้ามเฟรมด้วย postMessage ปลอดภัยก็ต่อเมื่อผู้รับตรวจว่าใครส่ง แต่ตัวรับนี้ยอมรับข้อความแป้นพิมพ์จากผู้ส่งใดก็ได้ และข้อความนั้นยังพก HTML ดิบในฐานะข้อมูลเลย์เอาต์แป้นพิมพ์ได้ หน้า Preview ใน sandbox จึงยื่น HTML ของผู้โจมตีข้ามขอบเขตไปให้หน้าหลักที่เชื่อถือได้

สร้างเฟรมที่เป็นตัวตนของ chatgpt.com — HTML นั้นสร้างเฟรมใหม่ที่ไม่ได้อยู่ใน sandbox และเบราว์เซอร์ถือว่าเป็นส่วนหนึ่งของ chatgpt.com จากนั้นสคริปต์ที่โหลดจาก YouTube ส่งโค้ดเข้าไปรันในเฟรมนั้น ขั้นนี้ได้ผลเพราะนโยบาย Content Security Policy (CSP นโยบายจำกัดแหล่งสคริปต์ของหน้าเว็บ) ของ ChatGPT บล็อกโค้ดแบบ inline แต่อนุญาตสคริปต์จาก YouTube

สาเหตุที่แท้จริง 3 ข้อ — Parameter สรุปว่าการออกแบบ 3 อย่างมาเรียงกันพอดี ได้แก่ (1) MathLive ทำตามข้อความที่เปลี่ยนการตั้งค่าโดยไม่ตรวจเฟรมผู้ส่ง (2) ข้อความนั้นพก HTML ดิบได้ และ (3) HTML สร้างเฟรมที่ไม่มี sandbox และสืบทอดตัวตน chatgpt.com ได้ ขั้น YouTube เป็นแค่ทางเลี่ยงสุดท้าย การบล็อกขั้นนั้นอย่างเดียวยังปล่อยให้ Preview ที่ไม่น่าเชื่อถือส่ง HTML เข้าหน้าหลักได้อยู่

ผลกระทบ

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

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

คำแนะนำ

  • ผู้ใช้ ChatGPT ไม่ต้องทำอะไรเพิ่ม การแก้ไขอยู่ฝั่ง OpenAI แล้ว แต่ควรระวังลิงก์แชร์แชตจากคนไม่รู้จักเช่นเดียวกับลิงก์อื่น
  • ทีมพัฒนาเว็บควรไล่ตรวจทุก message event listener ในหน้าหลัก รวมถึงที่มาจากไลบรารีบุคคลที่สาม ว่าตรวจ event.origin และ event.source ก่อนทำตามคำสั่ง
  • ห้ามให้ข้อความข้ามเฟรมพก HTML ที่จะถูกเรนเดอร์โดยตรง และ sanitize ทุกค่าที่มาจาก postMessage
  • ทบทวน CSP ไม่ให้อนุญาตโดเมนกว้าง ๆ อย่าง YouTube ใน script-src หากไม่จำเป็น เพราะกลายเป็นทางเลี่ยงได้
  • แยกการเรนเดอร์เนื้อหาที่ผู้ใช้สร้างเองออกจากหน้าที่ถือเซสชันและข้อมูลส่วนตัวทั้งหมด ไม่ใช่เฉพาะส่วน Preview

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