league/commonmark เสี่ยง DoS ผ่าน Attributes — GHSA-8rr7-cvq3-gmfh

พอดีไล่ฟีด Packagist เจอประกาศช่องโหว่ของ league/commonmark ไลบรารีแปลง Markdown สำหรับ PHP รหัส GHSA-8rr7-cvq3-gmfh จุดที่ต้องตรวจคือการเปิดส่วนเสริม AttributesExtension เพราะข้อมูลที่ดูเป็นข้อความธรรมดาอาจทำให้ตัวแปลงใช้ CPU มากผิดสัดส่วน และกระทบการให้บริการของแอปได้

เกิดอะไรขึ้น

ประกาศผู้พัฒนาเผยแพร่วันที่ 11 สิงหาคม 2026 ส่วนรายการใน GitHub Advisory Database เข้าฐานวันที่ 1 กันยายน 2026 เวลา UTC ซึ่งตรงกับ 2 กันยายน 2026 ตามเวลาไทย

ปัญหาเกิดเมื่อ Markdown มีแอตทริบิวต์ชื่อไม่ซ้ำกันจำนวนมาก ทุกครั้งที่เพิ่มแอตทริบิวต์ ตัวแปลงจะย้อนอ่านข้อมูลเดิมทั้งชุด ข้อมูลยิ่งมาก งานยิ่งเพิ่มแบบกำลังสอง หรือ O(n²)

มีปัญหาสองจุด จุดแรกคือ AttributesListener::processDocument() ที่รวม attribute nodes ไปยังเป้าหมายเดียวกัน แต่กลับรวมและกรองข้อมูลเดิมทั้งชุดซ้ำ จุดที่สองคือ AttributesBlockContinueParser::tryContinue() ที่อ่าน attribute blocks หลายบรรทัดต่อกัน แล้วสร้างชุดข้อมูลสะสมใหม่ทุกบรรทัด ทั้งสองแบบทำให้ข้อความขนาดไม่มากใช้เวลาแปลงนานได้

ผู้โจมตีที่ส่ง Markdown เข้าแอปที่เข้าเงื่อนไขได้โดยไม่ต้องยืนยันตัวตน สามารถยึดเวลาทำงานของ PHP workers จนคำขอปกติทำงานไม่เสร็จ ผลกระทบตามประกาศจำกัดอยู่ที่ความพร้อมใช้งาน ไม่ใช่ข้อมูลรั่ว การเปลี่ยนผลลัพธ์ที่แสดง หรือการข้ามข้อจำกัดการเรนเดอร์ GitHub จัดระดับ High คะแนน CVSS 3.1: 7.5 และยังไม่ระบุ CVE ช่องโหว่นี้ยังไม่อยู่ใน KEV ฉบับ 4 พฤศจิกายน 2026

ใครโดนและรุ่นที่แก้

ช่วงรุ่นที่ได้รับผลรวมคือ ตั้งแต่ 1.5.0 แต่ต่ำกว่า 2.10.0 โดยต้องลงทะเบียน AttributesExtension บน Environment เอง ส่วนเสริมนี้ไม่ได้เปิดมาพร้อม CommonMarkConverter, GithubFlavoredMarkdownConverter หรือ GithubFlavoredMarkdownExtension แอปที่ไม่ได้ลงทะเบียนส่วนเสริมนี้ไม่อยู่ในขอบเขตประกาศ

รุ่น 2.9.1 และ 2.9.2 ยังมีปัญหานี้ แพตช์ก่อนหน้าแก้เฉพาะการสะสม class แต่ชื่อแอตทริบิวต์อื่นยังทำให้เกิดปัญหาได้ ส่วนสาย 1.x เลิกสนับสนุนแล้ว ต้องย้ายไป 2.10.0 หรือใหม่กว่า แพตช์ใหม่ทำงานเฉพาะข้อมูลที่เพิ่มเข้ามา โดยไม่เปลี่ยนผล HTML หรือลำดับแอตทริบิวต์

ต้องทำอะไร

ตรวจรุ่นที่ติดตั้งและค้นหาจุดลงทะเบียน AttributesExtension ในโค้ด โดยเฉพาะส่วนที่รับข้อความจากผู้ใช้ ทดสอบอัปเดต dependency และตรวจว่า composer.json ยอมรับ 2.10.0 แล้ว หากแพ็กเกจอื่นยังบังคับให้ใช้รุ่นเก่า ต้องแก้ข้อจำกัดนั้นก่อน ตัวอย่างคำสั่งสำหรับโครงการที่รองรับรุ่นแก้แล้วคือ

composer show league/commonmark
composer update league/commonmark --with-all-dependencies
composer show league/commonmark

ตรวจผลครั้งสุดท้ายว่ารุ่นที่ติดตั้งเป็น 2.10.0 หรือใหม่กว่า และทบทวนการเปลี่ยนแปลงใน composer.lock ก่อนนำไปใช้งานจริง ควรทดสอบข้อความ Markdown ปกติและส่วนที่พึ่งพาแอตทริบิวต์ด้วย โดยเฉพาะโครงการที่ย้ายข้ามจากสาย 1.x ขั้นตอนนี้เป็นคำแนะนำในการนำแพตช์ไปใช้ ไม่ใช่ workaround เพิ่มเติมจากผู้พัฒนา

ถ้ายังอัปเดตไม่ได้ ผู้พัฒนาแนะนำให้หยุดลงทะเบียนส่วนเสริมนี้เมื่อแปลง Markdown ที่ไม่น่าเชื่อถือ ซึ่งตัดเส้นทางปัญหาทั้งสองแบบ หากจำเป็นต้องใช้ ให้จำกัดความยาวข้อมูลก่อนแปลงอย่างเข้มงวด โดยเพดานต้องเล็กพอจะจำกัดงานที่โตแบบกำลังสองได้ ประกาศไม่ได้กำหนดขนาดที่ปลอดภัยตายตัว ส่วนการจำกัดเวลา การจำกัดอัตราคำขอ และการให้เฉพาะผู้ใช้ที่เชื่อถือได้ส่งข้อมูล ช่วยลดโอกาสเกิดผลกระทบแต่ใช้แทนการอัปเดตไม่ได้

ส่วนตัวผมให้เร่งแพตช์เมื่อเปิดส่วนเสริมนี้รับ Markdown จากภายนอก เพราะกระทบ PHP workers และคำขอปกติได้โดยตรง ที่มา: GitHub Security Advisory GHSA-8rr7-cvq3-gmfh และ เอกสารคำสั่ง Composer หากมีรายละเอียดเพิ่มเติมจากผู้พัฒนา เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ