Opus 4.8 ทำไม่สำเร็จ Opus 5 ออกมาแล้วทำได้ใน 3 ชั่วโมง: รายงาน Hacktron เล่าการเจาะ OpenAI ผ่านรูใน libheif — และบิลค่าโทเคนทั้งแคมเปญไม่ถึง $3,000

หมายเหตุ: รายงานฉบับนี้เผยแพร่เมื่อ 13 ก.ย. 2026 (อัปเดตข้อมูลแพตช์ 14 ก.ย.) เราไม่ได้เขียนถึงในรอบนั้นและหยิบมาเล่าย้อนหลัง เพราะเนื้อหาส่วนที่ วัด “ความสามารถของโมเดลในการเขียน exploit” เป็นข้อมูลที่หาได้ยากมาก และ ช่องโหว่ที่เกี่ยวข้องถูกแพตช์เรียบร้อยแล้วทั้งหมด

ข่าวความปลอดภัยส่วนใหญ่อ่านแล้วลืม แต่รายงานของทีม Hacktron ฉบับนี้ต่างออกไป เพราะมันไม่ใช่แค่เรื่อง “มีคนเจาะ OpenAI ได้” — มันคือบันทึกภาคสนามที่ระบุชัดว่า โมเดลรุ่นไหนทำงานเขียน exploit ได้ถึงระดับไหน และต้นทุนเท่าไร ซึ่งเป็นข้อมูล ที่ benchmark สาธารณะตัวไหนก็ไม่ให้

เรื่องย่อ: 25 ก.ค. 2026 ทีมสามคนของ Hacktron (Harsh Jaiswal, Mohan Pedhapati, Rahul Maini) ต่อช่องโหว่สองตัวเข้าด้วยกันจนเข้าถึงบัญชี ChatGPT ของพนักงาน OpenAI หลายคน และผ่านบัญชีนั้นเข้าถึงรีโปภายในขององค์กรได้ เพื่อพิสูจน์ว่าเข้าถึงได้จริง โดยไม่ต้องอ่านข้อมูลลับ พวกเขาสั่ง Codex ของพนักงานคนหนึ่งให้เปิด pull request ในโมโนรีโป openai/openai แล้วหยุดทดสอบทันที ทั้งหมดตั้งแต่เริ่มค้นจนได้สิทธิ์ ใช้เวลาไม่ถึง 72 ชั่วโมง

ห่วงโซ่: จากรูปภาพหนึ่งใบ ถึงโมโนรีโปภายใน

จุดเริ่มคือกระดานสนทนา community.openai.com ซึ่งรันบน Discourse และรองรับ “Sign in with OpenAI” ผ่าน auth.openai.com ทีม Hacktron มองว่าตัว Discourse เองเจาะยาก จึงไปเล่นกับ dependency แทน

23 ก.ค. พวกเขาไล่ดู pipeline อัปโหลดรูปของ Discourse แล้วพบว่าไฟล์ HEIC/HEIF เดินทางไม่เหมือนไฟล์อื่น — ปกติ Discourse ใช้ FastImage ตรวจรูป แต่ FastImage ไม่รองรับ HEIF จึงส่งไฟล์พวกนี้ต่อให้คำสั่ง magick ของ ImageMagick แปลงร่าง ซึ่งเท่ากับเปิด parser ของ libheif ให้รับไฟล์ที่ผู้โจมตีควบคุมได้โดยตรง

จากนั้นคือส่วนที่น่าสนใจ: พวกเขาเปิดเซสชัน Opus 4.8 พร้อม Docker image ของ Discourse แล้วสั่งให้ตรวจแพ็กเกจ libheif ที่ติดตั้งอยู่ ผลคือโมเดลพบว่า แพตช์ความปลอดภัยบางตัวไม่ถูก backport มา — สาเหตุที่รายงานชี้ไว้น่าสนใจมาก สำหรับคนทำ supply chain: โค้ดที่มีปัญหาถูกแก้ที่ upstream ตั้งแต่ปีก่อน แต่ คอมมิตนั้นไม่ได้ระบุว่าเป็นการแก้ด้านความปลอดภัยและไม่มี CVE ดิสโทรจึงไม่มี สัญญาณให้ backport Debian 12 ส่ง libheif เวอร์ชัน 1.19.7 (Discourse image ใช้ฐานนี้) และแม้แต่ Debian 13 ก็ยังส่ง 1.19.8 ที่มีรูอยู่ในตอนนั้น

Debian ออก DSA-6417-1 เมื่อ 8 ส.ค. 2026 รวม CVE ถึง 12 รายการใน libheif ตัวเดียว ส่วน Discourse ออกคำแนะนำ GHSA-vhm9-85gw-x335 เมื่อ 28 ก.ค. พร้อมเพิ่ม sandbox ให้ ImageMagick เป็น defense in depth

ขั้นตอนสุดท้ายไม่ได้อยู่ที่ Discourse เลย — ทีมงานย้ำเองว่าช่องที่ทำให้ยกระดับ จาก “ยึดกระดานสนทนา” เป็น “ยึดบัญชี ChatGPT/Codex” คือ SSO misconfiguration ฝั่ง OpenAI ไม่ใช่บั๊กของ Discourse ถ้าบริการไหนก็ตามที่ใช้ OpenAI SSO ถูกเจาะ ผลลัพธ์ก็จะเหมือนกัน และเนื่องจากผู้ใช้เชื่อมต่อ GitHub, Slack, อีเมล เข้ากับ Codex/ChatGPT ขอบเขตความเสียหายที่เป็นไปได้จึงกว้างมาก

ส่วนที่นักพัฒนาควรอ่านที่สุด: โมเดลไหนทำได้แค่ไหน

นี่คือเหตุผลหลักที่เราหยิบเรื่องนี้มาเขียน รายงานบันทึกลำดับเวลาไว้ละเอียดผิดปกติ

• 24 ก.ค. — ใช้ Opus 4.8 พัฒนา exploit ที่รันได้จริงกับ ImageMagick/libheif ในสภาพ ปิด ASLR สำเร็จ
• จากนั้นเปิดหลายเซสชันเพื่อทำให้มันเสถียรกับคอนฟิกมาตรฐานของ Discourse ที่ เปิด ASLR — รายงานใช้คำว่า “wasn’t fruitful” คือทำไม่สำเร็จ
• เย็นวันนั้น Anthropic ปล่อย Claude Opus 5 ทีมเปิดเซสชันใหม่ ได้ exploit ที่ใช้งานได้บน ARM64 (เครื่อง Mac ในเครื่อง) ภายใน 3 ชั่วโมง แล้วสั่งให้ พอร์ตไปยังสภาพแวดล้อม x86-64 และคอนฟิก jemalloc ที่ Discourse ใช้
• 06:00 น. 25 ก.ค. — ยืนยัน RCE ในเครื่องผ่านการอัปโหลดรูปสำเร็จ
• จากนั้นปล่อย Claude ทำงานแบบอัตโนมัติในลูป /goal ยิงใส่อินสแตนซ์ Discourse Cloud ของตัวเอง โดย proxy ผ่าน rce.ee/ctf-forum เพื่อให้ดูเหมือน เป้าหมาย CTF — เพราะ Opus ปฏิเสธที่จะเขียน exploit สำหรับอินสแตนซ์ระยะไกล
• 10:00 น. — กลับมาดูอีกที agent ทำ RCE บน Discourse Cloud สำเร็จแล้ว และ พิสูจน์ด้วยการอ่าน /etc/hosts

ข้อสรุปเรื่องความสามารถที่ทีมเขียนไว้ตรง ๆ: “Opus 4.8 ดิ้นรนอยู่หลายเซสชันกว่าจะ ทำ exploit ที่ทำงานกับ ASLR ไม่สำเร็จ ภายในไม่กี่ชั่วโมงหลัง Opus 5 ออก เราให้ โจทย์เดียวกันแล้วมันทำได้” และเขายังระบุว่าเห็นก้าวกระโดดอีกครั้งจาก Opus 5 ไป GPT-5.6 Sol ในสถานการณ์ที่ยากกว่า — คือต้องเจาะโดยไม่รู้อะไรเลยเกี่ยวกับระบบ เป้าหมาย นอกจากว่ามันมีช่องโหว่

ตัวเลขต้นทุนที่ควรทำให้ทุกคนหยุดคิด

ช่องโหว่ libheif ไม่ได้ถูกใช้กับ OpenAI เจ้าเดียว Hacktron ขยายเป็นงานวิจัยชื่อ HEIF Heist ไล่ตาม libheif ข้ามผลิตภัณฑ์ — ในรายงานระบุถึง Slack, Zoom, Meta, GitHub Enterprise, Ruby on Rails และเฟรมเวิร์ก Node.js อย่าง Next.js, Astro และ Gatsby ตัวเลขที่เขาให้ไว้:

• แคมเปญทั้งหมด: 2 เดือน, นักวิจัย 3 คน, ค่าโทเคนรวมไม่ถึง $3,000
• ปรับ exploit ให้เข้ากับเป้าหมายใหม่แต่ละราย: 1–2 วัน
• การเจาะ Discourse/OpenAI: “ใช้เวลาของ agent ไม่กี่วัน และเวลาของมนุษย์แค่ไม่กี่ชั่วโมง”
• แต่ละเป้าหมายเริ่มจากการอัปโหลดรูปหนึ่งใบ โดยส่วนใหญ่ ไม่รู้เวอร์ชัน libheif, ไม่รู้เวอร์ชัน libc, ไม่รู้สภาพแวดล้อม deploy
• และบรรทัดที่หนักที่สุด: “เราไม่ทราบว่ามีบริษัทใดตรวจจับกิจกรรมนี้ได้ ยกเว้น Shopify” ทั้งที่ส่งรูปเข้าไปหลายพันใบและตัวประมวลผลรูปแครชซ้ำแล้วซ้ำอีก

OpenAI จ่ายรางวัล $6,500 เมื่อ 1 ก.ย. พร้อมหมายเหตุว่าการทดสอบกับ community.openai.com ที่โฮสต์โดย Discourse อยู่นอกขอบเขตโปรแกรม รางวัลนี้ให้กับ สิ่งที่พบฝั่ง OpenAI เท่านั้น ส่วนการตอบสนองเร็วมากทั้งสองฝ่าย — OpenAI ยืนยัน ว่าแก้แล้วภายในราว 14 ชั่วโมงหลังรับรายงาน ส่วน Discourse รับรายงานวันเสาร์ ตอบวันอาทิตย์ และมีแพตช์วันจันทร์

สิ่งที่ต้องทำถ้าระบบคุณรับรูปจากผู้ใช้

รายงานระบุว่า HEIF Heist ไม่ได้ผูกกับเวอร์ชันเดียว แต่กินหลายสาย (1.19.x, 1.20.x, 1.22.x, 1.23.x) ทุก deployment ที่ยังไม่ได้แพตช์ล่าสุดถือว่าเสี่ยง

1. อัปเดต libheif และ libde265 ผ่านช่องทางความปลอดภัยของดิสโทรหรือ upstream โดยตรง ณ 14 ก.ย. 2026 เวอร์ชันความปลอดภัยล่าสุดของ libheif คือ v1.23.4 (v1.23.2 ถูกแทนที่ด้วยแพตช์ตามมาแล้ว) — แต่แพ็กเกจของดิสโทรอาจ backport แพตช์โดยยังใช้เลขเวอร์ชันเก่า ให้ดูประกาศความปลอดภัยของแพ็กเกจประกอบ
2. ถ้ารัน Discourse เอง ให้ rebuild ไม่ใช่แค่อัปเดตผ่านหน้าเว็บ — คำเตือนใน รายงานชัดเจนว่า Docker image เก่าอาจยังมี libheif ที่มีรูอยู่: git pull แล้ว ./launcher rebuild app จาก /var/discourse (ลูกค้าที่ Discourse โฮสต์ให้ถูกแพตช์ไปแล้ว)
3. ปิดการถอดรหัส HEIF/AVIF ที่ไม่จำเป็น ถ้าแอปคุณไม่ต้องรับไฟล์ .heic .heif .avif จากผู้ใช้ ก็ปฏิเสธมันไปเลยตั้งแต่ชั้นแรก
4. แยก pipeline ประมวลผลรูปออกเป็น sandbox ที่ใช้แล้วทิ้ง — ImageMagick มี policy.xml ที่จำกัดฟอร์แมตและทรัพยากรที่ยอมรับได้ ใช้มัน

มุมมอง AI Curator

บทสรุปของรายงานพูดถึงสิ่งที่เรียกว่า security through complexity — เป็นเวลานาน ที่ช่องโหว่ memory corruption ถูก “รู้” กันอย่างเปิดเผยได้โดยไม่อันตรายมาก เพราะ การเปลี่ยนบั๊กให้เป็น exploit ที่เสถียรต้องใช้ความเชี่ยวชาญหายาก เวลามหาศาล และ ความรู้เรื่องสภาพแวดล้อมของเป้าหมาย 0-day จึงถูกเก็บไว้ใช้กับเป้าหมายมูลค่าสูง เท่านั้น บริษัททั่วไปได้รับการปกป้องจาก “ต้นทุนของการโจมตี” มากกว่าจากมาตรการ ความปลอดภัยของตัวเอง

ตัวเลข $3,000 ต่อแคมเปญสองเดือนคือการประกาศว่ากำแพงนั้นหมดอายุแล้ว สิ่งที่เคย ต้องใช้ทีมที่มีทุนหนาและเวลาหลายเดือน ตอนนี้ย่อลงเหลือไม่กี่วันด้วยงบที่ startup ไทยขนาดเล็กก็จ่ายไหว

สำหรับผู้อ่านชาวไทยและ SEA เราคิดว่ามีสองประเด็นที่ต้องแยกให้ออก

หนึ่ง — นี่ไม่ใช่เรื่อง “AI จะแฮ็กเราเอง” รายงานเขียนชัดว่า “This was not completely autonomous hacking, and skilled human guidance remained important” มนุษย์ยังเป็นคนตั้งสมมติฐาน เลือกเป้าหมาย และตัดสินใจ สิ่งที่เปลี่ยนคือ อัตราส่วนงานต่อคน ทีมสามคนทำงานได้เท่าทีมสามสิบคน นั่นคือ การเปลี่ยนแปลงเชิงเศรษฐศาสตร์ ไม่ใช่เชิงเวทมนตร์

สอง — ฝั่งตั้งรับต้องอัปเดตสมมติฐาน ไม่ใช่แค่ patch level บรรทัดที่ควรทำให้ ทีม security ในไทยนอนไม่หลับไม่ใช่ตัวเลข $3,000 แต่คือประโยคว่ามีเพียง Shopify เจ้าเดียวที่ตรวจจับได้ ทั้งที่มีรูปหลายพันใบและ image processor แครชซ้ำ ๆ ถ้าองค์กรระดับนั้นยังไม่เห็น ระบบ monitoring ของเราที่ดู error rate เป็นรายชั่วโมง จะเห็นได้อย่างไร? คำถามที่ควรถามพรุ่งนี้เช้าคือ: ถ้า service ที่แปลงรูปของเรา segfault 50 ครั้งในหนึ่งชั่วโมง มีใครได้รับ alert หรือไม่ — หรือมันแค่ถูก restart โดย Kubernetes เงียบ ๆ?

และมีบทเรียนที่สามที่ไม่ค่อยมีใครพูดถึง: ต้นตอของเรื่องทั้งหมดคือคอมมิต upstream ที่แก้บั๊กด้านความปลอดภัยแต่ไม่ได้ติดป้ายว่าเป็นการแก้ความปลอดภัย และไม่มี CVE ทุกวันนี้เครื่องมือ scan dependency ของเราทำงานบนฐานข้อมูล CVE เกือบทั้งหมด แปลว่ามีช่องโหว่ประเภทนี้ — ที่ถูกแก้แล้วแต่ไม่มีใครติดป้าย — มองไม่เห็นด้วย เครื่องมือปกติ ในขณะที่โมเดลอย่าง Opus 4.8 อ่านโค้ดแล้วเจอ ถ้าฝ่ายโจมตีใช้ AI อ่าน diff ของ upstream เพื่อหาแพตช์ที่ดิสโทรพลาด ฝ่ายตั้งรับก็ควรใช้วิธีเดียวกัน ได้แล้ว — และนั่นน่าจะเป็นการใช้ coding agent ที่คุ้มค่าที่สุดอย่างหนึ่งในปีนี้

แหล่งข่าว

• Hacking OpenAI — Hacktron AI (13 ก.ย. 2026)
• Discourse security advisory GHSA-vhm9-85gw-x335 (28 ก.ค. 2026)
• Debian DSA-6417-1: libheif security update (8 ส.ค. 2026, 12 CVE)