สรุปทั้งเรื่องในบรรทัดเดียว
- ใช้พายป์ไลน์ราคาถูกที่ผสาน LLM prompt กับการบันเดิลซอร์สโค้ด เพื่อค้นพบช่องโหว่ denial-of-service 3 รายการใน Django และ FastAPI (Starlette) (CVE-2025-64458, CVE-2025-64460, CVE-2025-62727)
สรุป
- หลังจากเห็นทีมอันดับต้น ๆ ใน DEF CON LiveCTF และ DARPA AIxCC ใช้ LLM เจาะไบนารีและค้นหา 0-day ใหม่ ๆ ก็รู้สึกว่าในงาน offensive research จริง ๆ แล้ว LLM อาจมีประสิทธิภาพเหนือกว่ามนุษย์ได้
- เมื่อไล่ดู GitHub archive และการออกแบบ RoboDuck ของทีมที่เข้าร่วม AIxCC (Team Atlanta, Theori) จึงรู้สึกว่าแนวทาง “ใช้ LLM หา bug แทนการ fuzzing” น่าจะนำมาปรับใช้กับ workflow การค้นหาช่องโหว่ได้
- โดยอาศัยบริบทที่สะสมมาจากการรายงานประเด็นด้านความปลอดภัยหลายรายการใน Django, DRF และ Python จึงตั้งเป้าหมายแรกอย่างชัดเจนว่าจะใช้ LLM ค้นหาช่องโหว่ใหม่ในกลุ่ม denial-of-service ของ Django framework
- ต่างจากโมเดลของผู้เข้าแข่งขัน AIxCC ที่ทำอัตโนมัติครบตั้งแต่การวิเคราะห์ไบนารีไปจนถึงการแพตช์ สำหรับ Django ซึ่งเป็นสคริปต์เบส ผู้เขียนออกแบบโครงสร้างที่ทำอัตโนมัติเฉพาะ “ขั้นตอนรวบรวม candidate ของ code segment ที่ดูน่าสงสัย” เพื่อจำกัดต้นทุนไว้เพียงไม่กี่ดอลลาร์
- ผู้เขียนกำหนดบทบาทให้ LLM เป็น “นักวิจัยความปลอดภัยที่ค้นหาช่องโหว่ใน Django” แล้วสร้างพรอมป์ตยาวที่รวมตัวอย่าง CVE diff ของ DoS, ข้อจำกัดใน
<tips> และตัวอย่างรูปแบบผลลัพธ์ไว้ด้วยกัน เพื่อกันข้อเสนอแพตช์ที่ไม่จำเป็นและลดสัดส่วน false positive
- ซอร์สโค้ด Django ถูกบันเดิลเป็น XML ตามไดเรกทอรีเดียวกัน แล้วแบ่งให้มีขนาดต่ำกว่า 40K โทเคนก่อนส่งให้ GPT-5 ทำให้สามารถไล่ตรวจทั้ง framework ได้ครบหนึ่งรอบโดยมีค่าใช้จ่ายรวมราว 5 ดอลลาร์
- เมื่อตรวจทาน candidate ที่เป็น false positive จาก workflow ก็กลับพบแพตเทิร์นที่เปราะบางซึ่งถูกมองข้ามมานานหลายปี อีกทั้งในขั้นตอนตัดสินความถูกต้อง LLM ยังแสดงความสามารถโดดเด่นในการอธิบาย root cause ของประเด็นความปลอดภัยและเขียน PoC
- ต่อมาผู้เขียนเปลี่ยนจาก OpenAI API ไปใช้ Codex CLI พร้อมพรอมป์ตใน AGENTS.md เพื่อให้ไล่สำรวจซอร์สของ Django แบบเชิงรุก และผลลัพธ์คือการค้นพบช่องโหว่ DoS แบบ O(n²) ในการจัดการ URL hostname ของ HttpResponseRedirectBase ซึ่งได้รับการลงทะเบียนเป็น CVE-2025-64458
- เมื่อนำพรอมป์ตเดียวกันไปใช้กับ FastAPI (ที่จริงคือ Starlette) ก็พบว่าลอจิกการรวม Range header ของ FileResponse สามารถก่อให้เกิด ReDoS ได้จากการประมวลผล O(n²) ที่อิง regex จึงถูกเปิดเผยเป็น CVE-2025-62727 และได้รับการประเมิน CVSS 8.7 (High) ตามเกณฑ์ของ Snyk
5 ความคิดเห็น
ลงมือทำได้สุดยอดมาก.. น่าชื่นชมครับ
เป็นกรณีศึกษาที่ดีมากจนถึงขั้นสามารถนำไปอ้างอิงในสไลด์นำเสนอภายนอกได้เลย ควรเก็บไว้ครับ
> ในแง่ของต้นทุน ผมคิดว่ายิ่งเป็นงานที่ต้องใช้บริบทสูงและต้องการพรอมป์ต์ที่ละเอียดและยาวมากเท่าไร ช่วงเวลาที่จะถูกทดแทนก็ยิ่งเลื่อนออกไปอย่างหลีกเลี่ยงไม่ได้
ผมคิดว่าประเด็นนี้ก็เป็นอินไซต์ที่ยอดเยี่ยมเช่นกัน
ผมเองก็แค่สนใจอยู่เหมือนกัน แต่ยังไม่ได้ลองลงลึกจริงจัง และบทความนี้ก็ให้ทั้งแรงจูงใจและอินไซต์ไปพร้อมกัน ขอแนะนำว่าเป็นบทความที่ดีครับ
เนื้อหาของบทความดีกว่าที่อคติแรกจากการอ่านสรุปทำให้คิดไว้มาก (พาดหัวล่อเป้า..) ใครที่สนใจแนะนำให้อ่านต้นฉบับครับ