เดโม Django แบบ 133 เอเจนต์ของ Mistral Large 4: จำลองบั๊กที่ Django แก้ไขไปแล้วได้สำเร็จ

Mistral Large 4 โมเดลน้ำหนักเปิดที่มีพารามิเตอร์ 1.05 ล้านล้าน ซึ่ง Mistral AI ตั้งชื่อเล่นว่า Le Chonk ได้รับการนำเสนอเมื่อวันที่ 4 พฤศจิกายน 2026 ในฐานะนักวิจัยความปลอดภัยแบบครบวงจร โพสต์จากบัญชี X ทางการของ Mistral ถามว่าโมเดลนี้สามารถ "ค้นหาช่องโหว่ร้ายแรง พิสูจน์ และแก้ไขได้หรือไม่" จากนั้นตอบด้วยเอเจนต์ 133 ตัว ฐานโค้ด Django และไทม์แลปส์ความเร็ว 90 เท่า โพสต์ดังกล่าวไม่ได้ระบุ CVE ไม่ได้เผยแพร่แพตช์ ไม่ได้ให้รันไทม์ จำนวนโทเค็น จำนวนผลบวกลวง และไม่มีลิงก์ไปยังรายงานทางเทคนิค

กำหนดเวลาทำให้ตัวเลือกแคบลง ทีมความปลอดภัยของ Django ได้ออกแพตช์แก้ไขสำหรับ CVE หกรายการเมื่อวันก่อน คือวันที่ 3 พฤศจิกายน 2026 ในเวอร์ชัน 6.1.3, 6.0.10 และ 5.2.19 (มีหนึ่งประเด็นที่ไม่มีแพตช์สำหรับ 5.2 ระบุไว้) หากชุดนั้นคือเป้าหมาย — และเป็นชุด CVE ของ Django เพียงชุดเดียวในข่าวสัปดาห์นั้น — เดโมนั้นเป็นไปไม่ได้ที่จะค้นพบช่องโหว่ที่ไม่รู้จัก เพราะทั้งหกรายการเป็นสาธารณะและได้รับการแพตช์แล้วก่อนวิดีโอจะถูกโพสต์ นอกจากนี้ ยังไม่ใช่ช่องโหว่ระดับวิกฤต รายการหนึ่งมีคะแนนระดับปานกลาง ส่วนอีกห้ารายการถูกจัดอยู่ในระดับต่ำ

นั่นไม่ได้ทำให้เดโมนี้ไร้ค่า แต่ทำให้มันเป็นการสาธิตเวิร์กโฟลว์มากกว่าการอ้างว่าเป็นการค้นพบ และความแตกต่างนี้สำคัญสำหรับใครก็ตามที่กำลังตัดสินใจว่าโมเดลแบบ open-weight จะสามารถเข้ามามีที่ทางในคิวคัดกรองของทีมความปลอดภัยได้หรือไม่

สิ่งที่ Mistral แสดงให้เห็นจริง ๆ

โพสต์นี้สั้น: “Mistral Large 4 สามารถค้นหาช่องโหว่ร้ายแรง พิสูจน์ และแก้ไขได้หรือไม่? เราได้ทดสอบกับ Django CVE ที่เพิ่งเกิดขึ้นเมื่อเร็ว ๆ นี้ เอเจนต์ 133 ตัวทำแผนที่โค้ด ค้นหาจุดบกพร่อง ทดสอบสถานการณ์โจมตี และยืนยันบั๊ก จากนั้น Le Chonk ก็แพตช์มัน การคัดแยกปัญหา การทำซ้ำ และการแพตช์ แสดงที่ความเร็ว 90x” ณ เวลาที่เขียน โพสต์มี 540 ไลก์ 94 รีโพสต์ 107 การตอบกลับ และประมาณ 21,000 วิว — เป็นโพสต์ผลิตภัณฑ์ที่น่านับถือ ไม่ใช่การเปิดเผยช่องโหว่

บันทึกการเผยแพร่ของ Mistral เองอธิบายขั้นตอนการทำงานเดียวกันนี้ไว้ละเอียดกว่า ประกาศแบบ open-weight ระบุถึงเอเจนต์ "Cyber Vulnerability Triage" ที่อ่านรายงานช่องโหว่ที่เข้ามา จำลองข้อบกพร่องเหล่านั้นซ้ำในแซนด์บ็อกซ์แบบแยกส่วน เขียนแพตช์และปรับปรุงแพตช์ซ้ำ ๆ และดำเนินต่อไป "จนกว่า canary exploit จะใช้ไม่ได้อีกต่อไป" นั่นเป็นคุณสมบัติที่มีเอกสารประกอบของโมเดล ซึ่งเขียนไว้ก่อนวิดีโอ การรันเอเจนต์ 133 ตัวเป็นการสาธิตต่อสาธารณะถึงคุณสมบัติดังกล่าว

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

แบตช์ Django และเหตุผลที่คำว่า "critical" ไม่เข้ากัน

ประกาศของ Django ลงวันที่ 3 พฤศจิกายนมีความเฉพาะเจาะจงอย่างผิดปกติ ซึ่งนั่นเองที่ทำให้มันมีประโยชน์ในฐานะกลุ่มควบคุม โดยระบุประเด็นไว้หกข้อ แต่ละข้อมี CVE ผู้รายงาน ชุดสาขาที่ได้รับผลกระทบ และคอมมิตที่ใช้แก้ไข ระดับความรุนแรงนั้นไม่ได้ใกล้เคียงกับระดับวิกฤต:

• CVE-2026-111362 — ระดับปานกลาง สมาชิก crs ของเรขาคณิต GeoJSON อาจทำให้ GDAL ส่งคำขอผ่านเครือข่ายหรืออ่านไฟล์ภายในเครื่องระหว่างการตรวจสอบความถูกต้อง การบันทึก หรือการสอบถาม ซึ่งเป็นช่องทางการโจมตีแบบ SSRF และการอ่านไฟล์ภายในเครื่อง

• CVE-2026-108147 — ต่ำ การอัปโหลดแบบ multipart ที่เข้ารหัส Base64 ถูกบัฟเฟอร์ก่อนที่ตัวจัดการการอัปโหลดจะทำงาน ซึ่งข้าม FILE_UPLOAD_MAX_MEMORY_SIZE และอาจทำให้หน่วยความจำหมดได้

• CVE-2026-111211 — ต่ำ อักขระควบคุมในค่าฟอร์มเรขาคณิตที่ไม่ถูกต้องถูกบันทึกโดยไม่มีการ escape ทำให้เกิดการฉีดหรือปลอมแปลงบันทึก (log injection หรือ forgery)

• CVE-2026-113593 — ต่ำ: ค่า Vary header ที่หายไปและค่าว่างสร้างแคชคีย์เดียวกัน ทำให้เสี่ยงต่อการเปิดเผยการตอบกลับที่แคชไว้ซึ่งเป็นข้อมูลส่วนตัว

• CVE-2026-113733 — ต่ำ ผู้ใช้แอดมินที่ดูได้อย่างเดียวสามารถเห็นแฮชรหัสผ่านแบบเต็มสำหรับโมเดลผู้ใช้ที่กำหนดเองบางรายการ

• CVE-2026-114582 — ความรุนแรงต่ำ อินพุตสตริง SpatialReference อาจทำให้ GDAL ดึง URL หรืออ่านไฟล์; การป้องกันแบบสมบูรณ์ต้องใช้ GDAL 3.9 หรือใหม่กว่า

ทั้งหกได้รับการแก้ไขในวันเดียวกัน นี่คือกระบวนการปกติของ Django: คำแนะนำด้านความปลอดภัย แพตช์ และบันทึก CVE จะเผยแพร่พร้อมกัน โมเดลที่ "ยืนยันบั๊ก" ในอีกหนึ่งวันต่อมากำลังยืนยันบั๊กที่การแก้ไขอยู่ในรีโพซิทอรีแล้ว และมีขั้นตอนการทำซ้ำอยู่ในรายงานสาธารณะ การทำซ้ำบั๊กที่ถูกรายงานเป็นงานแรกของคิวคัดแยก ดังนั้นนี่คืองานจริง — แต่มันไม่เหมือนกับการค้นพบบั๊ก

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

133 เอเจนต์เป็นตัวเลขของการออร์เคสเทรชัน

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

ตัวชี้วัดที่จะทำให้จำนวนนี้นมีความหมายคือตัวชี้วัดที่หายไป: มีการยกข้อบกพร่องที่ต้องสงสัยขึ้นมากี่รายการ มีกี่รายการที่เป็นผลบวกลวง ต้องใช้เอเจนต์กี่ตัวต่อบั๊กที่ยืนยันได้หนึ่งรายการ และการรันครั้งนั้นมีค่าใช้จ่ายเป็นโทเคนเท่าไร ระบบที่ยกผู้ต้องสงสัย 200 รายการเพื่อยืนยันบั๊กจริงหนึ่งรายการเป็นผลิตภัณฑ์ที่ต่างจากระบบที่ยกขึ้นมาสามรายการและยืนยันได้หนึ่งรายการ และทั้งสองระบบก็สามารถถูกอธิบายอย่างซื่อตรงได้ว่าเป็น "133 เอเจนต์"

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

ตัวเลขด้านความปลอดภัยที่ Mistral เปิดเผย

โพสต์เกี่ยวกับโมเดลแบบเปิดน้ำหนักของ Mistral ระบุว่า Mistral Large 4 อยู่ที่ 51% ใน Artificial Analysis Cyber Index ในแผนภูมิที่ผู้ขายจัดทำขึ้น ซึ่งจัดให้ MiMo-V2.6-Pro อยู่ที่ 56% และ DeepSeek-V4.1-Flash 1017 อยู่ที่ 57% โดย Kimi K3 อยู่ที่ 41% และ GLM-5.3 อยู่ที่ 36% ดัชนีนี้ทดสอบว่าโมเดลสามารถค้นหาช่องโหว่ในฐานโค้ด ทำซ้ำและตรวจสอบความถูกต้องของช่องโหว่เหล่านั้น และแพตช์ช่องโหว่เหล่านั้นได้หรือไม่ — ซึ่งเป็นคำกริยาสามคำเดียวกันกับในเดโม

โพสต์เดียวกันรายงานอัตราการปฏิเสธเฉลี่ย 96.6% สำหรับคำขอทางไซเบอร์ที่เป็นอันตราย ซึ่ง Mistral ระบุว่าเป็นอัตราสูงสุดที่ตนวัดได้ในบรรดาโมเดลแบบเปิด และความต้านทานต่อการโจมตี 97.1% บนเกณฑ์มาตรฐานความปลอดภัยของเอเจนต์ B3 เพิ่มขึ้นจาก 93.3% ตอนพรีวิว หน้า พรีวิว เดือนตุลาคมยังระบุคะแนน 82% ในการทดสอบการจำลองและแพตช์ช่องโหว่ของ Mistral เอง และ 93% จาก 40 ความท้าทาย Cybench; โพสต์เกี่ยวกับโมเดลน้ำหนักเปิดไม่ได้กล่าวถึงตัวเลขทั้งสองซ้ำ

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

มีการตึงเครียดที่แท้จริงในการวางตำแหน่งผลิตภัณฑ์ โมเดลที่ถูกปรับให้ปฏิเสธคำขอทางไซเบอร์ที่เป็นอันตรายถึง 96.6% ก็ยังถูกขายโดยชูความสามารถในการจำลอง exploit และเขียนแพตช์ คำตอบของ Mistral คือตัวแปรเฉพาะทางสำหรับการทดสอบเจาะระบบและการทำเรดทีม ซึ่งถูกจำกัดการเข้าถึงด้วยการตรวจสอบคุณสมบัติและข้อจำกัดตามสัญญาให้ใช้ได้เฉพาะระบบที่ครอบครองหรือได้รับอนุญาตเท่านั้น เช็กพอยต์แบบเปิดน้ำหนักคือโมเดลทั่วไป พร้อมการ์ดเรลที่โฮสต์สามารถปรับแต่งได้ — ซึ่งเป็นเหตุผลพอดีที่คำถามเรื่องการใช้ประโยชน์สองทางนั้นติดไปกับน้ำหนักโมเดลมากกว่าตัว API

อะไรจะทำให้เดโมกลายเป็นหลักฐาน

ข้อกล่าวอ้างแบบครบวงจรที่น่าเชื่อถือต้องมีหกสิ่ง ไม่มีสิ่งใดแปลกพิเศษเลย และทุกสิ่งเหล่านั้นล้วนขาดหายไปจากโพสต์

• CVE ที่ระบุชื่อ หรือบั๊กที่ไม่มีรายงานสาธารณะ — เพื่อให้ผู้อ่านแยกแยะการค้นพบออกจากการทำซ้ำได้

• คอมมิตที่มีช่องโหว่และคอมมิตที่ได้รับการแพตช์แล้ว เพื่อให้สามารถตรวจสอบ diff ได้

• การจำลองสถานการณ์ก่อนและหลังในสภาพแวดล้อมเดียวกัน รวมถึง exploit ที่ล้มเหลวและ exploit ที่ผ่าน

• จำนวนผลบวกเท็จ: จำนวนผู้สมัครที่ตัวแทนเสนอขึ้นมาก่อนที่จะมีหนึ่งรายผ่านการคัดเลือก

• เวลาจริง (wall-clock) และต้นทุนโทเคนสำหรับการรันทั้งหมด ไม่ใช่ตัวคูณการเล่นซ้ำ

• การรันซ้ำอย่างอิสระโดยบุคคลที่ไม่ใช่ Mistral

เผยแพร่สิ่งเหล่านั้น แล้วข้อโต้แย้งจะเปลี่ยนไป จนกว่าจะถึงตอนนั้น คำอธิบายที่ตรงไปตรงมาคือ “Mistral สาธิตเอเจนต์คัดกรองปัญหาของตนกับบั๊ก Django สาธารณะ” ซึ่งเป็นการสาธิตผลิตภัณฑ์ที่มีประโยชน์ และเป็นข้อกล่าวอ้างที่เล็กกว่าประโยคแรกของโพสต์มาก

การรันแพตเทิร์นกับโค้ดเบสของคุณเอง

เวตเปิด (open weights) คือส่วนที่สำคัญสำหรับทีมความปลอดภัย Mistral เปิดตัวเช็กพอยต์เมื่อวันที่ 29 ตุลาคม 2026 ภายใต้ Mistral Ecosystem Open-Weight License ซึ่งเป็นสัญญาอนุญาต MIT ที่ดัดแปลงแล้ว อนุญาตให้ใช้ ดัดแปลง ไฟน์ทูน และทำเชิงพาณิชย์ แต่กำหนดให้ใครก็ตามที่ดำเนินธุรกิจโมเดลในรูปแบบบริการต้องมีสัญญาอนุญาตแยกต่างหาก เช็กพอยต์นี้มี 1.05 ล้านล้านพารามิเตอร์ โดยมี 49 พันล้านพารามิเตอร์ที่ใช้งานต่อโทเคน รองรับบริบทขนาด 1M โทเคน และมีรุ่นย่อย NVFP4 สำหรับ Blackwell GPUs การโฮสต์เองถือเป็นการซื้อคลัสเตอร์ ไม่ใช่การดาวน์โหลดลงแล็ปท็อป แต่มันช่วยเก็บซอร์สโค้ดและผลการค้นพบไว้ภายในขอบเขตของคุณ — ซึ่งเป็นเหตุผลที่ทีมความปลอดภัยจะเลือกใช้แทน API

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

นั่นคือจุดที่ระบบ routing เข้ามาช่วย Mistral Large 4 ไม่ได้อยู่ในแคตตาล็อกของ OrcaRouter — มันให้บริการผ่าน API ของ Mistral เองและดาวน์โหลดไปโฮสต์เองได้ — แต่ OrcaRouter นำโมเดลอื่นอีก 200+ โมเดลมาไว้เบื้องหลังคีย์เดียวที่เข้ากันได้กับ OpenAI โดยบวกเพิ่ม 0% จากราคาตามรายการของผู้ให้บริการ มี automatic failover และมี routing DSL ที่ประกอบตัวตรวจสอบความเห็นที่สองเข้าไปในการเรียกครั้งเดียวกันได้ ไพป์ไลน์สำหรับการคัดแยก (triage) ไม่จำเป็นต้องมีโมเดลเดียวที่เก่งทุกอย่าง แต่ต้องการให้ผู้เขียนแพตช์กับผู้รีวิวแพตช์เป็นคนละตัวกัน และคีย์เดียวเป็นวิธีที่ถูกกว่าในการไปถึงจุดนั้นเมื่อเทียบกับสัญญากับผู้ขายสองฉบับ

ข้อกล่าวอ้างที่ต้องจับตา

Mistral มีองค์ประกอบของผลิตภัณฑ์ความปลอดภัยที่น่าเชื่อถือ: น้ำหนักโมเดลแบบเปิด ลูปการคัดแยกที่มีเอกสารประกอบ เมตริกการปฏิเสธที่แข็งแกร่ง และเบนช์มาร์กที่วัดคำกริยาที่ถูกต้อง สิ่งที่ยังไม่มีต่อสาธารณะ คือกรณีที่โมเดลค้นพบสิ่งที่ยังไม่ถูกแก้ไขมาก่อน เดโมครั้งหน้าควรระบุชื่อบั๊ก เผยแพร่ diff และให้คนอื่นรันมันได้ จนกว่าจะถึงตอนนั้น วิดีโอ 133 เอเจนต์เป็นเพียงการสาธิตการประสานงาน ไม่ใช่หลักฐานของการค้นพบ และคำว่า “critical” กำลังรับภาระมากเกินกว่าที่ชุดบั๊ก Django จะรองรับ