Guzzle ข้ามการตรวจโฮสต์ได้ CVE-2026-69246
นักพัฒนาและผู้ดูแลระบบที่ใช้ Guzzle ดึง URL จากภายนอกพร้อมตรวจโฮสต์ควรเร่งอัปเดตและทบทวนการตรวจปลายทาง
1-minute summary
- Symptom / problem
- ชื่อโฮสต์ที่แอปตรวจอาจต่างจากปลายทางที่ตัวส่งคำขอเชื่อมต่อจริง ทำให้ข้ามข้อจำกัดตามโฮสต์ได้
- Who should read
- นักพัฒนาและผู้ดูแลระบบของแอป PHP ที่ใช้ Guzzle รับ URL ที่ผู้ใช้ควบคุมได้และตรวจโฮสต์ก่อนส่งคำขอ
- Fix in short
- อัปเดต 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 หากมีรายละเอียดจากผู้พัฒนาเพิ่มเติม เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
Want us to set this up?
Get help with server setup, configuration, migration, or troubleshooting. Save time for the work that matters.
Hit something like this? Stuck somewhere?
Come trade notes on the LinuxThai board
Comments 0
No comments yet — be the first