สรุปสั้น

หน่วยงาน Cybersecurity and Infrastructure Security Agency (CISA) ของสหรัฐฯ ยืนยันว่าช่องโหว่ที่เพิ่งได้รับแพตช์ใน JetBrains TeamCity เวอร์ชันที่ติดตั้งบนเซิร์ฟเวอร์ขององค์กรเอง กำลังถูกใช้โจมตีจริงในธรรมชาติแล้ว ช่องโหว่ที่ว่าคือ CVE-2026-63077 ซึ่งได้คะแนน CVSS 9.8 จัดอยู่ในระดับวิกฤต โดยเป็นช่องโหว่ประเภท deserialization ของข้อมูลที่ไม่น่าเชื่อถือ

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

ประเด็นสำคัญที่ยังไม่มีคำตอบคือ ปัจจุบันยังไม่ทราบว่าช่องโหว่ถูกโจมตีด้วยวิธีใด ใครเป็นผู้อยู่เบื้องหลัง และการโจมตีเกิดขึ้นในวงกว้างแค่ไหน อีกทั้ง JetBrains เองก็ยังไม่ได้อัปเดตคำแนะนำด้านความปลอดภัยเพื่อยืนยันว่ามีการโจมตีจริง ผู้ใช้เวอร์ชันติดตั้งเองจึงควรอัปเดตทันที ส่วนหน่วยงานรัฐบาลกลางสหรัฐฯ (FCEB) มีเส้นตายต้องแพตช์ภายในวันที่ 8 สิงหาคม 2569

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 6 สิงหาคม 2569 ว่า CISA ได้เพิ่ม CVE-2026-63077 เข้าแคตตาล็อก Known Exploited Vulnerabilities (KEV) โดย CISA อธิบายลักษณะช่องโหว่ไว้ว่า “JetBrains TeamCity มีช่องโหว่ deserialization ของข้อมูลที่ไม่น่าเชื่อถือ ซึ่งอาจเปิดทางให้เกิดการรันโค้ดระยะไกลโดยไม่ต้องยืนยันตัวตนผ่านโปรโตคอล agent polling” ซึ่งตรงกับคำอธิบายของ JetBrains ที่ระบุว่าผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนสามารถใช้ช่องทางเดียวกันนี้เลี่ยงการตรวจสอบสิทธิ์แล้วรันคำสั่งระบบปฏิบัติการได้

การขึ้นบัญชี KEV ครั้งนี้เกิดขึ้นภายใต้ Binding Operational Directive (BOD) 26-04 ซึ่งกำหนดให้หน่วยงาน FCEB ต้องจัดลำดับความสำคัญในการแพตช์ช่องโหว่ความเสี่ยงสูงที่อยู่ในแคตตาล็อก โดยเส้นตายสำหรับ CVE-2026-63077 คือวันที่ 8 สิงหาคม 2569 ซึ่งเป็นกรอบเวลาที่สั้นมากเมื่อเทียบกับวันที่ประกาศ สะท้อนว่า CISA ประเมินความเร่งด่วนไว้สูง

นี่เป็นการเพิ่มช่องโหว่เข้า KEV ครั้งที่สองภายในสัปดาห์เดียว หลังจากเมื่อวันที่ 5 สิงหาคม CISA เพิ่งเพิ่มช่องโหว่ 3 รายการใน Langflow, Apache Tomcat และ N-able N-central เข้าไป (2026/08/031 ) สำหรับผลิตภัณฑ์ในเครือ JetBrains เอง ก่อนหน้านี้บริษัทเคยออกแพตช์ด่วนอุดช่องโหว่ร้ายแรงหลายตัวที่เปิดทางข้ามการยืนยันตัวตนและรันโค้ดมาแล้วเมื่อต้นเดือนกรกฎาคม (2026/07/041 ) และเมื่อวันที่ 24 กรกฎาคมก็มีการแก้ช่องโหว่ใน TeamCity อีก 4 จุดพร้อมกับช่องโหว่ RCE ใน IntelliJ IDEA (2026/07/264 ) แต่ CVE-2026-63077 เป็นคนละหมายเลขกับทุกตัวที่รายงานไปก่อนหน้านี้

รายละเอียดช่องโหว่

กลไกของช่องโหว่อยู่ที่การที่เซิร์ฟเวอร์ TeamCity รับข้อมูลที่ถูก serialize มาจากภายนอกแล้วแปลงกลับเป็นอ็อบเจกต์โดยไม่ได้ตรวจสอบความน่าเชื่อถือของข้อมูลนั้นก่อน ช่องโหว่ประเภทนี้เป็นที่รู้จักกันดีในโลก Java เพราะการ deserialize ข้อมูลที่ผู้โจมตีควบคุมได้ เปิดทางให้สร้างสายโซ่ของอ็อบเจกต์ที่นำไปสู่การเรียกคำสั่งบนระบบปฏิบัติการในที่สุด

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

ขอบเขตความเสียหายตามที่ JetBrains ระบุนั้นแปรผันตามสิทธิ์ที่ให้กับโปรเซสของเซิร์ฟเวอร์ TeamCity การโจมตีที่สำเร็จอาจทำให้ข้อมูลของ TeamCity ค่าตั้งค่าต่างๆ และข้อมูลรับรองที่เก็บไว้ในระบบถูกเปิดเผย เปลี่ยนแปลงสถานะของเซิร์ฟเวอร์ได้ และอาจกระทบความถูกต้องของ build artifact รวมถึงไปป์ไลน์ CI/CD ที่อยู่ถัดจากนั้น

สิ่งที่ยังไม่มีข้อมูลและควรระบุให้ชัดคือ ไม่มีการเปิดเผยว่าผู้โจมตีใช้เพย์โหลดแบบใด ไม่มีตัวบ่งชี้การบุกรุก (IoC) ที่เผยแพร่ต่อสาธารณะ ไม่มีการระบุกลุ่มผู้ก่อเหตุ และไม่มีตัวเลขจำนวนระบบที่ถูกโจมตี CISA อาศัยหลักฐานภายในของตนในการขึ้นบัญชี ขณะที่คำแนะนำของ JetBrains ยังไม่ได้ปรับให้สะท้อนสถานะ “ถูกโจมตีจริง” แต่อย่างใด

ผลกระทบ

องค์กรที่ได้รับผลกระทบคือผู้ที่ติดตั้ง TeamCity ไว้บนโครงสร้างพื้นฐานของตัวเอง ซึ่งมักเป็นองค์กรที่ต้องการเก็บซอร์สโค้ดและกระบวนการ build ไว้ภายใน เซิร์ฟเวอร์ประเภทนี้จึงมักถือครองข้อมูลรับรองที่มีสิทธิ์สูงจำนวนมาก ทั้งโทเค็นเข้าถึงที่เก็บซอร์สโค้ด คีย์สำหรับ deploy ขึ้นระบบโปรดักชัน ข้อมูลรับรองของ container registry และคีย์สำหรับลงลายมือชื่อดิจิทัลของซอฟต์แวร์

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

ในทางปฏิบัติ องค์กรจำนวนไม่น้อยยังปฏิบัติกับเซิร์ฟเวอร์ build เสมือนเป็นเครื่องมือภายในที่ไม่ต้องเข้มงวดเท่าระบบที่ให้บริการลูกค้า ทั้งที่ระดับสิทธิ์ที่มันถือครองสูงกว่าเซิร์ฟเวอร์เว็บทั่วไปมาก ช่องโหว่นี้จึงเป็นเครื่องเตือนว่าระบบ CI/CD ควรถูกจัดชั้นความสำคัญเทียบเท่าระบบที่ควบคุมสิทธิ์ระดับสูง

คำแนะนำ

อัปเดต TeamCity เวอร์ชันติดตั้งเองเป็นเวอร์ชันที่ได้รับแพตช์แล้วทันที และอย่ารอให้ JetBrains ยืนยันสถานะการถูกโจมตี เพราะการที่ CISA กำหนดเส้นตายไว้เพียงไม่กี่วันสะท้อนว่ามีหลักฐานการโจมตีจริงอยู่แล้ว

จำกัดการเข้าถึงเซิร์ฟเวอร์ TeamCity ไม่ให้เปิดสู่อินเทอร์เน็ตโดยตรง โดยเฉพาะพอร์ตที่ให้บริการ agent polling ควรอนุญาตเฉพาะช่วงที่อยู่ไอพีของ build agent ที่รู้จัก หรือให้เชื่อมผ่าน VPN เท่านั้น มาตรการนี้ไม่ได้แก้ช่องโหว่แต่ตัดผู้โจมตีจากภายนอกออกได้ทันทีระหว่างรอแพตช์

ทบทวนสิทธิ์ของบัญชีระบบปฏิบัติการที่รันโปรเซส TeamCity เพราะขอบเขตความเสียหายผูกกับสิทธิ์นั้นโดยตรง ควรใช้บัญชีเฉพาะที่มีสิทธิ์ต่ำที่สุดเท่าที่ทำงานได้ ไม่รันด้วย root หรือ Administrator

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

แหล่งอ้างอิง