ปัญหาใบรับรอง eMudhra ทำให้หลายโครงการต้องปรับความเชื่อถือใน certificate chain แต่การแก้ที่ตัวติดตั้ง toolchain กับการแก้ verifier ในแอปเป็นคนละชั้น Go เผยบันทึกการตอบสนองวันที่ 26 ตุลาคม 2026 ส่วน rustup 1.29.2 ออกวันที่ 20 ตุลาคม เพื่ออัปเดต dependency ที่เกี่ยวกับการตรวจใบรับรอง
สำหรับทีมที่มีทั้ง Go และ Rust การเห็นเครื่องมือหนึ่งอัปเดตแล้วจึงยังไม่พอจะสรุปว่า binary หรือเครื่องมือทุกตัวในระบบได้รับการแก้ครบ
ลำดับเหตุการณ์ของ Go
Go Security Team อธิบายว่ากุญแจของ intermediate certificates ที่เกี่ยวข้องอ่อนแอจนเสี่ยงนำไปปลอมใบรับรอง TLS ได้ ทีมได้รับแจ้งวันที่ 19 ตุลาคม และเลือกใช้ URGENT track เพื่อออก Go 1.27.3 และ 1.26.10 ที่บล็อกความเชื่อถือใน intermediate ชุดนี้
เวลาที่ทีมรายงานเริ่มรับแจ้ง 11:45 PDT และประกาศ release 19:13 PDT รวม 7 ชั่วโมง 28 นาที เป็นเวลาวันที่ 19 ตุลาคมตามเขตเวลาต้นทาง ซึ่งตรงกับช่วงวันที่ 20 ตุลาคมในไทย กราฟปกใช้เวลาสะสมจากจุดรับแจ้งตามบันทึกของทีม ไม่ใช่ผลทดสอบ response time ของอุตสาหกรรมหรือของ Reefsight
บันทึกยังแยกพฤติกรรมการตรวจ certificate ของ Go: Windows/macOS อาศัย platform APIs ส่วน Linux มี verifier ของ Go เองและไม่มีระบบ revocation กลางแบบเดียวกันในขอบเขตที่อธิบาย ทีมจึงใช้ release เร่งด่วนเป็นวิธีส่งการป้องกันให้ผู้ใช้
rustup เป็นเครื่องมือจัดการ toolchain
ประกาศ rustup ระบุว่ารุ่น 1.29.2 เป็น release ขนาดเล็กที่อัปเดต rustls-webpki และ webpki-root-certs เพื่อแก้ intermediate certificates ที่มีปัญหา โดยอ้าง CVE-2026-111943 และ RUSTSEC-2026-0382
การอัปเดต rustup จึงเป็นงานของเครื่องมือดาวน์โหลด/จัดการ Rust toolchain ไม่ได้รับรองว่าแอป Rust ของทีมที่ใช้ TLS library อีกชุดหนึ่งเปลี่ยน dependency แล้ว และไม่ใช่การติดตั้ง rustc major version ใหม่แทนโดยอัตโนมัติ
| สิ่งที่ทีมตรวจ | ขอบเขตที่ต้องติดตามแยก |
|---|---|
| Go toolchain ที่ใช้ build | รุ่นแพตช์ที่มีการแก้และกระบวนการ rebuild/redeploy binary ที่เกี่ยวข้อง |
| แอป Go ที่รับมาจาก vendor | release ที่ vendor build และส่งให้จริง; อัปเดต compiler ในเครื่องไม่ได้เปลี่ยนไฟล์แอปเดิม |
| rustup | รุ่นของตัวจัดการ toolchain และช่องทางอัปเดตตามประกาศ |
| แอป Rust หรือเครื่องมืออื่น | dependency และ trust behavior ของโปรแกรมนั้นเอง |
การดำเนินการควรเริ่มจาก inventory ที่ระบุเจ้าของโปรแกรม รุ่นที่ build และสถานที่ใช้งาน แล้วติดตาม patch ของแต่ละโครงการ ไม่ปิดการตรวจ TLS เพื่อให้ผ่าน error และไม่ถือว่าเครื่องมือตัวหนึ่งอัปเดตแทนทุกชั้น
Reefsight ตรวจประกาศและบันทึกต้นฉบับ แต่ไม่ได้ตรวจ trust store สแกนช่องโหว่ อัปเดต rustup หรือ rebuild/deploy บริการของผู้อ่าน จึงไม่มีข้อยืนยันว่าระบบใดถูกโจมตีหรือได้รับการแก้ครบแล้ว