Django ออกแพตช์ 6.1.2, 6.0.9 และ 5.2.18 อุดช่องโหว่ 4 รายการ รวม DoS ผ่าน HTTP header
Django ออกรุ่น 6.1.2, 6.0.9 และ 5.2.18 เมื่อ 6 ต.ค. 2026 แก้ช่องโหว่ 4 รายการ ระดับปานกลาง 3 รายการ รวม DoS จากการแยก HTTP header ที่โจมตีได้โดยไม่ต้องล็อกอิน
โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที
สรุปประเด็นสำคัญ
- ทีม Django ออกรุ่นแก้ไขความปลอดภัย 6.1.2, 6.0.9 และ 5.2.18 เมื่อ 6 ตุลาคม 2026 แก้ช่องโหว่ 4 รายการ ระดับ moderate 3 รายการและ low 1 รายการ และแนะนำให้ผู้ใช้ทุกรายอัปเกรดโดยเร็ว
- CVE-2026-84429 ทำให้การแยกค่า HTTP header ใช้เวลาแบบกำลังสอง คำขอที่ไม่ต้องล็อกอินส่งผ่าน header อย่าง Accept หรือ Content-Type ได้ จึงเสี่ยงต่อการโจมตีแบบ denial-of-service
- CVE-2026-87975 เปิดให้ข้อมูล POST ปลอมลบหรือสร้างระเบียนผ่าน model formset ที่ให้แก้ primary key ได้ ส่วน CVE-2026-87890 ใน GeoDjango อาจทำให้ GDAL ส่งคำขอเครือข่ายออกไปภายนอก
- วันที่ 8 ตุลาคม 2026 ทีมความปลอดภัยของ Django เลิกรับรายงานช่องโหว่ใหม่ผ่าน HackerOne ให้แจ้งทางอีเมล [email protected] แทน
- Django 6.0 ได้แพตช์ความปลอดภัยถึง เมษายน 2027 ส่วน 5.2 LTS ถึง เมษายน 2028 และ 4.2 LTS หมดซัพพอร์ตไปแล้วตั้งแต่ 7 เมษายน 2026
ทีม Django ออกรุ่นแก้ไขความปลอดภัย 6.1.2, 6.0.9 และ 5.2.18 เมื่อวันที่ 6 ตุลาคม 2026 อุดช่องโหว่ 4 รายการในทุกสายที่ยังมีซัพพอร์ต รายการที่องค์กรควรรีบดูที่สุดคือช่องโหว่ denial-of-service ในการแยกค่า HTTP header ซึ่งคำขอที่ไม่ต้องล็อกอินเข้าถึงได้ และช่องโหว่ใน model formset ที่เปิดให้ลบหรือสร้างข้อมูลเกินสิทธิ์
สองวันต่อมา วันที่ 8 ตุลาคม 2026 ทีมความปลอดภัยของ Django ประกาศเลิกรับรายงานช่องโหว่ใหม่ผ่าน HackerOne และให้แจ้งทางอีเมลแทน
ช่องโหว่ 4 รายการที่ Django แก้ในรอบนี้
ประกาศของ Sarah Boyce ระบุรายละเอียดและระดับความรุนแรงตามนโยบายความปลอดภัยของ Django ไว้ดังนี้
| CVE | ส่วนที่ได้รับผล | ผลกระทบ | ระดับ |
|---|---|---|---|
| CVE-2026-84429 | parse_header_parameters() ที่ใช้แยกค่า HTTP header |
DoS จากเวลาประมวลผลแบบกำลังสอง ไม่ต้องล็อกอิน | moderate |
| CVE-2026-87975 | model formset ที่ให้แก้ primary key ได้ | ลบหรือสร้างระเบียนเกินขอบเขตด้วย POST ปลอม | moderate |
| CVE-2026-87890 | spatial lookup ของ GeoDjango ที่รับค่า raster เป็น bytes | GDAL ส่งคำขอเครือข่ายในนามโพรเซสของ Django | moderate |
| CVE-2026-77050 | get_supported_language_variant() |
ใช้หน่วยความจำมากเกินจากรหัสภาษาที่ยาวผิดปกติ | low |
ช่องโหว่ใน HTTP header และ model formset ที่ผู้ใช้ Django ต้องรีบปิด
ช่องโหว่ใน HTTP header (CVE-2026-84429) เกิดเมื่อค่าในเครื่องหมายคำพูดมีตัวคั่นจำนวนมาก ฟังก์ชันจะใช้เวลาเพิ่มแบบกำลังสอง คำขอจากผู้ที่ไม่ได้ล็อกอินส่งค่าแบบนี้ผ่าน header อย่าง Accept หรือ Content-Type ได้ เช่นผ่านการเลือกรูปแบบเนื้อหาของ HttpRequest.accepts() และขีดจำกัดความยาวต่อครั้งไม่ได้คุมขนาดรวมของ header ที่ส่งซ้ำ Django แก้โดยเปลี่ยนไปใช้ email.message.Message ของ Python ผลข้างเคียงคือ header ที่ผิดรูปแบบบางแบบจะถูกแยกค่าต่างจากเดิม
ช่องโหว่ใน model formset (CVE-2026-87975) กระทบโมเดลที่ให้กำหนด primary key ผ่านฟอร์มได้ เช่นใช้ OneToOneField หรือ parent link เป็น primary key ของ inline formset หรือใส่ natural key หรือ UUID primary key ไว้ในฟิลด์ของฟอร์ม ข้อมูล POST ปลอมจะลบระเบียนนอก queryset ที่จำกัดไว้ หรือสร้างระเบียนใหม่ผ่าน formset ที่ควรแก้ไขได้อย่างเดียว โมเดลที่ใช้ BigAutoField ตามค่าเริ่มต้นไม่ได้รับผล
ช่องโหว่ใน GeoDjango และการจัดการรหัสภาษา
ช่องโหว่ใน GeoDjango (CVE-2026-87890) เกิดจาก spatial lookup ที่รับค่า raster เป็น bytes โดยไม่ต้องห่อด้วย GDALRaster ค่านั้นอาจเป็นเอกสาร VRT ที่อ้างแหล่ง raster ภายนอก ทำให้ GDAL ส่งคำขอเครือข่ายออกไปในนามผู้ใช้ที่รันโพรเซสของ Django ประกาศระบุว่าจุดนี้ตกหล่นไปจากการแก้ CVE-2026-15307 ครั้งก่อน การแก้รอบนี้ไม่เข้ากันกับโค้ดเดิม เพราะค่า bytes ต้องห่อด้วย GDALRaster ก่อนใช้ ยกเว้นค่าที่เป็น hexadecimal geometry
ส่วน CVE-2026-77050 ระดับ low เกิดจากรหัสภาษาที่ยาวผิดปกติจำนวนมากถูกใช้เป็นคีย์ของแคชก่อนถูกจำกัดความยาว Django แก้โดยปฏิเสธหรือตัดรหัสภาษาที่ยาวเกิน 500 ตัวอักษรก่อนค้นในแคช ทบทวนความหมายของรหัสช่องโหว่ได้ที่ CVE คืออะไร
Django เลิกรับรายงานช่องโหว่ผ่าน HackerOne
ประกาศวันที่ 8 ตุลาคม 2026 ของ Django Security Team สั้นมาก ทีมไม่รับรายงานความปลอดภัยใหม่ผ่าน HackerOne แล้ว รายงานเดิมที่ส่งเข้ามาทางนั้นยังเปิดอยู่และได้รับการดูแลต่อ ผู้ที่พบช่องโหว่ให้ส่งอีเมลไปที่ [email protected] ตามนโยบายความปลอดภัยของโครงการ และไม่แจ้งผ่าน Trac หรือ Django Forum ซึ่งเป็นพื้นที่สาธารณะ ประกาศไม่ได้ให้เหตุผลของการเปลี่ยนแปลง
ทำไมเรื่องนี้สำคัญ: รอบซัพพอร์ตของ Django กำลังเปลี่ยน
แพตช์รอบนี้ออกให้เฉพาะ 6.1, 6.0 และ 5.2 ตามตาราง Supported Versions ของ Django ซึ่งแบ่งซัพพอร์ตเป็นสองช่วง ช่วง mainstream ได้รับแก้ทั้งช่องโหว่ บั๊กที่ทำข้อมูลหาย บั๊กที่ทำให้ระบบล่ม บั๊กสำคัญในฟีเจอร์ใหม่ และ regression ส่วนช่วง extended ได้รับเฉพาะแก้ช่องโหว่และบั๊กที่ทำข้อมูลหาย
| สาย | รุ่นล่าสุด | สิ้นสุด mainstream | สิ้นสุด extended |
|---|---|---|---|
| 5.2 LTS | 5.2.18 | 3 ธ.ค. 2025 | เม.ย. 2028 |
| 6.0 | 6.0.9 | 4 ส.ค. 2026 | เม.ย. 2027 |
| 6.1 | 6.1.2 | เม.ย. 2027 | ธ.ค. 2027 |
| 6.2 LTS (ออก เม.ย. 2027) | – | ธ.ค. 2027 | เม.ย. 2030 |
Django 4.2 LTS หมดซัพพอร์ตไปแล้วตั้งแต่ 7 เมษายน 2026 จึงไม่อยู่ในรายการรุ่นที่ได้แพตช์ หน้าเดียวกันยังระบุการเปลี่ยนนโยบายครั้งใหญ่ Django 6.2 จะเป็นรุ่นสุดท้ายที่ใช้เลขแบบเดิม ตั้งแต่ Django 2028 รุ่นใหม่จะใช้เลขปีและออกทุกเดือนมกราคม และทุกรุ่นจะได้ซัพพอร์ต 3 ปีเท่ากัน ไม่ใช่เฉพาะรุ่น LTS แบบที่ผ่านมา
สิ่งที่องค์กรไทยควรทำ
- อัปเดต Django ทุกระบบภายในสัปดาห์นี้ เป็น 6.1.2, 6.0.9 หรือ 5.2.18 ตามสายที่ใช้ โดยเฉพาะเว็บที่เปิดสู่อินเทอร์เน็ต เพราะช่องโหว่ใน HTTP header โจมตีได้โดยไม่ต้องล็อกอิน
- ค้นโค้ดหา model formset และ inline formset ที่ใส่ primary key แบบ natural key, UUID หรือ OneToOneField ไว้ในฟิลด์ของฟอร์ม แล้วทดสอบหลังอัปเดตว่าการลบและสร้างข้อมูลยังถูกจำกัดตามสิทธิ์
- ทีมที่ใช้ GeoDjango ตรวจว่ามีจุดที่ส่งค่า bytes จากผู้ใช้เข้า spatial lookup โดยตรงหรือไม่ เพราะหลังอัปเดตค่าเหล่านั้นต้องห่อด้วย
GDALRasterและควรตรวจสอบข้อมูลจากผู้ใช้ก่อนเสมอ - วางแผนย้ายออกจาก 4.2 และ 6.0 ระบบที่ยังอยู่บน 4.2 ไม่ได้แพตช์ความปลอดภัยแล้ว ส่วน 6.0 ได้แพตช์ถึงเมษายน 2027 เท่านั้น ทางเลือกระยะยาวคือ 5.2 LTS ซึ่งซัพพอร์ตถึงเมษายน 2028 หรือรอ 6.2 LTS ในเดือนเมษายน 2027
- ปรับขั้นตอนแจ้งช่องโหว่ภายใน ทีมที่ทดสอบเจาะระบบหรือทำ bug bounty ควรส่งรายงานช่องโหว่ของ Django ทางอีเมลแทน HackerOne ติดตามข่าวซอฟต์แวร์และ DevOps เพิ่มเติมได้ที่หมวดซอฟต์แวร์
คำถามที่พบบ่อย
Django รุ่นไหนที่ต้องอัปเดตจากแพตช์ 6 ตุลาคม 2026?
ทุกสาย Django ที่ยังมีซัพพอร์ตได้รับผลกระทบ คือ 6.1, 6.0 และ 5.2 ให้อัปเดตเป็น Django 6.1.2, 6.0.9 หรือ 5.2.18 ตามสายที่ใช้อยู่ ทีม Django แนะนำให้ผู้ใช้ทุกรายอัปเกรดโดยเร็วที่สุด ส่วนรุ่นที่หมดซัพพอร์ตแล้วอย่าง 4.2 ไม่มีแพตช์ออกมา
ช่องโหว่ Django CVE-2026-84429 อันตรายแค่ไหน?
CVE-2026-84429 อยู่ระดับ moderate ตามนโยบายความปลอดภัยของ Django ฟังก์ชันแยกค่า HTTP header ใช้เวลาแบบกำลังสองเมื่อค่าในเครื่องหมายคำพูดมีตัวคั่นจำนวนมาก ผู้โจมตีที่ไม่ได้ล็อกอินส่งค่าผ่าน header อย่าง Accept หรือ Content-Type ได้ จึงใช้ทำให้เซิร์ฟเวอร์ทำงานหนักจนให้บริการไม่ได้
แอป Django แบบไหนได้รับผลจากช่องโหว่ใน model formset?
CVE-2026-87975 กระทบ model formset ที่ผู้ใช้กำหนด primary key ได้ผ่านฟอร์ม เช่นโมเดลที่ใช้ OneToOneField หรือ parent link เป็น primary key ของ inline formset และโมเดลที่ใส่ natural key หรือ UUID primary key ไว้ใน fields ข้อมูล POST ปลอมจึงลบระเบียนนอก queryset ที่จำกัดไว้หรือสร้างระเบียนผ่าน formset ที่ควรแก้ไขได้อย่างเดียว ส่วนโมเดลที่ใช้ BigAutoField ตามค่าเริ่มต้นไม่ได้รับผล
ถ้าพบช่องโหว่ใน Django ต้องแจ้งที่ไหน?
ตั้งแต่ 8 ตุลาคม 2026 ทีมความปลอดภัยของ Django ไม่รับรายงานใหม่ผ่าน HackerOne แล้ว ให้ส่งอีเมลไปที่ [email protected] ตามขั้นตอนใน Django security policies และไม่โพสต์ใน Trac หรือ Django Forum ส่วนรายงานเดิมที่ส่งผ่าน HackerOne ยังได้รับการดูแลต่อ
แหล่งอ้างอิง
- Django security releases issued: 6.1.2, 6.0.9, and 5.2.18 — Django Software Foundation
- Django security reporting update — Django Software Foundation
- Download Django: Supported Versions — Django Software Foundation
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ