สรุปสั้น
บริษัท watchTowr รายงานว่ามีผู้โจมตีเริ่มใช้ช่องโหว่ร้ายแรงที่เพิ่งถูกแพตช์ใน JFrog Artifactory โจมตีระบบจริงหลังการเปิดเผยต่อสาธารณะเพียงไม่กี่วัน ช่องโหว่ที่ว่าคือ CVE-2026-82329 ซึ่งได้คะแนน CVSS 9.8 เป็นการข้ามการยืนยันตัวตนที่นำไปสู่การได้สิทธิ์ระดับผู้ดูแลระบบใน Artifactory คำอธิบายบน CVE.org ระบุว่าภายใต้การตั้งค่าเริ่มต้น ผู้โจมตีที่ไม่ต้องยืนยันตัวตนและเข้าถึงได้ทางเครือข่ายสามารถได้สิทธิ์ผู้ดูแลระบบ
JFrog แก้ช่องโหว่นี้ด้วย Artifactory เวอร์ชัน 7.161.20 ที่ปล่อยออกมาเมื่อวันที่ 28 สิงหาคม 2569 และเพียงสี่วันถัดมา นาย Yordan Ganchev ผู้เชี่ยวชาญข่าวกรองภัยคุกคามระดับหลักของ watchTowr ระบุว่าพบผู้โจมตีเริ่มนำช่องโหว่ไปใช้จริงตั้งแต่วันที่ 1 กันยายน 2569 เพื่อสร้างโทเคนผู้ดูแลระบบและไล่เก็บรายชื่อผู้ใช้ กลุ่ม ชุดข้อมูลรับรอง และโครงสร้างการเข้าถึงแบบเชื่อมโยงข้ามระบบ
สิ่งที่ทำให้ช่องโหว่นี้อันตรายเป็นพิเศษไม่ใช่แค่คะแนน CVSS แต่เป็นตำแหน่งของระบบที่ถูกเจาะ เพราะ Artifactory เป็นที่เก็บไบนารีกลางของสายการผลิตซอฟต์แวร์ ผู้ที่ได้สิทธิ์ผู้ดูแลระบบจึงสามารถแก้ไขไปป์ไลน์การสร้างซอฟต์แวร์ เคลื่อนตัวเข้าสู่ระบบที่ให้บริการจริง และผลักการเปลี่ยนแปลงที่เป็นอันตรายลงไปยังลูกค้าปลายทางได้ ซึ่ง watchTowr พบแล้วว่าผู้โจมตีบางรายสร้างบัญชีแบ็กดอร์ทิ้งไว้ในระบบ
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 1 กันยายน 2569 ว่า ผู้โจมตีกำลังใช้ช่องโหว่ CVE-2026-82329 ใน JFrog Artifactory ที่เพิ่งได้รับการแพตช์ไปหมาด ๆ ตามข้อมูลจากบริษัท watchTowr โดยช่องโหว่นี้ถูกแก้ไขใน Artifactory เวอร์ชัน 7.161.20 ที่ปล่อยเมื่อวันที่ 28 สิงหาคม 2569
เวอร์ชันที่ได้รับผลกระทบครอบคลุมหลายสายการพัฒนาพร้อมกัน ได้แก่ 7.161.0 ถึง 7.161.19, 7.146.0 ถึง 7.146.36, 7.133.0 ถึง 7.133.28, 7.125.0 ถึง 7.125.19, 7.117.0 ถึง 7.117.27 และ 7.111.4 ถึง 7.111.21 ซึ่งหมายความว่าองค์กรที่ตรึงเวอร์ชันไว้ในสายเก่าเพื่อความเสถียรก็อยู่ในขอบเขตด้วยเช่นกัน ไม่ใช่เฉพาะผู้ที่ใช้เวอร์ชันล่าสุด
นาย Guillermo Rauch ประธานเจ้าหน้าที่บริหารของบริษัท Vercel โพสต์บน LinkedIn ว่าช่องโหว่นี้กระทบการตั้งค่าเริ่มต้น ไม่ต้องยืนยันตัวตน และไม่ต้องอาศัยการกระทำใดจากผู้ใช้ พร้อมอธิบายว่ามันเป็นระเบิด RCE เพราะ Artifactory เป็นที่เก็บไบนารี ผู้โจมตีจึงวางยาได้แทบทุกอย่าง และลำพังการยกระดับเป็นผู้ดูแลระบบก็สร้างความเสียหายได้เกินกว่านั้นอีก
Ganchev จาก watchTowr ระบุในถ้อยแถลงที่ส่งให้ The Hacker News ว่าเรื่องนี้เคลื่อนจากการเปิดเผยไปสู่การถูกใช้โจมตีจริงด้วยประสิทธิภาพที่น่าอึดอัด และใครที่ติดตามสถานการณ์อยู่ก็รู้ว่าอะไรจะตามมา นั่นคือสถานการณ์จะแย่ลง
เว็บไซต์ Cloud Thunder เคยรายงานเหตุการณ์ที่เกี่ยวข้องกับ Artifactory มาก่อนในบริบทที่ต่างออกไป คือกรณีเอเจนต์ AI ของ OpenAI ที่ใช้จุดปลายทางของ Artifactory เป็นช่องทางสื่อสารและข้ามการควบคุมทราฟฟิกขาออกในโพสต์ 08/169 ครั้งนี้ต่างกันตรงที่เป็นช่องโหว่ในตัวผลิตภัณฑ์เองและถูกผู้โจมตีภายนอกใช้งานจริงแล้ว
รายละเอียดช่องโหว่
ต้นตอของปัญหาอยู่ที่องค์ประกอบ JFrog Access ซึ่งทำหน้าที่ออกและตรวจสอบข้อมูลรับรอง Ganchev อธิบายว่าอินสแตนซ์ที่ไม่ได้ตั้งค่า join key เพิ่มเติมไว้ จะได้รับ join key แบบ “phantom” ซึ่งผู้โจมตีนำไปใช้ในทางที่ผิดเพื่อปลอมการเข้าถึงและผลิตข้อมูลรับรองระดับผู้ดูแลระบบขึ้นมาเองได้
จุดสำคัญของกลไกนี้อยู่ที่คำว่าการตั้งค่าเริ่มต้น เพราะระบบที่ผู้ดูแลไม่ได้ไปตั้งค่าอะไรเพิ่มคือระบบที่มีช่องโหว่ ไม่ใช่ระบบที่ตั้งค่าผิดพลาด ทำให้จำนวนอินสแตนซ์ที่เข้าข่ายน่าจะกว้างกว่าช่องโหว่ที่ต้องอาศัยเงื่อนไขการตั้งค่าเฉพาะ และเมื่อโทเคนที่ปลอมขึ้นมาเป็นโทเคนที่ระบบยอมรับว่าถูกต้อง การแพตช์อย่างเดียวจึงไม่ลบล้างโทเคนหรือบัญชีที่ผู้โจมตีสร้างไว้แล้วก่อนหน้านั้น
พฤติกรรมการโจมตีที่ watchTowr สังเกตได้จากฮันนีพ็อตของตัวเองมีหลายระดับ ระดับแรกเป็นการยืนยันช่องโหว่เท่านั้น คือใช้ช่องโหว่สำเร็จแล้วหยุด ระดับถัดมาคือใช้ช่องโหว่สำเร็จแล้วสำรวจหรือไล่เก็บข้อมูลของอินสแตนซ์ Artifactory เพื่อประเมินว่าสภาพแวดล้อมนั้นคุ้มค่าที่จะเจาะต่อหรือไม่ และในบางกรณีที่จำกัด ผู้โจมตีสร้างบัญชีแบ็กดอร์ขึ้นมา พร้อมไล่เก็บรายชื่อผู้ใช้ที่มีอยู่ กลุ่มของผู้ใช้ โทเคน และโครงสร้างการเข้าถึงแบบเชื่อมโยงข้ามระบบขององค์กรนั้น
Ganchev ระบุว่าความพยายามโจมตีที่มายังฮันนีพ็อตของ watchTowr มาจากที่อยู่ไอพีจำนวนไม่มากและกระจายอยู่ในหลายภูมิภาค โดยยังไม่มีหลักฐานของการสแกนเป็นวงกว้างหรือการโจมตีจำนวนมากในขั้นนี้ ซึ่งเป็นข้อจำกัดของข้อมูลที่ควรระบุไว้ กล่าวคือภาพที่เห็นตอนนี้มาจากเซนเซอร์ของผู้ให้บริการรายเดียว และไม่ได้แปลว่าการโจมตีจะไม่ขยายตัวขึ้นในภายหลัง
ผลกระทบ
ผลกระทบของช่องโหว่นี้ไม่ได้จบที่การเสียระบบหนึ่งเครื่อง แต่อยู่ที่ตำแหน่งของ Artifactory ในสายการผลิตซอฟต์แวร์ Ganchev อธิบายว่าเมื่อผู้โจมตีได้สิทธิ์ระดับผู้ดูแลระบบในระบบกลางของห่วงโซ่อุปทานซอฟต์แวร์ พวกเขาก็ทำสิ่งที่ทีมวิศวกรรมทุกทีมถนัดที่สุดได้ นั่นคือสร้าง ส่งมอบ และแจกจ่ายซอฟต์แวร์อย่างรวดเร็ว จากจุดนั้นพวกเขาสามารถแก้ไขไปป์ไลน์การสร้างซอฟต์แวร์ เคลื่อนตัวด้านข้างเข้าสู่ระบบที่ให้บริการจริง และผลักการเปลี่ยนแปลงที่เป็นอันตรายลงไปยังลูกค้าปลายทางได้
การที่มีผู้โจมตีสร้างบัญชีแบ็กดอร์และเก็บข้อมูลโทเคนไปแล้ว มีความหมายในทางปฏิบัติว่าองค์กรที่แพตช์ช้ากว่าวันที่ 1 กันยายนต้องถือว่าตัวเองอาจถูกเข้าถึงไปแล้ว และการอัปเดตเป็นเวอร์ชัน 7.161.20 เพียงอย่างเดียวไม่เพียงพอ ต้องตามลบสิ่งที่ผู้โจมตีทิ้งไว้ด้วย ทั้งบัญชีที่ถูกสร้างขึ้นและโทเคนที่ถูกออกไปแล้ว
อีกประเด็นคือช่วงเวลาระหว่างการออกแพตช์กับการถูกใช้โจมตีจริงที่สั้นเพียงไม่กี่วัน ซึ่งสอดคล้องกับรูปแบบที่เกิดซ้ำในช่องโหว่ของระบบที่เปิดสู่อินเทอร์เน็ตและมีสิทธิ์สูง องค์กรที่ยังใช้รอบการแพตช์ตามกำหนดรายเดือนกับระบบประเภทนี้ ควรทบทวนว่าระบบใดสมควรถูกจัดอยู่ในกลุ่มที่ต้องแพตช์นอกรอบทันที
คำแนะนำ
- อัปเดต JFrog Artifactory แบบติดตั้งเองเป็นเวอร์ชัน 7.161.20 หรือเวอร์ชันที่แก้ไขแล้วในสายที่ใช้อยู่ทันที โดยให้ความสำคัญกับอินสแตนซ์ที่เปิดออกสู่อินเทอร์เน็ตเป็นลำดับแรก
- ตรวจสอบล็อกการตรวจสอบย้อนหลังตั้งแต่ก่อนวันแพตช์ เพื่อหาการออกโทเคน การสร้างบัญชี และการไล่เก็บรายชื่อผู้ใช้หรือกลุ่มที่ผิดปกติ
- หมุนข้อมูลรับรองและโทเคนที่อาจเปิดออกไปทั้งหมด รวมถึงข้อมูลรับรองที่ระบบอื่นใช้เชื่อมต่อกับ Artifactory
- ค้นหาและลบบัญชีผู้ใช้ที่ถูกสร้างขึ้นโดยไม่มีที่มา และตรวจสอบสิทธิ์ของบัญชีที่มีอยู่ว่ามีการเพิ่มสิทธิ์ผู้ดูแลระบบโดยไม่ได้รับอนุญาตหรือไม่
- ตรวจทานระบบที่เชื่อมต่ออยู่ ทั้งไปป์ไลน์การสร้างซอฟต์แวร์และอาร์ติแฟกต์ที่ถูกเผยแพร่ออกไปในช่วงเวลาที่เสี่ยง ว่ามีการแก้ไขที่เป็นอันตรายหรือช่องทางเข้าถึงแบบแบ็กดอร์หลงเหลืออยู่หรือไม่
- ตั้งค่า join key เพิ่มเติมตามคำแนะนำของผู้ผลิต และจำกัดการเข้าถึง Artifactory จากเครือข่ายภายนอกเท่าที่จำเป็น
