Guzzle ทำ fragment รั่วผ่าน Referer: CVE-2026-67354

พอดีไล่ฟีด Packagist เจอประกาศของ Guzzle ไลบรารี HTTP สำหรับ PHP ข้อมูลหลัง # ใน URI อาจหลุดไปกับเฮดเดอร์ Referer ระหว่างตาม redirect ปัญหานี้คือ CVE-2026-67354 ต้องเช็กว่าแอปเปิดสร้าง Referer อัตโนมัติไว้หรือเปล่า เพราะค่าเริ่มต้นปิดอยู่ ประกาศผู้พัฒนาเผยแพร่ 18 กรกฎาคม 2026 และให้คะแนน CVSS 3.1 ที่ 5.9/10 ระดับปานกลาง ส่วนระเบียน CVE เผยแพร่ 1 สิงหาคม 2026

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

• ผู้ดูแลระบบ: ถ้าดูแลแอป PHP ที่ใช้ Guzzle และเปิดส่ง Referer พร้อม URI ที่มีข้อมูลลับ ให้ประสานทีมพัฒนาเพื่อปิดตัวเลือกนี้และนำรุ่นที่แก้แล้วขึ้นใช้งานโดยเร็ว
• นักพัฒนา: ตรวจรุ่น Guzzle และการตั้งค่า redirect ถ้าเปิด referer และส่งข้อมูลลับใน fragment ให้ปิดทันทีระหว่างอัปเดตเป็น 7.15.1 หรือใหม่กว่า

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

Fragment คือส่วนของ URI หลังเครื่องหมาย # ปกติไคลเอนต์เก็บส่วนนี้ไว้เอง ไม่ส่งไปในคำขอ HTTP เซิร์ฟเวอร์แรกเลยไม่เห็นข้อมูลนี้ แต่เมื่อเปิด allow_redirects.referer ตัว RedirectMiddleware จะใช้ URI ต้นทางสร้าง Referer โดยตัดข้อมูลผู้ใช้ออก แต่ยังเก็บ fragment ไว้

ถ้าคำขอถูกเปลี่ยนเส้นทางโดยยังใช้ scheme เดิม เช่น HTTPS ไป HTTPS ปลายทาง redirect อาจได้รับข้อมูลหลัง # ผ่านเฮดเดอร์ ผู้โจมตีที่ควบคุมปลายทางนั้นสามารถอ่านผ่านโค้ดแอปหรือบันทึกคำขอได้ ถ้า fragment มีโทเคนเข้าถึงระบบ ความลับสำหรับล็อกอินครั้งเดียว หรือค่า state ข้อมูลเหล่านั้นก็อาจหลุดออกนอกขอบเขตที่ตั้งใจไว้ ปัญหานี้เกิดได้ทั้ง cURL handler และ stream handler

ข้อมูลจะรั่วเมื่อแอปเปิด referer ใส่ความลับใน fragment และตาม redirect ด้วย scheme เดิมไปยังปลายทางที่เชื่อถือน้อยกว่า ถ้าปิดตัวเลือกนี้ ไม่ใส่ความลับ ไม่ตาม redirect หรือตามเฉพาะปลายทางที่เชื่อถือเท่ากัน ก็ไม่เข้าเงื่อนไขนี้ ส่วน redirect ที่เปลี่ยน scheme จะไม่มีเฮดเดอร์นี้อยู่แล้ว ดูรายละเอียดใน ประกาศผู้พัฒนา Guzzle

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

รุ่นที่แก้แล้วจะตัดทั้งข้อมูลผู้ใช้และ fragment ก่อนสร้าง Referer แต่ยังส่ง path และ query ไปกับเฮดเดอร์ รายการแก้ไขยืนยันไว้ใน บันทึกรุ่น 7.15.1

ต้องทำอะไร

เริ่มจากตรวจ dependency ของโปรเจกต์และจุดที่ตั้งค่า redirect ตัวอย่างคำสั่งต่อไปนี้ใช้ในไดเรกทอรีโปรเจกต์เพื่อดูรุ่น อัปเดตแพ็กเกจพร้อม dependency ที่เกี่ยวข้อง แล้วตรวจรุ่นอีกครั้ง ตัวเลือก --with-all-dependencies อาจอัปเดต dependency อื่นที่โปรเจกต์ใช้อยู่ด้วย ตาม คู่มือ Composer

composer show guzzlehttp/guzzle
composer update guzzlehttp/guzzle --with-all-dependencies
composer show guzzlehttp/guzzle

ตรวจให้แน่ใจว่าผลลัพธ์เป็น 7.15.1 หรือใหม่กว่า ถ้าข้อกำหนดใน composer.json หรือแพ็กเกจอื่นยังล็อกรุ่นเก่า ต้องแก้ข้อจำกัดให้เข้ากันก่อน ทดสอบการตาม redirect ของแอป และนำ composer.lock ที่อัปเดตแล้วไปใช้ในขั้นตอนนำขึ้นระบบด้วย

หากยังอัปเดตไม่ได้ ผู้พัฒนาแนะนำให้ตั้ง referer ภายใน allow_redirects เป็น false หรือปิดการตาม redirect อัตโนมัติแล้วเลือกตามเฉพาะปลายทางที่เชื่อถือเอง อีกทางคือตัด fragment ออกจาก URI ก่อนส่งคำขอที่อาจเปลี่ยนเส้นทาง อย่าอาศัยแค่ว่าคำขอแรกไม่ส่ง fragment เพราะ middleware สามารถนำกลับมาใส่ใน Referer ได้

ส่วนตัวผมให้รีบปิด referer และอัปเดตถ้าแอปส่งข้อมูลลับใน fragment พร้อมตาม redirect ออกไปภายนอก ส่วนแอปที่ปิดตัวเลือกนี้อยู่แล้วให้นำแพตช์เข้ารอบบำรุงรักษา ที่มา: Guzzle: URI fragments disclosed in redirect Referer headers เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ