Guzzle คุกกี้รั่วและถูกแทรกผ่านโดเมน IP: CVE-2026-59883

พอดีไล่ฟีด Packagist เจอประกาศช่องโหว่ของ Guzzle ไลบรารี HTTP สำหรับ PHP รหัส CVE-2026-59883 ปัญหาอยู่ที่การเลือกคุกกี้ให้ปลายทาง คุกกี้ที่ควรส่งให้ IP เดียวอาจหลุดไปโฮสต์อื่น โฮสต์อื่นก็อาจแทรกคุกกี้กลับมาได้ ประกาศจัดระดับปานกลาง โดยให้คะแนน CVSS 3.1 ที่ 4.7 จาก 10

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

• ผู้ดูแลระบบ: หากแอปเข้าเงื่อนไขข้างต้น ให้ประสานทีมพัฒนาเพื่อนำรุ่นที่แก้แล้วขึ้นใช้งานโดยเร็ว
• นักพัฒนา: ตรวจการใช้คุกกี้ร่วมกันข้ามโฮสต์และอัปเดต Guzzle โดยเร็วหากมีคุกกี้ที่ผูกกับ IP หรือชื่อโฮสต์ตัวเลขล้วน

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

CookieJar เป็นที่เก็บคุกกี้ของ client จุดที่ผิดคือ SetCookie::matchesDomain() ตรวจ IP เฉพาะโฮสต์ปลายทาง แต่ไม่ได้ตรวจค่าโดเมนของคุกกี้ด้วย เลยยอมให้ชื่อโฮสต์ที่ลงท้ายตรงกันใช้คุกกี้นั้นได้ ปัญหานี้เกิดกับค่า IPv4, IPv6 ในวงเล็บเหลี่ยม และค่าตัวเลขล้วนที่อ่านเป็น IPv4 ทั้งหมดนี้ควรจับคู่กับโฮสต์ที่ตรงกันทั้งชื่อเท่านั้น

ผลคือชื่อโฮสต์อื่นที่ลงท้ายตรงกับค่าโดเมนดังกล่าวอาจได้รับคุกกี้ไปด้วย ในทางกลับกัน โฮสต์เลียนแบบก็อาจฝากคุกกี้ให้ Guzzle ส่งไปยัง IP จริงได้ ผลกระทบมีทั้งคุกกี้รั่วและคุกกี้ถูกแทรก อีกกรณีคือ session fixation ซึ่งบังคับให้ใช้เซสชันที่ผู้โจมตีกำหนด ผลที่เกิดขึ้นขึ้นกับวิธีอ่านคุกกี้ของบริการปลายทาง

การรั่วต้องมีทั้งการใช้คลังคุกกี้ร่วมกันและการเชื่อมต่อถึงโฮสต์เลียนแบบได้จริง ชื่อแบบนี้จดทะเบียนสาธารณะไม่ได้ตามประกาศ ผู้โจมตีเลยต้องมีอิทธิพลต่อการแปลงชื่อเป็น IP เช่น ในเครือข่ายภายใน คอนเทนเนอร์ หรือสภาพแวดล้อมพัฒนา

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

แอปต้องเปิดใช้คุกกี้ของ Guzzle ใช้ CookieJar ร่วมกันข้ามโฮสต์หรือขอบเขตความเชื่อถือ และมีคุกกี้ผูกกับ IP หรือชื่อโฮสต์ตัวเลขล้วน หากไม่เปิดใช้คุกกี้ แยกคลังตามโฮสต์อยู่แล้ว หรือไม่มีคุกกี้ลักษณะนี้ ประกาศระบุว่าไม่เข้าเงื่อนไขได้รับผลกระทบ รุ่นที่แก้เปลี่ยนให้โดเมนเหล่านี้จับคู่ได้เฉพาะโฮสต์ที่ตรงกันทั้งหมด

ต้องทำอะไร

ตรวจรุ่นในโปรเจกต์และโค้ดที่สร้าง HTTP client ก่อน แล้วใช้ Composer อัปเดตในระบบทดสอบ ข้อกำหนดรุ่นในโปรเจกต์ต้องยอมรับ 7.12.3 หรือใหม่กว่าด้วย (เอกสารคำสั่ง Composer)

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

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

ตรวจตัวเลือก cookies => true ด้วย เพราะจะสร้างคลังคุกกี้ร่วมสำหรับไคลเอนต์นั้น หากไคลเอนต์เดียวติดต่อหลายโฮสต์ที่มีระดับความเชื่อถือต่างกัน ควรแยกที่เก็บคุกกี้ตามคำแนะนำข้างต้น

ส่วนตัวผมให้เร่งแพตช์เมื่อเข้าเงื่อนไขใช้คุกกี้ร่วมข้ามโฮสต์และมีคุกกี้ผูกกับ IP ส่วนแอปที่ไม่เข้าเงื่อนไขจัดอัปเดตตามรอบบำรุงรักษาได้ ที่มา: Guzzle: Cookie Disclosure and Injection via IP-Address Domains — GHSA-g446-98w2-8p5w และ ประกาศรุ่น 7.12.3 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ