Guzzle ทำ fragment รั่วผ่าน Referer: CVE-2026-67354
นักพัฒนาและผู้ดูแลระบบที่ใช้ Guzzle พร้อมเปิด referer และส่ง URI ที่มีข้อมูลลับใน fragment ควรปิดตัวเลือกนี้ทันทีระหว่างเตรียมอัปเดต
สรุปใน 1 นาที
- อาการ/ปัญหา
- ข้อมูลลับใน fragment ของ URI อาจรั่วไปยังปลายทาง redirect ผ่านเฮดเดอร์ Referer
- ใครควรอ่าน
- นักพัฒนาและผู้ดูแลระบบของแอป PHP ที่ใช้ Guzzle ก่อน 7.15.1 พร้อมเปิด referer และตาม redirect ที่เข้าเงื่อนไข
- ทางแก้แบบสั้น
- อัปเดต guzzlehttp/guzzle เป็น 7.15.1 หรือใหม่กว่า หรือปิด allow_redirects.referer ระหว่างรออัปเดต
พอดีไล่ฟีด 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
ใครโดนและรุ่นที่แก้
| แพ็กเกจ | รุ่นที่ได้รับผลกระทบ | รุ่นที่แก้แล้ว |
|---|---|---|
guzzlehttp/guzzle บน Composer |
ก่อน 7.15.1 เมื่อเปิด referer และเข้าเงื่อนไขข้างต้น |
7.15.1 และใหม่กว่า |
รุ่นที่แก้แล้วจะตัดทั้งข้อมูลผู้ใช้และ 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 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย