Guzzle รับคุกกี้ไม่จำกัด เสี่ยงบริการล่ม CVE-2026-67353
นักพัฒนาและผู้ดูแลระบบที่ใช้ Guzzle รับคุกกี้จากปลายทางที่ไม่ไว้วางใจควรเร่งอัปเดตเป็น 7.15.1 หรือใหม่กว่า
สรุปใน 1 นาที
- อาการ/ปัญหา
- คุกกี้จำนวนมากหรือขนาดใหญ่ทำให้ใช้หน่วยความจำเพิ่มและคำขอถัดไปล้มเหลวได้
- ใครควรอ่าน
- นักพัฒนาและผู้ดูแลระบบของแอป PHP ที่ใช้ CookieJar ในตัวของ Guzzle รับคำตอบที่ผู้โจมตีควบคุมและเก็บคุกกี้ไว้ใช้ต่อ
- ทางแก้แบบสั้น
- อัปเดต guzzlehttp/guzzle เป็น 7.15.1 หรือใหม่กว่า และแยกหรือปิดการรับคุกกี้จากปลายทางที่ไม่ไว้วางใจระหว่างรอแพตช์
พอดีไล่ฟีด Packagist เจอประกาศของ Guzzle ไลบรารี HTTP สำหรับ PHP เรื่องรับคุกกี้จาก response โดยไม่จำกัดจำนวนหรือขนาด รหัส CVE-2026-67353 ปัญหานี้อาจทำให้บริการช้าหรือส่งคำขอต่อไม่ได้ โดยเฉพาะแอปที่เก็บคุกกี้จากเว็บภายนอกแล้วนำกลับมาใช้ ระดับความรุนแรงอยู่ที่ปานกลาง คะแนน CVSS 3.1 เท่ากับ 5.3 จาก 10
ใครต้องทำอะไร
- นักพัฒนา: ถ้าใช้ Guzzle รับและเก็บคุกกี้จากปลายทางที่ไม่ไว้วางใจ ให้เร่งอัปเดต dependency เป็น 7.15.1 หรือใหม่กว่าและทดสอบก่อนนำขึ้นใช้งาน
- ผู้ดูแลระบบ: ถ้าดูแลแอป PHP ที่มีเงื่อนไขนี้ ให้ประสานทีมพัฒนาเพื่อนำแพตช์ขึ้นใช้งานโดยเร็ว พร้อมตรวจรุ่นแพ็กเกจในชุดที่ติดตั้งจริง
เกิดอะไรขึ้น
CookieJar คือที่เก็บคุกกี้ของ Guzzle รุ่นที่มีปัญหารับเฮดเดอร์ Set-Cookie จาก response โดยไม่จำกัดจำนวนหรือขนาด พอส่งคำขอครั้งถัดไป ก็รวมคุกกี้ที่ใช้กับปลายทางนั้นลงในเฮดเดอร์ Cookie โดยไม่จำกัดความยาว
เซิร์ฟเวอร์ที่ผู้โจมตีควบคุมเลยส่งคุกกี้ขนาดใหญ่จำนวนมากมาให้แอปเก็บได้ ผลคือใช้หน่วยความจำและเวลาประมวลผลเพิ่ม คำขอถัดไปอาจถูกปฏิเสธเพราะเฮดเดอร์ยาวเกินที่ระบบระหว่างทางรับได้ ผลที่ประกาศยืนยันคือ denial of service หรือทำให้บริการใช้งานไม่ได้
ถ้าใช้ jar ร่วมกัน คุกกี้ระดับโดเมนแม่จากโฮสต์หนึ่งอาจถูกส่งไปยังอีกโฮสต์ใต้โดเมนแม่เดียวกันได้ ทำให้บริการอีกปลายทางได้รับผลกระทบด้วย เงื่อนไขสำคัญคือเปิดใช้คุกกี้ในตัว รับคำตอบที่ผู้โจมตีควบคุม และเก็บหรือนำ jar กลับมาใช้ แอปที่ไม่ใช้คุกกี้ไม่เข้าข่ายพฤติกรรมนี้
ใครโดนและรุ่นที่แก้
| แพ็กเกจ | รุ่นที่ได้รับผลกระทบ | รุ่นที่แก้ไข |
|---|---|---|
guzzlehttp/guzzle ผ่าน Composer |
ต่ำกว่า 7.15.1 | 7.15.1 หรือใหม่กว่า |
แพตช์ให้เพิ่มหรือแทนที่คุกกี้สำเร็จได้ไม่เกิน 50 รายการต่อ response ค่า Set-Cookie ที่ยาวเกิน 8,190 ไบต์จะถูกข้าม ฝั่งคำขอส่งคุกกี้ได้ไม่เกิน 150 คู่ และทั้งบรรทัด Cookie: รวมชื่อเฮดเดอร์กับช่องว่างต้องไม่เกิน 8,190 ไบต์ แต่ยังไม่มีเพดานจำนวนคุกกี้สะสมจาก response หลายครั้ง
ต้องทำอะไร
ตรวจ dependency ของแต่ละโปรเจกต์ก่อน เพราะ Guzzle อาจถูกติดตั้งผ่านแพ็กเกจอื่นด้วย จากนั้นอัปเดตในสภาพแวดล้อมทดสอบ โดยรันคำสั่งในโฟลเดอร์ที่มี composer.json
composer show guzzlehttp/guzzle
composer update guzzlehttp/guzzle --with-all-dependencies
composer show guzzlehttp/guzzle
composer audit
ตรวจว่ารุ่นหลังอัปเดตเป็น 7.15.1 หรือใหม่กว่า ตัวเลือก --with-all-dependencies อาจทำให้ dependency ที่เกี่ยวข้องเปลี่ยนตาม หากติดข้อกำหนดรุ่นในโปรเจกต์ ต้องแก้ข้อกำหนดหรืออัปเดตแพ็กเกจที่บังคับใช้รุ่นเก่าก่อน ดูรายละเอียดคำสั่งได้จาก คู่มือ Composer
คำแนะนำในการนำขึ้นใช้งานคือทดสอบเส้นทางที่ต้องเก็บคุกกี้ เช่น การเรียกบริการภายนอกต่อเนื่อง แล้วส่ง composer.lock ที่อัปเดตพร้อมชุดแอป การรัน install ด้วย lock เดิมจะยังได้รุ่นเดิม ควรตรวจรุ่นในชุดที่ใช้งานจริงอีกครั้ง
หากยังอัปเดตไม่ได้ ผู้พัฒนาแนะนำให้แยก jar ตามโฮสต์หรือขอบเขตความไว้วางใจ ปิดคุกกี้สำหรับคำขอที่ไม่ไว้วางใจ หรือล้าง jar หลังรับคำตอบก่อนใช้ต่อ หากจำเป็นต้องรับคุกกี้จากปลายทางเหล่านี้ ให้ใช้ CookieJarInterface ที่กำหนดขีดจำกัดเอง
อัปเดต libcurl อย่างเดียวไม่แก้ปัญหา เพราะ Guzzle จัดการ CookieJar เอง ขีดจำกัดคุกกี้ของ libcurl ไม่ได้ครอบคลุมส่วนนี้
ส่วนตัวผมให้เร่งแพตช์หากรับคุกกี้จากปลายทางที่ไม่ไว้วางใจและใช้ jar ต่อเนื่อง ส่วนแอปที่ไม่เปิดคุกกี้ให้ตรวจยืนยันเงื่อนไขก่อนจัดรอบอัปเดต ที่มา: Guzzle: Unbounded response cookies risk denial of service เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย