Python ปล่อยแพตช์ความปลอดภัยด่วนพร้อมกันห้าสายรุ่นเมื่อวันที่ 25 ตุลาคม 2026 ได้แก่ 3.15.2, 3.14.10, 3.13.18, 3.12.16 และ 3.11.18 สาเหตุหลักมาจากกุญแจของ intermediate CA จาก eMudhra ถูกเปิดเผย ทำให้ทีมงานต้องเร่งปิดช่องทางปลอมแปลงใบรับรอง TLS ทันที
เกิดอะไรขึ้น
ประกาศในชุมชน Python ระบุว่าเหตุการณ์นี้ทำให้จำเป็นต้องถอด root CA ของ emSign ออกจากชุดใบรับรองอย่าง certifi เพราะหากไม่อัปเดต ฝั่ง TLS client อาจเสี่ยงต่อการถูกดักข้อมูลตรงกลาง รวมถึงการเชื่อมต่อไปยัง python.org และ pypi.org ด้วย
ใน Python รุ่นใหม่ โมดูล ssl จะปฏิเสธ certificate chain ที่มีกุญแจ intermediate ซึ่งถูกเปิดเผย โดย changelog ระบุว่าวิธีนี้เป็นมาตรการพิเศษและเป็นแนวป้องกันด่านสุดท้าย เนื่องจากหน้าที่หลักในการเพิกถอนความเชื่อถือยังเป็นของ root store บนแต่ละแพลตฟอร์ม รายการบล็อกนี้จึงทำขึ้นเพื่อช่วยอุดช่องว่างระหว่างที่การอัปเดตยังส่งไปไม่ถึงระบบปฏิบัติการ, container image หรือชุดใบรับรองในแพ็กเกจของ Python
นอกจากนี้ ในรอบเดียวกันยังมีการแก้ไขประเด็นอื่นๆ ด้วย
| รายการ | สิ่งที่เปลี่ยน | รุ่นที่ควรสนใจ |
|---|---|---|
| CVE-2026-115557 | ssl ปฏิเสธกุญแจ intermediate ของ eMudhra ที่ถูกเปิดเผย | ทุกสายรุ่นที่ออกรอบนี้ |
| CVE-2026-114583 | tarfile.tar_filter() ปฏิเสธลิงก์ที่ชี้แทนที่โฟลเดอร์ปลายทาง | ทุกสายรุ่นที่ออกรอบนี้ |
| gh-160300 | http.cookiejar ไม่รับ cookie ที่ Version ติดลบ ซึ่งเดิมข้ามการตรวจโดเมน | ทุกสายรุ่นที่ออกรอบนี้ |
| CVE-2026-77214, CVE-2026-102633 | อัปเดต Expat ที่ฝังมาเป็น 2.9.0 | 3.13.18, 3.12.16 และ 3.11.18 ตามหน้ารีลีส |
ใครได้รับผล
กลุ่มแรกคือทุกทีมที่รันแอป Python ซึ่งเชื่อมต่อ HTTPS ผ่านโมดูล ssl ตลอดจนระบบ build ที่ต้องดึงแพ็กเกจจาก PyPI เพราะตามประกาศ ความเสี่ยงไม่ได้หยุดอยู่แค่ที่ตัว interpreter เท่านั้น แต่เครื่องมืออย่าง pip, certifi และ uv ต่างก็มีชุดใบรับรองหรือวิธีตรวจสอบของตัวเอง
กลุ่มที่สองคือทีมที่ยังใช้งาน Python 3.10 หรือเก่ากว่านั้น โดยตารางสถานะของ Python ระบุว่า 3.10 หมดอายุการสนับสนุนไปแล้วตั้งแต่วันที่ 1 ตุลาคม 2026 และประกาศระบุชัดว่าสายรุ่นเหล่านี้จะไม่ได้รับการอัปเดตความปลอดภัยอีกต่อไป
สำหรับแอปที่มีการแตกไฟล์ tar จากภายนอกด้วย tar_filter และแอปที่แชร์ CookieJar ร่วมกันระหว่างหลายเซิร์ฟเวอร์ ก็ควรเช็กรายการแก้ไขที่เหลือด้วยเช่นกัน โดยรายงาน gh-160300 อธิบายว่า เซิร์ฟเวอร์ปลายทางที่ถูกเรียกอาจตั้งค่าหรือเขียนทับ cookie ของโดเมนอื่นได้ แต่ไม่ได้ทำให้ cookie เดิมรั่วไหลกลับไปยังเซิร์ฟเวอร์นั้น
ควรทำอะไร
- อัปเกรด Python ให้เป็นรุ่นที่ระบุไว้ข้างต้น ทั้งบนเครื่องพัฒนาและ image ที่ใช้งานจริงบนโปรดักชัน
- อัปเกรดเครื่องมือในทุก virtual environment โดยดูรายการขั้นต่ำในประกาศ ได้แก่ certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4, pixi 0.82.1 และ virtualenv 21.14.12
- อัปเกรด pip ด้วยคำสั่งในประกาศ ซึ่งจะระบุ URL ของ wheel พร้อมเช็ก SHA-256 ให้เรียบร้อย จากนั้นค่อยใช้ pip เวอร์ชันใหม่นี้ไปอัปเกรด certifi และ uv ต่อ
- Build container image ใหม่โดยปิด layer cache เพื่อดึงใบรับรองล่าสุดของระบบเข้ามา และหลีกเลี่ยงการใช้เลเยอร์เดิมที่ตกค้าง
- เครื่อง macOS ที่ติดตั้งจาก python.org ต้องอัปเกรด pip และ certifi ใน Python ระดับ framework ตามตัวอย่างในประกาศ รวมถึงรุ่น free-threaded หากติดตั้งไว้ใช้งาน
- ตรวจ lockfile หากโปรเจกต์มีการล็อกเวอร์ชันของ certifi หรือเครื่องมือรุ่นเก่าไว้ ควรอัปเดตให้ได้ตามรุ่นขั้นต่ำก่อนจะสั่ง build รอบถัดไป เพราะการ build ใหม่จะยังคงติดตั้งตามรุ่นที่ระบุไว้ใน lockfile
ข้อจำกัด
ในหน้ารีลีส 3.15.2 ระบุว่าเมื่อรันบน Python รุ่นนี้ การใช้งาน pip ตามปกติรวมถึงการสั่งอัปเกรด pip จะปลอดภัยจากการโจมตีด้วยกุญแจชุดดังกล่าวแล้ว แม้จะยังไม่ได้อัปเดต pip ก็ตาม แต่นี่คุ้มครองเฉพาะบน Python รุ่นที่ได้รับแพตช์แล้วเท่านั้น ซึ่งประกาศในชุมชนยังคงแนะนำให้อัปเกรดทั้ง pip และ certifi ในทุก environment อยู่ดี เราจึงแนะนำให้จัดการควบคู่กันไปทั้งสองส่วน
รายการบล็อกในโมดูล ssl ไม่ได้ทำหน้าที่แทนการอัปเดตชุดใบรับรองของระบบปฏิบัติการ และไม่ครอบคลุมโปรแกรมที่ไม่ได้ตรวจสอบใบรับรองผ่าน ssl ของ Python รุ่นที่แก้แล้ว นอกจากนี้ ประกาศยังอาจอัปเดตเพิ่มเมื่อมีข้อมูลใหม่ จึงควรเข้าไปตรวจสอบอีกครั้งก่อนลงมือ ทั้งนี้ บทความนี้เป็นการสรุปข้อมูลจากเอกสารทางการของโครงการ โดยไม่ได้มีการทดสอบการโจมตีจริง
สำหรับทีมที่ใช้ Go หรือ Rust สามารถอ่านแนวทางรับมือของภาษาเหล่านั้นเพิ่มเติมได้ที่บทความ Go และ rustup กับกรณี eMudhra
