pip 26.2.2 มาแล้ว: อัปเดตเครื่องอย่างเดียวอาจยังไม่พอ หลังเหตุ emSign

กุญแจลับของใบรับรองตัวกลาง eMudhra จำนวน 8 ใบถูกระบุว่าถูกกระทบความปลอดภัย ตามบทความของ Simon Willison วันที่ 20 ตุลาคม 2026 และในกระทู้ Python.org มีคำอธิบายว่ากุญแจของทั้งแปดมีค่าที่อ่อนแอ เรื่องนี้จึงเกี่ยวกับความน่าเชื่อถือของการเชื่อมต่อที่โปรแกรมใช้รับส่งข้อมูลโดยตรง (Simon Willison, Python.org)

สำหรับคนใช้ Python ทำงาน จุดที่ต้องรีบเช็กคือ pip เครื่องมือติดตั้งชุดโปรแกรมเสริม และ certifi ชุดข้อมูลใบรับรองที่โปรแกรมใช้ตัดสินใจว่าจะเชื่อถือการเชื่อมต่อหรือไม่ ประกาศ Python.org แนะนำให้อัปเดตเป็น pip อย่างน้อย 26.2.2 และ certifi 2026.10.19 พร้อมสร้างอิมเมจคอนเทนเนอร์ใหม่ เพราะการปล่อยของเก่าไว้อาจเปิดโอกาสให้เกิดการแทรกกลางการเชื่อมต่อ รวมถึงการติดต่อ python.org และ pypi.org (Python.org)

ผมอยากให้คนที่มีสคริปต์ช่วยงาน รายงานข้อมูล หรือระบบธุรกิจอ่านประเด็นนี้ให้ถึงขั้นตอนตรวจสอบครับ เพราะในกรณีของ pip การแก้รายชื่อใบรับรองที่ระบบปฏิบัติการไว้ใจเพียงอย่างเดียวยังไม่พอ ตัว pip มีรายชื่ออีกชุดติดมาด้วย และยังใช้ชุดนั้นร่วมกับของระบบ (Python.org)

สรุป 30 วินาที: เกิดอะไรขึ้น

• ประกาศความปลอดภัยของ certifi ระบุว่าใบรับรองตัวกลางภายใต้ราก emSign ถูกเพิกถอนเพราะปัญหากุญแจลับ และกุญแจของหน่วยงานออกใบรับรองที่ถูกกระทบสามารถถูกใช้สร้างใบรับรองเพื่อการโจมตีแบบแทรกกลางได้ (GitHub: certifi advisory)
• pip 26.2.2 ออกวันที่ 20 ตุลาคม 2026 โดยบันทึกการเปลี่ยนแปลงระบุว่าอัปเดต certifi ที่ฝังมาด้วยเป็น 2026.10.19 (pip changelog)
• รายละเอียดในงานติดตามของ CPython ระบุว่าชุดใหม่นำ emSign Root CA - G3 ออก หลังใบรับรองตัวกลาง G3 ที่ได้รับผลกระทบถูกเพิกถอน และยังเก็บราก emSign ที่ไม่ได้รับผลกระทบไว้ (GitHub: CPython)
• ประกาศสำหรับผู้ใช้ Python ขอให้อัปเดตเครื่องมือในสภาพแวดล้อมเสมือนที่มีอยู่ทุกชุด และสร้างอิมเมจคอนเทนเนอร์ใหม่เพื่อรับใบรับรองระบบล่าสุด (Python.org)

ทำไมเรื่องนี้เกี่ยวกับคุณ

คนที่กดติดตั้งแพ็กเกจเพื่อทำรายงาน วิเคราะห์ข้อมูล หรือดูแลระบบอัตโนมัติ ควรให้ความสำคัญกับตัวติดตั้งด้วย Christian Heimes อธิบายในกระทู้ว่า pip รุ่นต่ำกว่า 26.2.2 ยังเชื่อถือใบรับรองตัวกลางที่มีปัญหาผ่าน certifi ที่ติดมากับตัวเอง แม้ระบบปฏิบัติการจะเลิกเชื่อถือไปแล้ว การอัปเดต pip จึงเป็นวิธีแก้ที่เขาระบุว่าเชื่อถือได้สำหรับกรณีนี้ (Python.org)

สำหรับพนักงานออฟฟิศ นักศึกษา หรือเจ้าของกิจการที่ใช้โปรแกรมซึ่งมีคนอื่นดูแล ข้อเสนอของผมคือส่งข่าวนี้ให้ผู้รับผิดชอบระบบตรวจสอบ แหล่งข้อมูลยังไม่ได้บอกว่าองค์กรใดในไทยได้รับผลกระทบ แต่ธุรกิจในไทยที่ใช้ pip หรือ certifi ก็ควรเช็กตามคำแนะนำเดียวกัน ขอบเขตคำเตือนจาก Python.org ครอบคลุมทั้งแพ็กเกจที่ติดตั้งไว้และอิมเมจที่ใช้รันงาน (Python.org)

อีกคำที่ต้องรู้คือ virtual environment หรือ venv ซึ่งเป็นสภาพแวดล้อมแยกสำหรับชุดโปรแกรมของงานหนึ่ง ๆ ในกระทู้มีคำแนะนำให้จัดการทุกชุดที่มีอยู่ ผมจึงแนะนำให้ตรวจตามรายชื่อโปรเจกต์ที่ใช้งานจริงด้วย การเห็นเวอร์ชันใหม่ในสภาพแวดล้อมหนึ่งยังไม่ใช่หลักฐานว่าตรวจครบตามขอบเขตที่ประกาศขอแล้ว (Python.org)

ทำงานยังไง

CA หรือหน่วยงานออกใบรับรอง ทำหน้าที่อยู่ในระบบความเชื่อถือของการเชื่อมต่อ ใบรับรองรากเป็นจุดตั้งต้นที่ซอฟต์แวร์เลือกไว้ใจ ส่วนใบรับรองตัวกลางเชื่อมความเชื่อถือนั้นไปยังใบรับรองอื่น ประกาศ certifi อธิบายว่าปัญหากุญแจของ CA สามารถนำไปสู่การออกใบรับรองสำหรับโจมตีแบบแทรกกลางได้ จึงต้องนำรากที่เกี่ยวข้องออกจากชุดที่เชื่อถือ (GitHub: certifi advisory)

TLS คือระบบป้องกันการเชื่อมต่อที่ประกาศ Python.org พูดถึง ส่วน MITM หรือการแทรกกลาง คือความเสี่ยงที่ผู้โจมตีเข้ามาคั่นการสื่อสารด้วยความเชื่อถือที่ผิด ประกาศเตือนถึงไคลเอนต์ TLS ซึ่งหมายถึงฝั่งโปรแกรมที่เริ่มเชื่อมต่อ และยกการติดต่อ python.org กับ pypi.org เป็นตัวอย่างของสิ่งที่อาจได้รับผลกระทบ (Python.org)

CA bundle คือชุดใบรับรองที่โปรแกรมนำมาใช้เป็นรายการความเชื่อถือ ส่วน certifi เป็นแพ็กเกจที่จัดเตรียมชุดนี้ คำว่า vendored ในบันทึกของ pip หมายถึงการนำส่วนประกอบนั้นมารวมไว้ภายในตัวโปรแกรมเอง pip 26.2.2 จึงมีการเปลี่ยน certifi ภายในเป็นรุ่น 2026.10.19 โดยตรง ไม่ได้มีแค่คำแนะนำให้ผู้ใช้ไปแก้ค่าระบบ (pip changelog, Python.org)

ลองนึกถึง สมุดรายชื่อร้านที่เชื่อถือได้ที่แต่ละแอปพกติดตัวเอง ครับ เราแก้สมุดกลางของบ้าน ซึ่งเปรียบกับระบบปฏิบัติการแล้ว แต่ลูก ๆ ยังถือสมุดเล่มเก่าของตัวเองอยู่ สำหรับ pip สมุดที่พกมาคือ certifi ภายในตัวมัน และคำอธิบายในกระทู้ระบุว่า pip ใช้ทั้งชุดนี้และชุดของระบบร่วมกัน จึงต้องอัปเดตสมุดที่อยู่ใน pip ด้วย (Python.org)

รายละเอียดที่ชวนพลาดคือการกำหนดชุดใบรับรองเพิ่มเติมให้ pip ไม่ได้ลบความเชื่อถือจากชุดเดิม Christian Heimes ระบุว่าการตั้งค่าที่เกี่ยวข้องเป็นการเพิ่ม CA และไม่มีวิธีที่รองรับให้ปิด certifi ภายใน ดังนั้นอย่าใช้การปรับค่าใบรับรองเป็นเหตุผลข้ามการอัปเดต pip (Python.org)

จุดสังเกต: อัปเดต certifi แล้ว ยังต้องเช็ก pip แยก

จุดหักมุมของข่าวนี้คือชื่อ certifi ปรากฏได้ทั้งในคำแนะนำให้อัปเดตแพ็กเกจ และในฐานะส่วนประกอบที่ pip รวมมาเอง เหตุผลที่ต้องตรวจทั้งสองส่วนมาจากคำอธิบายเรื่อง certifi ภายใน pip และหลักฐานในบันทึกรุ่น 26.2.2 ที่ระบุการอัปเกรดส่วนประกอบนั้นโดยเฉพาะ ผมจึงเสนอให้บันทึกผลตรวจ pip กับ certifi แยกกัน เพื่อให้เห็นว่าทำครบทั้งสองรายการแล้ว (Python.org, pip changelog)

ฝั่ง CPython ซึ่งเป็นตัว Python ที่งานติดตามนี้กล่าวถึง มีประเด็นเรื่อง ensurepip ส่วนที่จัดเตรียม pip ที่ติดมากับ Python งานหมายเลข 159894 ขอเปลี่ยน pip ที่รวมมา จาก 26.2.1 เป็น 26.2.2 ขณะเดียวกัน Zachary Ware แจ้งในกระทู้ว่าการเปลี่ยนแปลงหลักถูกรวมแล้ว และยังมีงานนำกลับไปยังสายรุ่นก่อน พร้อมแผนออกรุ่นความปลอดภัยเมื่อทำได้ (GitHub: CPython, Python.org)

จุดนี้เกี่ยวกับงานที่จะสร้างใหม่ด้วย Paul Moore ยกประเด็นว่า ระหว่างรอ CPython รุ่นใหม่ การอัปเกรด pip หลังสร้าง venv ใหม่เป็นทางแก้ชั่วคราวที่อาจลืมได้ง่าย ผมจึงแนะนำให้เพิ่มขั้นตอนตรวจนี้ในขั้นตอนเริ่มโปรเจกต์ของทีม มากกว่าฝากไว้กับความจำของแต่ละคน (Python.org)

เรื่องเงิน / ผลกระทบ

ผลกระทบที่ยืนยันจากแหล่งข้อมูลคือความเสี่ยงต่อความน่าเชื่อถือของการเชื่อมต่อ ไม่ได้มีตัวเลขมูลค่าความเสียหาย จำนวนผู้เสียหายในไทย หรือหลักฐานว่าเงินของผู้ใช้รายใดถูกขโมย ประกาศ certifi กล่าวถึงความสามารถในการใช้กุญแจที่ถูกกระทบออกใบรับรองสำหรับ MITM ส่วน Python.org เตือนว่าการไม่อัปเดตอาจทำให้ไคลเอนต์ TLS เผชิญการโจมตีลักษณะนี้ (GitHub: certifi advisory, Python.org)

ในมุมการจัดงาน ผมแนะนำให้คิดงบเวลาเป็นรายการตรวจสภาพแวดล้อม อัปเดต ทดสอบงานเดิม และสร้างชุดใช้งานใหม่ตามความจำเป็น เหตุผลที่ต้องเผื่อเวลาให้หลายจุดคือประกาศขอให้อัปเดต venv ที่มีอยู่ทั้งหมดและสร้างอิมเมจคอนเทนเนอร์ใหม่ ไม่ได้จำกัดงานไว้ที่เครื่องของผู้พัฒนาเพียงเครื่องเดียว (Python.org)

คอนเทนเนอร์คือรูปแบบจัดชุดสภาพแวดล้อมสำหรับนำไปรันงาน ส่วนอิมเมจคือชุดที่ใช้ตั้งต้นสภาพแวดล้อมนั้น คำแนะนำของ Python.org ระบุชัดให้สร้างอิมเมจใหม่เพื่อรับใบรับรองระบบล่าสุด สำหรับทีมที่ส่งงานให้ลูกค้า ผมเสนอให้กำหนดผู้รับผิดชอบและหลักฐานเวอร์ชันของชุดที่จะส่งมอบ จะช่วยให้การปิดงานอัปเดตมีสิ่งตรวจสอบได้ (Python.org)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

certifi 2026.10.18 กับ 2026.10.19 ต้องอ่านพร้อมกัน ประกาศความปลอดภัยของ certifi ระบุว่ารุ่น 2026.10.18 นำราก emSign ออก แต่ประกาศ Python.org มีหมายเหตุแนะนำ 2026.10.19 เพื่อความเข้ากันได้กับราก emSign ที่ไม่ได้รับผลกระทบ จึงไม่ควรเอาเลขรุ่นในประกาศฉบับแรกมาแทนคำแนะนำล่าสุดในชุดข้อมูลนี้ (GitHub: certifi advisory, Python.org)

คำว่าเอา emSign ออกมีขอบเขตต่างกัน advisory ใช้ถ้อยคำกว้างว่าถอดรากจาก emSign ขณะที่งาน CPython อธิบาย certifi 2026.10.19 อย่างเจาะจงว่าเอา emSign Root CA - G3 ออกและเก็บรากที่ไม่กระทบไว้ บทความนี้จึงใช้รายละเอียดหลังเมื่อพูดถึงชุดที่มากับ pip 26.2.2 และไม่สรุปว่าราก emSign ทุกใบถูกนำออกในรุ่นที่แนะนำ (GitHub: certifi advisory, GitHub: CPython)

การรวมโค้ดกับการปล่อยตัวติดตั้งครบทุกสายรุ่นเป็นคนละสถานะ ข้อมูลที่ให้มามีทั้งงาน CPython และคำชี้แจงว่าการแก้หลักรวมแล้ว แต่ยังมีงานนำกลับไปสายรุ่นก่อนและแผนออกรุ่นความปลอดภัย จึงยังยืนยันไม่ได้จากชุดแหล่งข่าวนี้ว่าตัวติดตั้ง Python ทุกชุดที่ผู้ใช้กำลังดาวน์โหลดได้รับการเปลี่ยนแปลงแล้ว (GitHub: CPython, Python.org)

Python รุ่นเก่าไม่ควรถูกเหมารวมว่าปลอดภัย ในกระทู้มีผู้เขียนสคริปต์ชุมชนบอกว่าข้าม Python ที่เก่ากว่า 3.10 เพราะ pip 26.2.2 ไม่รองรับ และตั้งข้อสงสัยว่าสภาพแวดล้อมเหล่านั้นเสี่ยงหรือไม่ นั่นเป็นข้อสงสัยของผู้แสดงความคิดเห็น ไม่ใช่ข้อยืนยันว่าไม่มีผลกระทบ ผมแนะนำให้ผู้ดูแลตรวจแนวทางที่เข้ากับรุ่นของตนแทนการข้ามรายการนั้นไป (Python.org)

แล้วเราควรทำอะไร

นักพัฒนา: ตรวจทั้ง venv และรายการแพ็กเกจของโปรเจกต์

1. ทำรายชื่อสภาพแวดล้อมที่ใช้งานจริง แล้วตรวจให้ pip เป็นอย่างน้อย 26.2.2 และ certifi เป็นอย่างน้อย 2026.10.19 ตามคำแนะนำ Python.org อย่าปิดงานจากผลตรวจเพียงสภาพแวดล้อมเดียว (Python.org)
2. ผมแนะนำให้ตรวจ requirements ซึ่งเป็นรายการแพ็กเกจที่โปรเจกต์ต้องใช้ และ lockfile ซึ่งบันทึกรุ่นที่เลือกไว้ หากโปรเจกต์ใช้ certifi ให้ปรับเงื่อนไขขั้นต่ำเป็น certifi>=2026.10.19 ตามรุ่นที่แนะนำ พร้อมทบทวนข้อกำหนดเดิม ผู้แชร์สคริปต์ในกระทู้ระบุเองว่าเครื่องมือของเขาไม่ได้อัปเดตรายการเหล่านี้ให้อัตโนมัติ (Python.org)
3. เพิ่มการตรวจ pip หลังสร้าง venv ใหม่ไว้ในขั้นตอนของทีม ระหว่างติดตามการปรับ pip ที่มากับ CPython ประเด็นนี้ถูกยกเป็นทางแก้ชั่วคราวไว้ในกระทู้โดยตรง (Python.org)

DevOps และผู้ดูแลระบบ: ตรวจชุดที่ใช้สร้างงานและชุดที่รันงาน

1. สร้างอิมเมจคอนเทนเนอร์ใหม่ให้รับใบรับรองระบบล่าสุด และตรวจเวอร์ชัน pip กับ certifi ภายในตามประกาศ การอัปเดตรายการเชื่อถือของระบบอย่างเดียวไม่ครอบคลุม certifi ที่ pip รวมมา (Python.org)
2. ผมแนะนำให้ทบทวนแคชของ CI หรือข้อมูลที่ระบบสร้างและทดสอบงานอัตโนมัติเก็บไว้ใช้ซ้ำ แล้วตรวจผลลัพธ์ที่สร้างออกมาจริงว่าได้รุ่นเป้าหมาย คำแนะนำนี้เป็นขั้นตอนตรวจความครบถ้วนต่อจากข้อกำหนดให้อัปเดตสภาพแวดล้อมและสร้างอิมเมจใหม่ ไม่ใช่รายงานว่ามี CI รายใดถูกโจมตี (Python.org)
3. ถ้าใช้ uv เครื่องมือจัดการงาน Python อีกตัว ให้ตรวจรุ่นด้วย Simon Willison ระบุว่า uv 0.13.4 ออกพร้อมรายการใบรับรองที่อัปเดตแล้ว ส่วนบันทึก pip ยืนยัน certifi 2026.10.19 ภายใน pip 26.2.2 แยกต่างหาก (Simon Willison, pip changelog)

คนทำข้อมูลและผู้ใช้โน้ตบุ๊ก: ให้ผู้ดูแลตรวจสภาพแวดล้อมที่เปิดงานนั้น

1. ถ้าคุณใช้โน้ตบุ๊กสำหรับเขียนและรันโค้ดเป็นช่วง ๆ ผมแนะนำให้ส่งชื่อสภาพแวดล้อมที่ใช้งานให้ผู้ดูแลตรวจ pip และ certifi ตามรุ่นที่ประกาศกำหนด เป้าหมายคือครอบคลุมสภาพแวดล้อมที่มีอยู่ตามคำเตือนของ Python.org (Python.org)
2. หลังอัปเดต ผมแนะนำให้ลองงานประจำที่ต้องเชื่อมต่ออีกครั้ง และเก็บผลตรวจเวอร์ชันไว้ประกอบการส่งต่องาน เหตุที่ควรตรวจการใช้งานจริงด้วยคือคำแนะนำรุ่น 2026.10.19 มีเรื่องความเข้ากันได้กับราก emSign ที่ไม่กระทบรวมอยู่ด้วย (Python.org)

คนส่งมอบแอป Python และคนใช้โปรแกรมสำเร็จรูป

1. ผู้ส่งมอบควรตรวจส่วนประกอบใบรับรองที่รวมอยู่ในชุดแอป และประเมินว่าต้องสร้างชุดส่งมอบใหม่หรือไม่ Simon Willison ย้ำว่าซอฟต์แวร์ที่รวมรายชื่อใบรับรองที่เชื่อถือไว้ต้องได้รับการอัปเดต ชุดข้อมูลนี้ไม่ได้แจกแจงว่าแอปสำเร็จรูปรายใดได้รับผลกระทบ (Simon Willison)
2. ผู้ใช้งานทั่วไปควรขอให้ผู้พัฒนาหรือผู้ดูแลยืนยันสถานะส่วนประกอบในโปรแกรมนั้น ผมเสนอให้ใช้คำถามที่ตรวจสอบได้ เช่น ชุดที่ส่งมอบใช้รายการใบรับรองที่อัปเดตแล้วหรือยัง เพราะคำเตือนเรื่องรายชื่อที่รวมกับซอฟต์แวร์ไม่ได้จำกัดอยู่แค่ชุดของระบบปฏิบัติการ (Simon Willison)

หลักฐานที่ควรเก็บหลังอัปเดต

ผมแนะนำให้เก็บชื่อโปรเจกต์ สภาพแวดล้อม และเวอร์ชันที่ตรวจพบคู่กัน โดยมีเป้าหมายอ้างอิงที่ชัดคือ pip 26.2.2 ซึ่งบันทึกการเปลี่ยนแปลงยืนยันว่าอัปเกรด certifi ภายในเป็น 2026.10.19 และคำแนะนำให้ตรวจ certifi ที่ใช้งานแยกด้วย หลักฐานลักษณะนี้ช่วยให้คนรับงานต่อเห็นว่าตรวจอะไรไปแล้วตามขอบเขตประกาศ (pip changelog, Python.org)

อีกจุดคือความปลอดภัยของการอัปเดตเอง ในกระทู้มีคำถามว่าการใช้ pip เก่าดาวน์โหลด pip ใหม่จะเสี่ยงหรือไม่ Seth Michael Larson ตอบด้วยแนวทางตรวจค่า SHA256 หรือค่าตรวจความตรงกันของไฟล์ และติดตั้งจากแหล่งโดยตรงที่ผูกค่านั้นไว้ ผมแนะนำให้ทีมใช้คำแนะนำต้นฉบับตามสภาพแวดล้อมของตน และตรวจทั้งแหล่งไฟล์กับค่าตรวจสอบให้ตรงกัน (Python.org)

สำหรับ Python บน macOS ที่ติดตั้งจาก python.org ประกาศระบุโดยเฉพาะว่ามี certifi CA bundle รวมมาด้วย และให้ขั้นตอนอัปเดตใบรับรองกับ pip สำหรับการติดตั้งนั้น ผู้ใช้กลุ่มนี้จึงควรอ่านรายละเอียดของชุดติดตั้งที่ตัวเองใช้ก่อนดำเนินการ ไม่ควรสรุปจากการอัปเดตระบบปฏิบัติการเพียงอย่างเดียว (Python.org)

ผมมองว่า…

ผมมองว่า ในเชิงความเห็น บทเรียนของข่าวนี้ ไม่ใช่การจำเลขเวอร์ชันให้แม่น แต่คือการรู้ว่างานของเราใช้ชุดความเชื่อถือจากที่ไหน เหตุผลที่ผมให้ความสำคัญกับเรื่องนี้คือคำอธิบายของผู้พัฒนาในกระทู้ว่า pip ยังใช้ certifi ภายในร่วมกับของระบบ การตรวจเพียงจุดเดียวจึงไม่ตอบขอบเขตที่ประกาศเตือนไว้ (Python.org)

ในมุมการทำงาน ผมอยากให้ทีมจบเรื่องนี้ด้วยรายการสภาพแวดล้อมที่มีผู้รับผิดชอบและผลตรวจที่ส่งต่อได้ การเพิ่มขั้นตอนตรวจหลังสร้าง venv และหลังสร้างชุดใช้งานเป็นข้อเสนอของผม เพื่อตอบประเด็นที่กระทู้ยกไว้เรื่อง pip ที่มากับ Python และความง่ายที่จะลืมอัปเกรดเมื่อเริ่มสภาพแวดล้อมใหม่ (Python.org)

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรติดตามต่อคือการอัปเดตประกาศ Python.org ซึ่งระบุว่าจะเพิ่มเติมข้อมูล และความคืบหน้าการนำ pip 26.2.2 ไปอยู่ในชุด CPython สายรุ่นต่าง ๆ ข้อมูลปัจจุบันบอกว่าการแก้หลักรวมแล้วและมีแผนออกรุ่นความปลอดภัย แต่ยังไม่ใช่หลักฐานว่าตัวติดตั้งทุกชุดอัปเดตครบแล้ว (Python.org, GitHub: CPython)

ระหว่างติดตามข่าว งานที่ประกาศให้ทำชัดแล้วคืออัปเดต pip และ certifi ตรวจสภาพแวดล้อมที่มีอยู่ และสร้างอิมเมจคอนเทนเนอร์ใหม่ ผมแนะนำให้เริ่มจากงานที่ยังใช้งานจริง แล้วเก็บรายการส่วนที่ยังต้องแก้ให้เห็นชัด เพื่อให้การติดตามรอบถัดไปมีจุดตั้งต้นครับ (Python.org)

Recap

• ตรวจ pip ให้เป็นอย่างน้อย 26.2.2 ตามประกาศ (Python.org)
• ตรวจ certifi ให้ถึงรุ่นแนะนำ 2026.10.19 ซึ่งคำนึงถึงราก emSign ที่ไม่กระทบด้วย (Python.org)
• ตรวจ venv ที่มีอยู่ทั้งหมด และเพิ่มการตรวจ pip เมื่อสร้างชุดใหม่ (Python.org)
• ทบทวนข้อกำหนดแพ็กเกจและ lockfile เพราะสคริปต์ชุมชนที่แชร์ไม่ได้แก้รายการเหล่านี้ให้ (Python.org)
• สร้างอิมเมจคอนเทนเนอร์ใหม่ตามคำแนะนำ และตรวจผลลัพธ์ที่นำไปใช้งาน (Python.org)
• ตรวจซอฟต์แวร์ที่รวมรายการใบรับรองของตัวเอง และตรวจ uv 0.13.4 หากใช้งาน (Simon Willison)
• ตรวจแนวทางยืนยันไฟล์อัปเดตด้วย SHA256 จากคำแนะนำต้นฉบับ (Python.org)
• ติดตาม pip ที่รวมมากับ CPython และสถานะรุ่นความปลอดภัยต่อไป (GitHub: CPython, Python.org)