Guzzle ข้ามการตรวจโฮสต์ได้ CVE-2026-69246
นักพัฒนาและผู้ดูแลระบบที่ใช้ Guzzle ดึง URL จากภายนอกพร้อมตรวจโฮสต์ควรเร่งอัปเดตและทบทวนการตรวจปลายทาง
สรุปใน 1 นาที
- อาการ/ปัญหา
- ชื่อโฮสต์ที่แอปตรวจอาจต่างจากปลายทางที่ตัวส่งคำขอเชื่อมต่อจริง ทำให้ข้ามข้อจำกัดตามโฮสต์ได้
- ใครควรอ่าน
- นักพัฒนาและผู้ดูแลระบบของแอป PHP ที่ใช้ Guzzle รับ URL ที่ผู้ใช้ควบคุมได้และตรวจโฮสต์ก่อนส่งคำขอ
- ทางแก้แบบสั้น
- อัปเดต guzzlehttp/guzzle เป็นรุ่นแก้ 7.15.2 หรือ 8.0.1 ตามสายรุ่น และตรวจที่อยู่ปลายทางหลัง resolve ชื่อโฮสต์
พอดีไล่ฟีด Packagist เจอประกาศของ Guzzle ไลบรารีส่ง HTTP request สำหรับ PHP เรื่อง CVE-2026-69246 ชื่อโฮสต์ที่เขียนในรูปแบบไม่มาตรฐานอาจผ่านการตรวจของแอป แล้วพาไปยังปลายทางที่แอปห้ามไว้ได้ ผู้พัฒนาเผยแพร่ประกาศวันที่ 26 กรกฎาคม 2026 และให้คะแนน CVSS 3.1 ที่ 7.2 ระดับ High
ใครต้องทำอะไร
- นักพัฒนา: ถ้าแอปรับ URL จากผู้ใช้แล้วตรวจโฮสต์ก่อนส่งให้ Guzzle ให้เร่งอัปเดตไลบรารีและตรวจว่าบล็อกปลายทางต้องห้ามได้จริง
- ผู้ดูแลระบบ: ถ้าดูแลแอปที่มีเงื่อนไขนี้ ให้ประสานทีมพัฒนานำรุ่นแก้ขึ้นใช้งานโดยเร็วและตรวจรุ่นในชุดที่ติดตั้งจริง
เกิดอะไรขึ้น
Guzzle ส่ง URI เป็นข้อความให้ตัวส่งคำขอ และกำหนดส่วนหัว Host แยกไว้ แต่ libcurl อาจถอดรหัสหรือแปลงชื่อโฮสต์ก่อนเชื่อมต่อ ชื่อที่แอปตรวจเลยอาจต่างจากปลายทางที่เชื่อมต่อจริง ปัญหาครอบคลุมทั้งตัวส่งผ่าน cURL และ StreamHandler
ถ้าผู้โจมตีกำหนด URI ได้ ก็อาจหลอกให้เซิร์ฟเวอร์ส่งคำขอไปยังโฮสต์ที่แอปห้ามไว้ นี่คือความเสี่ยง SSRF ผู้โจมตีอาจอ่านข้อมูลจากคำตอบได้เท่าที่แอปส่งกลับมาให้ ความต่างของชื่อยังกระทบการเลือก proxy การส่งข้อมูลยืนยันตัวตนเมื่อ redirect และการเก็บ cookie
แอปเข้าข่ายเมื่อรับข้อมูลจากภายนอกมาสร้าง URI แล้วตรวจโฮสต์ก่อนส่งให้ Guzzle แอปที่ดึงเฉพาะ URI ที่สร้างเองไม่รับผลกระทบ การอนุญาตเฉพาะชื่อมาตรฐานที่ตรงกันมักปฏิเสธชื่อผิดรูปได้ ส่วนการบล็อกชื่อบางรายการหรือกรอง IP ภายในเสี่ยงถูกข้าม
ใครโดนและรุ่นที่แก้
ประกาศ GHSA-v5mv-p594-2x33 ระบุช่วงรุ่นของแพ็กเกจ guzzlehttp/guzzle ดังนี้
| แพ็กเกจ / ช่วงรุ่นที่ได้รับผลกระทบ | รุ่นที่แก้ |
|---|---|
guzzlehttp/guzzle ทุกรุ่นต่ำกว่า 7.15.2 |
7.15.2 |
guzzlehttp/guzzle ตั้งแต่ 8.0.0 แต่ต่ำกว่า 8.0.1 |
8.0.1 |
แพตช์เพิ่มการตรวจโฮสต์ในตัวส่งคำขอที่มากับ Guzzle ทั้งสามตัวก่อนเชื่อมต่อเครือข่าย และแก้การสร้าง Host เมื่อไคลเอนต์เขียน URI ใหม่
ต้องทำอะไร
ตรวจ composer.lock ว่ามีแพ็กเกจนี้หรือไม่ รวมถึงกรณีที่ไลบรารีอื่นดึงเข้ามา เลือกรุ่นแก้ให้ตรงสายและตรวจข้อกำหนดใน composer.json ว่าอนุญาตให้อัปเดตได้ แล้วรันในพื้นที่พัฒนาหรือทดสอบ ตัวเลือกด้านล่างเปิดให้อัปเดตแพ็กเกจที่เกี่ยวข้องด้วย ตามคู่มือ Composer
composer update guzzlehttp/guzzle --with-all-dependencies
composer show guzzlehttp/guzzle
ตรวจรุ่นที่ได้ ทดสอบการดึง URL และการเปลี่ยนเส้นทาง แล้วนำ composer.lock กับชุดแอปขึ้นใช้งาน หากข้อกำหนดรุ่นขัดกัน ต้องแก้ข้อกำหนดหรือแพ็กเกจต้นทางก่อน
หากยังอัปเดตไม่ได้ ผู้พัฒนาแนะนำให้ตรวจโฮสต์และส่วนหัว Host แยกกันทุกครั้งที่เปลี่ยนเส้นทาง โดยจำกัดอักขระและปฏิเสธรูปแบบต้องห้ามตามตัวอย่างในประกาศ หากรับ UriInterface จากภายนอกให้แปลงกลับผ่าน GuzzleHttp\Psr7\Uri ก่อนใช้กฎนั้น
แพตช์ยังยอมรับ IP แบบย่อ การเทียบข้อความโฮสต์อย่างเดียวเลยยังไม่พอ ผู้พัฒนาแนะนำให้ resolve แล้วตรวจที่อยู่ปลายทาง และแยก cookie jar สำหรับต้นทางที่ไม่เชื่อถือ การเปิด idn_conversion ไม่ใช่การควบคุมสิทธิ์เข้าถึง
ส่วนตัวผมให้เร่งแพตช์ถ้าแอปรับ URL จากภายนอกและใช้การตรวจโฮสต์คุมปลายทาง พร้อมทบทวนกฎป้องกัน SSRF ควบคู่กัน ที่มา: Guzzle: Noncanonical host can bypass host-based checks และประกาศผู้พัฒนา Guzzle หากมีรายละเอียดจากผู้พัฒนาเพิ่มเติม เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย