สรุปสั้น
นักวิจัยจากบริษัท Novee Security เปิดเผยช่องโหว่ระบบ CI/CD (ระบบสร้างและส่งมอบซอฟต์แวร์อัตโนมัติ) รูปแบบใหม่ที่ตั้งชื่อว่า Cordyceps เมื่อเดือนมิถุนายน 2569 โดยหลังจากสแกน repository (คลังเก็บซอร์สโค้ด) ที่มีผลกระทบสูงราว 30,000 แห่งบนระบบนิเวศ npm, PyPI, crates.io และ Go นักวิจัยพบว่ามีความเสี่ยง 654 แห่ง และยืนยันว่าโจมตีได้จริงกว่า 300 แห่ง จุดที่น่ากังวลคือช่องโหว่นี้ไม่ได้อยู่ในไฟล์ใดไฟล์หนึ่ง แต่เกิดจากวิธีที่ workflow (ขั้นตอนงานอัตโนมัติ) ของ GitHub Actions หลายตัวเชื่อมต่อกัน ทำให้เครื่องมือสแกนความปลอดภัยแบบ SAST/DAST ที่ตรวจทีละไฟล์มองไม่เห็น เพราะทุกไฟล์เป็น YAML ที่ถูกต้องสมบูรณ์ ทำงานตามที่สั่งทุกประการ
โครงการที่ได้รับผลกระทบครอบคลุมเครื่องมือ build ที่เผยแพร่โดยบริษัท Microsoft, Google, Apache, Cloudflare และมูลนิธิ Python Software Foundation ขณะที่เงื่อนไขเดียวที่ผู้โจมตีต้องมีคือบัญชี GitHub แบบฟรี ไม่ต้องเป็นสมาชิกองค์กรและไม่ต้องมีสิทธิ์พิเศษใดๆ ทุก pipeline ที่ถูกโจมตีได้แสดงผลเป็นสีเขียว (ผ่านการตรวจ) ตลอดเวลาที่ความเสี่ยงดำรงอยู่ เพราะตัวสแกนเนอร์ไม่เคยถูกออกแบบมาให้เห็นภัยชนิดนี้ ทั้งนี้ Novee ยังไม่พบหลักฐานการโจมตีจริงในวงกว้าง และผู้ผลิตที่ถูกระบุชื่อได้ปิดช่องโหว่ในระบบตนแล้ว แต่นักวิจัยเตือนว่านี่เป็นรูปแบบที่พิสูจน์แล้วว่าโจมตีได้จริง และยังไม่ถูกแก้เป็นค่าเริ่มต้นในอุตสาหกรรมส่วนใหญ่
รายละเอียดข่าว
เว็บไซต์ BleepingComputer รายงานเมื่อวันที่ 7 กรกฎาคม 2569 อ้างอิงการเปิดเผยของบริษัท Novee Security ผ่านบทวิเคราะห์ของนาย Shane Warden สถาปนิกหลักของบริษัท ActiveState ว่าปัญหาไม่ได้อยู่ที่บรรทัดโค้ดใดโค้ดหนึ่ง แต่อยู่ที่ “องค์ประกอบ” (composition) ของการต่อ workflow เข้าด้วยกัน
โดยปกติ workflow ของ GitHub Actions จะถูกกระตุ้นด้วยเหตุการณ์ pull_request ซึ่งรันในบริบทที่ไม่น่าเชื่อถือของ fork คือไม่มี secret ของ repository และได้ token แบบอ่านอย่างเดียว แต่ปัญหาเริ่มต้นที่ pull_request_target และ workflow_run ซึ่งรันในบริบทของ repository หลัก มีสิทธิ์เข้าถึง secret และได้ GITHUB_TOKEN แบบอ่านและเขียน ผู้โจมตีสามารถหลอกให้ทั้งสองทำงานกับเนื้อหาที่ผู้โจมตีควบคุมได้จาก pull request ที่กระตุ้นมัน ซึ่งทีม GitHub Security Lab เรียกเทคนิคนี้ว่า “pwn request”
มีสามกลไกหลักที่ก่อความเสียหาย กลไกแรกคือ command injection ที่นำข้อมูลของผู้โจมตี เช่น ชื่อ branch, หัวข้อ หรือคอมเมนต์ ไปแทรกตรงๆ ใน run step จนหลุดเข้าไปทำงานในคำสั่ง shell กลไกที่สองคือ code injection ผ่าน actions/github-script ที่ประเมินอินพุตของผู้โจมตีเป็นโค้ด JavaScript ขณะรัน และกลไกที่สามคือ cross-workflow privilege escalation ที่ปล่อยให้ workflow สิทธิ์ต่ำเขียนข้อมูลไม่น่าเชื่อถือลง artifact หรือ output แล้ว workflow สิทธิ์สูงตัวที่สองอ่านและนำไปทำงานด้วย token ของผู้ดูแล จุดสำคัญคือ workflow แต่ละตัวเมื่อแยกกันจะไม่สามารถถูกโจมตีได้ ช่องโหว่เกิดจากวิธีที่มันเชื่อมต่อกันเท่านั้น ซึ่งเป็นเหตุผลว่าทำไมสแกนเนอร์จึงขึ้นสีเขียว เพราะไม่มีบรรทัดใดผิด
รายละเอียดช่องโหว่
Novee สาธิตบน repository ของ Azure Sentinel ของบริษัท Microsoft ว่าเพียงคอมเมนต์บน pull request ก็สามารถรันโค้ดของผู้โจมตีแบบไม่ระบุตัวตนบนระบบ CI ของ Microsoft และขโมยกุญแจ GitHub App แบบไม่หมดอายุได้ ซึ่งได้รับการยืนยันจากศูนย์ Microsoft Security Response Center เนื่องจาก Sentinel เป็นระบบ SIEM ของ Microsoft และส่วน Content Hub ของมันส่ง detection rules กับ playbook อัตโนมัติเข้าไปยัง workspace ของลูกค้าโดยตรง กุญแจที่ถูกขโมยจึงให้สิทธิ์เขียนถาวรต่อเนื้อหาความปลอดภัยที่องค์กรหลายพันแห่งพึ่งพา และสามารถแอบบั่นทอนแล้วส่งต่อเป็นอัปเดตที่ดูน่าเชื่อถือได้
repository ตัวอย่างของ Google AI Agent Development Kit ซึ่งเป็นแหล่งอ้างอิงที่นักพัฒนาหลายพันคนคัดลอกไปใช้สร้าง agent บน Google Cloud ก็พบว่า pull request เดียวสามารถรันโค้ดบน CI ของ Google และยกระดับสิทธิ์เป็น roles/owner บนโปรเจกต์ Google Cloud ที่เกี่ยวข้อง คือได้สิทธิ์เจ้าของแบบถาวร ซึ่ง Google ยืนยันแล้ว ส่วนโครงการ Apache Doris ก็มีเส้นทางขโมย credential คล้ายกัน ซึ่งทีม Apache Security Team ยืนยันและแก้ไขแล้ว
นาย Warden ชี้ว่าความเสี่ยงนี้สะสมทีละคอมมิตที่ดูสมเหตุสมผล โดยไม่มีใครตัดสินใจไว้ใจ pull request นั้นอย่างตั้งใจ และปัญหายิ่งทวีคูณจากการใช้ AI สร้าง workflow อัตโนมัติ เพราะเครื่องมือ AI ผลิต config ของ CI/CD ได้เร็วและทำซ้ำรูปแบบที่ไม่ปลอดภัยเหมือนเดิม ทำให้ความผิดพลาดหนึ่งจุดขยายผลข้าม repository นับล้านแห่ง นอกจากนี้ Cordyceps ไม่ใช่ CVE จึงไม่เข้าสู่ระบบจัดทำหมายเลขช่องโหว่ และ NIST เองก็ยอมรับเมื่อเดือนเมษายน 2569 ว่าไม่สามารถ enrich ทุก CVE ได้อีกต่อไป หลังยอดส่ง CVE เพิ่มขึ้น 263% นับจากปี 2020
ผลกระทบต่อไทย
องค์กรและนักพัฒนาในไทยที่ใช้ GitHub Actions สำหรับระบบ CI/CD โดยเฉพาะทีมที่รับ pull request จากภายนอกหรือเป็นโครงการโอเพนซอร์ส มีความเสี่ยงโดยตรง เพราะการโจมตีนี้ไม่ต้องอาศัยช่องโหว่ซอฟต์แวร์ แต่อาศัยการตั้งค่า workflow ที่ผิดพลาดซึ่งพบได้ทั่วไป ที่น่ากังวลกว่าคือหลายองค์กรไทยพึ่งพาเครื่องมือความปลอดภัยด้านซอฟต์แวร์ที่ส่งอัปเดตผ่าน pipeline เหล่านี้ หากผู้ผลิตต้นน้ำถูกเจาะและมีการฝังโค้ดร้ายในอัปเดต ผู้ใช้ปลายทางในไทยก็อาจได้รับผลกระทบแบบ supply chain โดยไม่รู้ตัว นอกจากนี้แนวโน้มการใช้ AI ช่วยเขียนโค้ดและ config ที่กำลังแพร่หลายในไทย ยิ่งเพิ่มโอกาสที่รูปแบบการตั้งค่าที่ไม่ปลอดภัยจะถูกทำซ้ำในวงกว้าง
คำแนะนำ
ผู้ดูแลระบบและทีมพัฒนาควรดำเนินการแก้ไขเฉพาะหน้าทันที ได้แก่ เลือกใช้ pull_request แทน pull_request_target สำหรับ contribution ที่ไม่น่าเชื่อถือ, ห้าม checkout โค้ดจาก head ของ pull request ภายใน workflow ที่มีสิทธิ์สูง, ส่งข้อมูลเหตุการณ์ผ่านตัวแปร env ที่ใส่เครื่องหมายคำพูดแทนการแทรกตรงๆ, ตั้งค่าสิทธิ์เริ่มต้นเป็นอ่านอย่างเดียว, ตรึง (pin) third-party action ไว้ที่ commit SHA แทนการอ้าง tag ที่ขยับได้ และตั้งให้ workflow สิทธิ์สูงต้องผ่านการอนุมัติด้วยมือสำหรับผู้ contribute ครั้งแรก จากนั้นควรกำกับดูแลสิ่งที่เข้าสู่กระบวนการ build ตั้งแต่ต้นทาง ไม่ใช่เพียงตรวจสิ่งที่ผ่านสแกนเนอร์เท่านั้น