Plug.Crypto อาจเขียน secret key ลง error log เมื่อรับข้อมูลผิดชนิด แก้แล้วใน 2.2.1

โครงการ Plug เผยแพร่คำแนะนำความปลอดภัยสำหรับ CVE-2026-105963 วันที่ 23 ตุลาคม 2026 ช่องโหว่นี้ทำให้ค่า secret key base หรือค่าลับที่นำไปเปรียบเทียบกับ API key ปรากฏใน stack trace เมื่อฟังก์ชันของ Plug.Crypto ได้รับอาร์กิวเมนต์ผิดชนิด และข้อผิดพลาดถูกส่งต่อไปยัง log หรือระบบติดตาม error ประเด็นสำคัญคือการส่งคำขอผิดรูปแบบเพียงอย่างเดียวไม่ได้ส่งค่าลับกลับไปให้ผู้โจมตี ผู้ที่จะอ่านค่าที่หลุดได้ต้องเข้าถึง log หรือ error tracker อีกขั้นหนึ่ง

ทำไมค่าในอาร์กิวเมนต์จึงไปอยู่ใน log

คำแนะนำของผู้ดูแลโครงการอธิบายว่า public function ใน Plug.Crypto ตรวจชนิดอาร์กิวเมนต์ด้วย guard ที่ส่วนหัวของฟังก์ชัน หาก guard ไม่ผ่าน Erlang VM จะสร้าง FunctionClauseError พร้อมค่าของอาร์กิวเมนต์จริงใน stack frame ชั้นบนสุด กลไกที่ไลบรารีใช้ตัดอาร์กิวเมนต์ออกจาก stack trace ทำงานกับข้อผิดพลาดซึ่งเกิดภายในตัวฟังก์ชัน แต่ไม่ทันจับข้อผิดพลาดที่เกิดก่อนเข้าตัวฟังก์ชันจาก guard ดังกล่าว

เมื่อแอปใช้ Plug.Cowboy หรือ Bandit ข้อมูลใน frame อาจถูกเขียนลง error log และแนบใน crash_reason ของ Logger หากองค์กรส่ง log ไปยังระบบรวบรวมภายนอกหรือ error tracker ขอบเขตผู้ที่อาจเห็นค่าลับจะขึ้นกับสิทธิ์ของระบบเหล่านั้นด้วย จึงต้องประเมินทั้งเส้นทางรับคำขอและเส้นทางจัดเก็บ log ไม่ใช่ตรวจเฉพาะ response ที่แอปส่งกลับผู้ใช้

จุดที่คำขอจากภายนอกอาจกระตุ้นปัญหา

ผู้ดูแลระบุกรณี Plug.Crypto.verify/4 ซึ่งรับ token ที่ไม่ใช่ binary และไม่ใช่ nil แล้วทำให้ secret key base ปรากฏใน stack trace แอป Phoenix ที่ส่งค่าพารามิเตอร์ของผู้ใช้ไปยัง Phoenix.Token.verify/4 โดยตรงอาจเข้าถึงเส้นทางนี้ได้ เพราะข้อมูลที่ parse จาก query string หรือ JSON อาจกลายเป็น list, integer หรือ map แทนข้อความธรรมดา การมี Phoenix หรือ Plug ใน dependency เพียงอย่างเดียวจึงยังไม่พอจะสรุปว่าแอปถูกใช้ประโยชน์ได้ ต้องตรวจว่ามี endpoint ใดส่งค่าที่ผู้ใช้ควบคุมได้ไปยังฟังก์ชันเหล่านี้โดยไม่ตรวจชนิดก่อนหรือไม่

อีกกรณีคือ Plug.Crypto.secure_compare/2 ถ้าฝั่งหนึ่งไม่ใช่ binary เช่น แอปอ่าน header ที่ไม่มีอยู่แล้วได้ nil แต่ส่งไปเทียบกับค่าลับที่ตั้งไว้ อาร์กิวเมนต์อีกฝั่งอาจถูกบันทึกใน stack trace คำแนะนำยังกล่าวถึง Plug.Crypto.decrypt/4 ที่อาจทำให้ derived key ปรากฏเมื่อ token ผิดชนิด ผลกระทบของแต่ละเส้นทางต่างกันตามโค้ดเรียกใช้จริงและสิทธิ์เข้าถึง log

เวอร์ชันที่ได้รับผลกระทบและรุ่นแก้

สำหรับแพ็กเกจ plug_crypto คำแนะนำระบุเวอร์ชันตั้งแต่ 1.0.0 ถึงก่อน 2.2.1 ได้รับผลกระทบ และ 2.2.1 เป็นเวอร์ชันแก้ แพ็กเกจรุ่นนี้ขึ้นทะเบียนใน Hex เมื่อ 23 ตุลาคม 2026 เวลา 09:48 UTC ส่วนประกาศความปลอดภัยบน GitHub เผยแพร่เวลา 09:48:19 UTC วันเดียวกัน

คำแนะนำยังแสดงช่วงของแพ็กเกจ plug ตั้งแต่ 1.6.3 ถึงก่อน 1.7.0 โดยระบุ 1.7.0 เป็นรุ่นแก้สำหรับช่วงนั้น เนื่องจากช่วงเวอร์ชันดังกล่าวเป็นสายเก่า ผู้ดูแลควรตรวจ dependency lockfile ที่ใช้งานจริง แยก plug ออกจาก plug_crypto และพิจารณาสายเวอร์ชันปัจจุบันตามคำแนะนำของโครงการ แทนการมองเลข 1.7.0 ว่าเป็นรุ่นล่าสุดของ Plug

แนวทางตรวจและรับมือ

ให้ตรวจ mix.lock หรือรายการแพ็กเกจที่ deploy ว่ามี plug_crypto ต่ำกว่า 2.2.1 หรือไม่ จากนั้นทบทวน endpoint ที่รับ token, API key หรือ header จากคำขอ ตรวจชนิดข้อมูลก่อนส่งเข้าฟังก์ชันด้านการเข้ารหัสและการเปรียบเทียบค่า โดยเฉพาะกรณีที่ parser อาจสร้างโครงสร้างข้อมูลแทน string อัปเดต dependency ไปยังรุ่นแก้แล้วทดสอบทั้งคำขอที่ถูกต้องและคำขอที่ส่งชนิดข้อมูลผิด เพื่อยืนยันว่าแอปไม่บันทึกค่าลับใน stack trace

หากเคยมีข้อผิดพลาดลักษณะนี้ในระบบที่เปิดใช้งาน ให้ตรวจ log และ error tracker อย่างจำกัดสิทธิ์เพื่อประเมินว่ามี secret key base, derived key หรือ API key ปรากฏจริงหรือไม่ และใครบ้างที่เข้าถึงข้อมูลดังกล่าวได้ หากพบการรั่วไหล ให้ดำเนินการตามแผนจัดการความลับขององค์กร เช่น หมุนเวียนค่าที่ได้รับผลกระทบ ประเมินเซสชันหรือ token ที่อาจถูกสร้างด้วยค่าลับเดิม และกำหนดอายุเก็บ log ให้เหมาะสม การลบข้อความใน log อย่างเดียวไม่แก้ไลบรารีที่ยังมีช่องโหว่

วันที่และแหล่งต้นทาง

คำแนะนำของโครงการ Plug เป็นหลักฐานการเปิดเผยต่อสาธารณะครั้งแรกที่ตรวจได้เมื่อ 23 ตุลาคม 2026 เวลา 09:48:19 UTC ระเบียน CVE-2026-105963 เผยแพร่ครั้งแรกในวันเดียวกันเวลา 09:56:58 UTC ส่วนแพตช์ plug_crypto 2.2.1 เผยแพร่บน Hex เวลา 09:48:03 UTC ก่อนประกาศประมาณ 15 วินาที

อ่าน คำแนะนำความปลอดภัยของโครงการ Plug, ระเบียน CVE และ ข้อมูลรุ่น 2.2.1 จาก Hex