"league/commonmark เสี่ยง DoS จาก Markdown: CVE-2026-71488"

พอดีไล่ฟีดความปลอดภัยเจอ CVE-2026-71488 ใน league/commonmark ไลบรารีแปลง Markdown ของ PHP ข้อความบางรูปแบบทำให้ตัวแปลงทำงานช้าจนบริการหยุดตอบสนองได้ ผู้พัฒนาเผยแพร่ advisory วันที่ 3 สิงหาคม 2026 ส่วน GitHub Advisory Database เผยแพร่รายการวันที่ 6 สิงหาคม 2026 ให้ระดับ High และ CVSS 3.1 เท่ากับ 7.5/10

ใครต้องทำอะไร

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

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

ตัวแปลงนับตำแหน่งเป็นตัวอักษร แต่ regular expression บอกตำแหน่งเป็นไบต์ เมื่อเจอ UTF-8 แบบหลายไบต์ บางขั้นตอนต้องอ่านบรรทัดเดิมซ้ำเพื่อเทียบตำแหน่ง บรรทัดยาวขึ้นสองเท่าเลยอาจทำงานเพิ่มราวสี่เท่า ส่วน Autolink ก็มีปัญหาคัดลอกและตรวจข้อความที่เหลือซ้ำ

ผู้โจมตีที่ส่ง Markdown เข้าแอปได้อาจใช้คำขอขนาดไม่มากกิน CPU และหน่วยความจำเกินสัดส่วน ถ้ามีหลายคำขอพร้อมกัน PHP workers อาจถูกใช้งานจนหมดและคำขอปกติรอไม่ไหว ผลกระทบของช่องโหว่นี้อยู่ที่ความพร้อมใช้งาน ประกาศระบุว่าไม่ได้ทำให้ข้อมูลรั่วหรือเปลี่ยนผลลัพธ์ที่แสดง และแอปที่แปลงเฉพาะข้อความจากแหล่งที่เชื่อถือได้ไม่เปิดช่องโจมตีจากระยะไกลตามกรณีนี้

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

ตารางยึดช่วง >=0.6.0,<2.9.0 ของ GitHub Advisory Database แต่หน้า advisory ผู้พัฒนา ระบุขอบบนเป็น <2.8.4 ข้อมูลสองหน้าต่างกัน ทั้งคู่ระบุรุ่นแก้เป็น 2.9.0 เลยไม่ควรถือว่า 2.8.4 เป็นรุ่นแก้

ปัญหาหลักกระทบทั้ง CommonMarkConverter, GithubFlavoredMarkdownConverter และ environment ที่ประกอบเอง การปิด Autolink อย่างเดียวแก้ไม่ครบ

ต้องทำอะไร

ตรวจรุ่นที่ติดตั้งและข้อกำหนดใน composer.json ก่อน สำหรับโปรเจกต์ที่ประกาศ dependency นี้โดยตรง สามารถกำหนดขั้นต่ำเป็นสาย 2.9 แล้วอัปเดตด้วย Composer จากโฟลเดอร์โปรเจกต์:

composer show league/commonmark
composer require "league/commonmark:^2.9" --with-all-dependencies
composer show league/commonmark
composer audit

หากเป็น dependency ทางอ้อม ให้ตรวจแพ็กเกจต้นทางและอัปเดตให้ยอมรับรุ่นที่แก้ อย่าฝืนข้อจำกัดโดยไม่ทดสอบ ตรวจผลลัพธ์ Markdown ของแอปและนำ composer.lock ที่ผ่านการทดสอบไปใช้ตอน deploy พร้อมยืนยันรุ่นที่ติดตั้งจริงอีกครั้ง

ถ้ายังอัปเดตไม่ได้ ผู้พัฒนาแนะนำให้ปฏิเสธหรือตัดบรรทัดที่ยาวเกินขอบเขตของแอป ก่อนส่งเข้าตัวแปลง การจำกัดขนาดคำขอรวมอย่างเดียวไม่พอ เสริมด้วยการจำกัดอัตราคำขอ เวลาประมวลผล และจำนวนงานแปลงพร้อมกันได้ แต่ใช้แทนแพตช์ไม่ได้

ส่วนตัวผมให้แอปที่รับ Markdown จากบุคคลภายนอกเร่งแพตช์ ส่วนแอปที่รับเฉพาะเนื้อหาที่เชื่อถือได้ให้จัดอัปเดตในรอบบำรุงรักษา ที่มา: GitHub Advisory Database: GHSA-2q4p-g7hv-5rgv และ บันทึกการออกรุ่น 2.9.0 หากมีรายละเอียดเพิ่มเติม เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ