Security Notice

Guzzle อาจส่งข้อมูลยืนยันตัวตนพร็อกซีผิดปลายทาง CVE-2026-67339

โดย Ton-Or ·14 ก.ค. 2026·อ่าน 4 นาที

นักพัฒนาและผู้ดูแลระบบที่ใช้ Guzzle พร้อมข้อมูลยืนยันตัวตนพร็อกซีควรตรวจการตั้งค่าและเร่งอัปเดตเป็น 7.14.2 หรือใหม่กว่า

สรุปใน 1 นาที

อาการ/ปัญหา: เฮดเดอร์ Proxy-Authorization อาจหลุดถึงเซิร์ฟเวอร์ปลายทางและเปิดเผยข้อมูลยืนยันตัวตนของพร็อกซี
ใครควรอ่าน: นักพัฒนาและผู้ดูแลระบบที่ดูแลแอป PHP ซึ่งใช้ Guzzle และตั้งค่าข้อมูลยืนยันตัวตนพร็อกซีในเงื่อนไขที่ประกาศระบุ
ทางแก้แบบสั้น: อัปเดต guzzlehttp/guzzle เป็น 7.14.2 หรือใหม่กว่า หรือใช้วิธีส่งข้อมูลยืนยันตัวตนพร็อกซีทดแทนตามคำแนะนำผู้พัฒนาระหว่างรอ

พอดีไล่ฟีด Packagist แล้วเจอประกาศของ Guzzle ไลบรารี HTTP สำหรับ PHP เรื่อง Proxy-Authorization อาจหลุดถึงเซิร์ฟเวอร์ปลายทาง ทั้งที่มีไว้ให้พร็อกซีเท่านั้น ช่องโหว่ CVE-2026-67339 หรือ GHSA-94pj-82f3-465w มีความรุนแรงปานกลาง คะแนน CVSS 3.1 5.3/10 ตาม ประกาศ GitHub Advisory Database

Guzzleไลบรารี HTTP ของ PHP

<7.14.2รุ่นที่ได้รับผลกระทบ

7.14.2รุ่นที่แก้ไข

5.3/10CVSS 3.1 ปานกลาง

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

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

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

CurlHandler และ CurlMultiHandler ใส่เฮดเดอร์ของคำขอลงในรายการที่จะส่งให้เซิร์ฟเวอร์ปลายทางก่อน แล้วค่อยแยก Proxy-Authorization ออกเมื่อคาดว่าจะใช้พร็อกซี HTTP หรือ HTTPS แต่ libcurl อาจเลือกเส้นทางต่างจากที่ Guzzle คาด เฮดเดอร์เลยติดไปกับคำขอที่ต่อตรง ข้ามพร็อกซีตาม NO_PROXY หรือผ่าน SOCKS ได้ การ redirect ไปเส้นทางเหล่านี้ก็เข้าข่าย เฮดเดอร์อาจมาจากค่าเริ่มต้นของ client ตัวเลือกคำขอ หรือ middleware ดูรายละเอียดใน ประกาศช่องโหว่

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

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

แพ็กเกจ	รุ่นที่ได้รับผลกระทบ	รุ่นที่แก้ไข
`guzzlehttp/guzzle`	ทุกรุ่นก่อน `7.14.2`	`7.14.2`

Guzzle ไม่ได้สร้างเฮดเดอร์นี้เอง แอปที่ไม่เคยตั้ง Proxy-Authorization เลยไม่เข้าข่ายปัญหาส่วนนี้ การใส่ข้อมูลบัญชีใน URL ของพร็อกซีอย่างเดียวก็ไม่เข้าข่าย แต่ stream handler อาจทำข้อมูลนั้นรั่วได้หากใช้ร่วมกับเฮดเดอร์นี้ หรือเขียนทับ stream_context.http.proxy ภายหลัง ส่วน CURLOPT_PROXYUSERPWD ไม่ได้รับผลกระทบตาม ประกาศผู้พัฒนา

รุ่นที่แก้แยกข้อมูลพร็อกซีออกจากเฮดเดอร์ปลายทาง และปฏิเสธบางการตั้งค่าที่ไม่ปลอดภัยก่อนเชื่อมต่อ ควรทดสอบพร็อกซีหลังอัปเดตด้วย ดู บันทึกรุ่น 7.14.2

ต้องทำอะไร

ตรวจการตั้ง Proxy-Authorization ในโค้ด ค่าเริ่มต้น และ middleware แล้วอัปเดต dependency ด้วย Composer และตรวจรุ่นอีกครั้ง

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

ต้องได้ 7.14.2 หรือใหม่กว่า หาก composer.json หรือแพ็กเกจอื่นล็อกรุ่นเก่า ต้องแก้ข้อกำหนดและทดสอบความเข้ากันได้ก่อน แล้วนำไฟล์ล็อกและ dependency ที่อัปเดตไปติดตั้งจริง

หากยังอัปเดตไม่ได้ ผู้พัฒนาแนะนำให้ลบ Proxy-Authorization จากเฮดเดอร์คำขอ ค่าเริ่มต้นของ client และ middleware แล้วส่งข้อมูลยืนยันตัวตนผ่าน URL ของพร็อกซีแทน หรือใช้ CURLOPT_PROXYUSERPWD เมื่อใช้ cURL handler อย่าใช้ข้อมูลบัญชีใน URL ร่วมกับเฮดเดอร์นี้ และอย่าเขียนทับ stream_context.http.proxy โดยตรง ตาม วิธีลดความเสี่ยงของผู้พัฒนา

ข้อควรระวัง

การอัปเดต libcurl อย่างเดียวไม่แก้ปัญหาการแยกเฮดเดอร์ตามเส้นทางของ Guzzle และการปิด redirect ช่วยลดความเสี่ยงแต่ยังไม่ปิดทุกช่องทางรั่ว ตามประกาศผู้พัฒนา

ส่วนตัวผมให้เร่งแพตช์ถ้าแอปตั้งเฮดเดอร์นี้และมีคำขอที่เข้าเงื่อนไขรั่ว ที่มา: Guzzle: Proxy-Authorization headers can be sent to origin servers (GHSA-94pj-82f3-465w) เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ

อยากให้เราทำให้ไหม?

ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า

คุยเรื่องงานกับเรา

แท็ก #php #security #cve #web-security #patch-management

เคยเจองานแบบนี้ไหม? ติดตรงไหน?

มาแลกวิธีกันต่อในบอร์ด LinuxThai

→ คุยต่อในบอร์ด

ความคิดเห็น 0

ยังไม่มีความคิดเห็น — เป็นคนแรกเลย