Symfony CVE-2026-118514 ข้ามกฎด้วย HEAD เช็กเงื่อนไขและอัปเดต

พอดีเห็น Symfony ออกประกาศชุดใหญ่เมื่อ 4 พ.ย. 2026 ตัวหลักคือ CVE-2026-118514 ซึ่งเป็นการแก้ที่ยังไม่ครบของ CVE-2026-45075 รอบก่อน ประกาศชุดเดียวกันมีปัญหาเรื่อง path กับ trusted proxy อีกสี่ตัว ผมเลยรวมไว้ในบันทึกเดียว ประเด็นของตัวหลักคือ request แบบ HEAD ไม่มี body ส่งกลับก็จริง แต่ controller ยังทำงานเต็มๆ ใครจำกัดสิทธิ์ตาม HTTP method ไว้ต้องเช็กทั้งรุ่นแพ็กเกจและ configuration ครับ

เกิดอะไรขึ้นกับ HEAD และกฎสิทธิ์

RequestMatcher และ MethodRequestMatcher ตรวจ method แบบตรงตัว แต่ router รับ HEAD ผ่าน handler ของ GET ได้ กฎ access_control ที่เขียน methods: [GET] เลยอาจไม่ครอบคลุม HEAD บน URL เดียวกัน หากไม่มีด่านสิทธิ์อื่นมารับต่อ controller ก็ทำงานได้ พร้อมผลข้างเคียงของมันและข้อมูลใน response headers แม้ไม่มีเนื้อหาหน้าส่งกลับ

firewall ที่จำกัด GET มีช่องว่างแบบเดียวกัน โดย HEAD อาจตกไปเข้า firewall ถัดไปหรือไม่มีตัวไหนรับ ส่วน custom matcher ต้องตรวจการใช้จริงด้วย แพตช์ CVE-2026-45075 แก้เฉพาะ attributes ด้านสิทธิ์ ลายเซ็น และ CSRF เลยยังเหลือส่วนนี้อยู่ แพตช์ใหม่เพิ่ม HEAD ให้ matcher เมื่อรายการมี GET ถ้าต้องการกฎ HEAD ต่างหาก ต้องวางก่อนกฎ GET ของ path เดียวกัน รายละเอียดจาก Symfony

ระดับความรุนแรงต้องดูพร้อมเงื่อนไข

Symfony ประเมิน HEAD bypass เป็น Moderate, CVSS v4.0 6.3 พร้อม vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N คือเข้าถึงผ่านเครือข่าย ไม่ต้องมีสิทธิ์หรือให้ผู้ใช้กดอะไร แต่ต้องเข้าเงื่อนไขของแอป หน้าจัดการที่เข้าเงื่อนไขเลยยังต้องเร่งแก้ advisory ของ CVE หลัก

อีกสี่ตัวเป็น GHSA ที่ยังไม่มีเลข CVE และไม่ได้ให้คะแนน CVSS ส่วนรายการ CISA KEV ฉบับ 4 พ.ย. 2026 ยังไม่มี CVE-2026-118514 และ Symfony เองก็ไม่ได้พูดถึงการโจมตีจริง ตอนนี้เลยนับเป็นช่องโหว่ที่ต้องแก้ตามเงื่อนไข ยังไม่ใช่เหตุฉุกเฉินแบบที่มีคนยิงอยู่ คะแนนและช่วงรุ่นในบันทึกนี้ยึดตาม advisory ของ Symfony เพราะ NVD ยังไม่ได้วิเคราะห์

ปัญหา path และ proxy อีกสี่ตัว

GHSA-3h27-hjv7-fqjx: ตัดชื่อ script ออกจาก path แม้เป็นแค่ต้นของ segment ที่ยาวกว่า ชั้นหน้า PHP กับ router เลยเห็นปลายทางต่างกัน กฎ path บน nginx, Apache, CDN หรือ WAF อาจถูกเลี่ยง ส่วน access_control และ firewall ของ Symfony อ่าน path เดียวกับ router เลยไม่กระทบจากตัวนี้ ประกาศเรื่อง path

GHSA-xg2q-4rrq-657q: private_ranges นำรายการปฏิเสธปลายทางของ HTTP client มาอนุญาต proxy รวม IPv4-mapped, 6to4, Teredo และ NAT64 โดย dual-stack listener ที่รายงาน IPv4 เป็น IPv4-mapped หรือ client จาก 6to4/Teredo ที่เข้าถึงได้ อาจถูกเชื่อเป็น proxy แล้วปลอม IP, host หรือ scheme ผ่าน forwarded headers กระทบ allowlist, rate limit, log และ URL รีเซ็ตรหัสผ่าน แพตช์แยกเป็น IpUtils::PRIVATE_RANGES ซึ่งมีใน 6.4.50 ด้วย สาย 6.4 ไม่กระทบโดยค่าเริ่มต้น แต่โค้ดที่ส่ง IpUtils::PRIVATE_SUBNETS เองต้องตรวจ ประกาศเรื่อง trusted proxies

GHSA-5mx8-mwrp-5693: base URL อาจเริ่มด้วยส่วน host ที่ client เลือก ส่งผลต่อลิงก์ form action, redirect และ asset เงื่อนไขอยู่ที่ front controller ใน subdirectory กับการ rewrite หรือการตั้ง SCRIPT_NAME บางแบบ ต้องมีผู้ใช้ตามลิงก์ที่จัดทำไว้ การตั้ง trusted_hosts ไม่ปิดกรณีนี้เพราะ request ยังเข้า host จริง ส่วน configuration ที่เอกสาร Symfony แนะนำไม่กระทบ ประกาศเรื่อง generated URLs

GHSA-wg5q-m2ww-f3c9: การ render inline fragment ทำให้ช่วงหนึ่งเชื่อถือที่อยู่ loopback IPv4 ที่ advisory ระบุ แล้ว router สร้าง context จาก main request ใหม่ในช่วงนั้น หาก request เข้ามาจาก local proxy ที่ไม่ได้ประกาศให้เชื่อถือ header ปลอมอาจติดไปใน absolute URL หลัง render ได้ กรณี php-fpm, mod_php หรือ proxy คนละเครื่องไม่กระทบตามเงื่อนไขที่ผู้พัฒนาอธิบาย ส่วน trusted_hosts ช่วยปฏิเสธ host นอกบัญชี แต่ไม่ปิดการเปลี่ยน scheme กับ port ทั้งหมด ประกาศเรื่อง inline fragments

เทียบแพ็กเกจและรุ่นที่แก้

ตารางนี้ยึดช่วงรุ่นในแต่ละ advisory ชื่อย่อ HF คือ symfony/http-foundation, HK คือ symfony/http-kernel และ FB คือ symfony/framework-bundle ถ้าติดตั้งแบบรวม symfony/symfony ให้เทียบรายการของแพ็กเกจรวมนั้นด้วย

Laravel HTTP Requests ยืนยันการสืบทอด Request และ composer.json ระบุ dependency แต่การมีแพ็กเกจอย่างเดียวไม่ยืนยันว่าแอปเรียกส่วนที่มีปัญหา

วิธีแก้และตรวจหลังเปลี่ยน

1. ตรวจเงื่อนไข เทียบแพ็กเกจใน lock file กับ configuration ที่ใช้งานจริง
2. สำรองและทดสอบ สำรองโค้ดกับ lock file แล้วจำลองการอัปเดตในชุดทดสอบ
3. อัปเดตแพ็กเกจ ตรวจรายการเปลี่ยนและเทียบรุ่นที่ได้กับตาราง
4. ยืนยันผล ทดสอบสิทธิ์ GET กับ HEAD และ URL ผ่านเส้นทางรับ request จริงก่อน deploy

ในโฟลเดอร์โปรเจกต์ ตรวจ lock file เทียบของที่ติดตั้งจริง แพ็กเกจที่ไม่มีจะรายงานว่าไม่พบ

composer show --locked symfony/http-foundation
composer show --locked symfony/http-kernel
composer show --locked symfony/framework-bundle
composer show 'symfony/*'

ตรวจ advisory ของ dependency ตาม lock file เพิ่มด้วย

composer audit --locked

สำรองโค้ดกับ lock file แล้วทำในชุดทดสอบก่อน คำสั่งนี้อัปเดตตาม constraint เดิมพร้อม dependency ที่เกี่ยวข้อง ตรวจรายการเปลี่ยนและเทียบรุ่นกับตารางอีกครั้ง อย่าดูแค่คำสั่งสำเร็จ

composer update 'symfony/*' --with-all-dependencies --dry-run
# ตรวจผลจำลองก่อนรันบรรทัดถัดไป
composer update 'symfony/*' --with-all-dependencies
composer audit --locked
composer show 'symfony/*'

ถ้ารุ่นถูกตรึง ให้แก้ constraint และทดสอบการย้ายสาขา แล้ว deploy lock file กับ dependency ชุดที่ทดสอบ พร้อมโหลด process ที่ค้างโค้ดเดิมใหม่ อ้างอิงคำสั่ง Composer

มาตรการชั่วคราวสำหรับ HEAD ผมแนะนำเพิ่ม HEAD ในกฎ GET ที่เกี่ยวข้องพร้อมตรวจลำดับกฎ ส่วน proxy บน loopback ผู้พัฒนาแนะนำให้ proxy ตั้ง forwarded headers เองและกำหนด trusted_hosts ยังต้องลงแพตช์ด้วย

ใน staging ใช้ route อ่านอย่างเดียวกับบัญชีไม่มีสิทธิ์ เทียบ GET และ HEAD ว่าถูกปฏิเสธตามกฎ สำหรับ proxy และ fragment ตรวจ URL ก่อนและหลัง render ผ่านทางเข้าแบบ production ว่า client เปลี่ยน host หรือ scheme ไม่ได้ ส่วนชั้น PHP อ่าน บันทึกแพตช์ php2shell แยกได้

เช็กว่าโดนหรือยัง และควรเร่งแค่ไหน

ประกาศไม่ได้ให้ชุด IOC ผมแนะนำเทียบ HEAD บน endpoint ที่มีสิทธิ์กำกับกับ application audit log ตรวจ URL นอกโดเมนในอีเมลหรือ cache และ IP หรือ scheme ผิดจากทางเข้าเว็บ อาการเหล่านี้เป็นเพียงจุดสืบต่อ HEAD จากระบบตรวจสุขภาพก็มีได้ และ log ปกติไม่ได้รับรองว่าไม่เคยโดน

ส่วนตัวผม ถ้าเข้าเงื่อนไขกฎ GET บนหน้าจัดการ หรือ client ควบคุมข้อมูล proxy ที่ใช้ตัดสินสิทธิ์ได้ จะเร่งแพตช์ในรอบฉุกเฉิน เว็บที่ไม่เข้าเงื่อนไขให้ลงรอบบำรุงรักษาใกล้ที่สุดพร้อมเก็บผลทดสอบ

ที่มา: Symfony CVE-2026-118514 (https://symfony.com/blog/cve-2026-118514-head-requests-bypass-the-methods-option-of-access-control-and-firewalls-incomplete-fix-for-cve-2026-45075), Symfony HEAD advisory (https://github.com/symfony/symfony/security/advisories/GHSA-jrf8-gvm4-7cgh), Symfony path advisory (https://github.com/symfony/symfony/security/advisories/GHSA-3h27-hjv7-fqjx), Symfony proxy advisory (https://github.com/symfony/symfony/security/advisories/GHSA-xg2q-4rrq-657q), Symfony base URL advisory (https://github.com/symfony/symfony/security/advisories/GHSA-5mx8-mwrp-5693), Symfony fragment advisory (https://github.com/symfony/symfony/security/advisories/GHSA-wg5q-m2ww-f3c9), Laravel (https://laravel.com/framework/docs/requests), Laravel dependency manifest (https://github.com/laravel/framework/blob/13.x/composer.json), Composer (https://getcomposer.org/doc/03-cli.md), CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) ข้อมูลถึง 5 พ.ย. 2026 ถ้ามีรายงานการโจมตีจริงหรือ NVD ให้คะแนนออกมา เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ