สรุปสั้น
นักวิจัยจากบริษัท Mindgard เปิดเผยช่องโหว่ในโปรแกรมแก้ไขโค้ดด้วย AI ชื่อ Cursor บนระบบ Windows โดยเพียงแค่เปิดโปรเจกต์ที่มีไฟล์ชื่อ git.exe วางอยู่ใน root ของโปรเจกต์ Cursor ก็จะรันไฟล์นั้นทันที ไม่มีการคลิก ไม่มีกล่องขออนุมัติ และไม่มีคำเตือนใดๆ ว่ากำลังจะมีอะไรทำงาน ไม่ว่าไบนารีนั้นจะทำอะไร มันก็ทำในสิทธิ์ของผู้ใช้ เข้าถึงซอร์สโค้ด คีย์ SSH และโทเคนคลาวด์ของเหยื่อได้ทั้งหมด และ Cursor จะรันไฟล์นั้นซ้ำไปเรื่อยๆ ตราบเท่าที่โปรเจกต์ยังเปิดอยู่ จุดที่อันตรายคือการโจมตีนี้ไม่ต้องอาศัย Prompt Injection ไม่ต้องมี AI Agent ไม่ต้องมีโมเดลเข้ามาเกี่ยว และไม่ต้องเข้าถึงเครื่องมาก่อน เพียงแค่เปิดโฟลเดอร์ก็คือการโจมตีทั้งหมด ผลลัพธ์คือการรันโค้ดตามอำเภอใจในสิทธิ์ของผู้ใช้ที่ล็อกอินอยู่
บริษัท Mindgard รายงานช่องโหว่นี้ต่อ Cursor ตั้งแต่วันที่ 15 ธันวาคม 2568 และเผยแพร่รายละเอียดทางเทคนิคทั้งหมดในวันอังคาร ซึ่งเป็นเวลา 7 เดือนต่อมา แต่จนถึงขณะนี้ยังไม่มีแพตช์ และ Cursor ก็ยังไม่ได้ออกประกาศแจ้งเตือนเกี่ยวกับปัญหานี้ เงื่อนไขที่ฟังดูเหมือนเป็นเรื่องยากคือการที่ไบนารีของผู้โจมตีต้องมาอยู่ใน root ของโปรเจกต์ แต่แท้จริงแล้วไม่ยากเลย เพราะการโคลน repository ของคนแปลกหน้าคือวิธีที่ไบนารีมาอยู่บนดิสก์ตั้งแต่แรก ซึ่งนักพัฒนาและ AI Agent ทำกันตลอดทั้งวัน ผู้โจมตีจึงไม่ต้องมีจุดตั้งต้นในเครื่องเลย
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 15 กรกฎาคม 2569 ว่ากลไกของช่องโหว่นี้อธิบายได้สั้นๆ คือ Cursor จะตรวจหาไบนารีของ Git ในหลายตำแหน่งเมื่อโหลดโปรเจกต์ และหนึ่งในตำแหน่งเหล่านั้นคือพื้นที่ทำงาน (Workspace) เอง ผลลัพธ์จาก Process Monitor ในรายงานแสดงให้เห็นว่า Cursor.exe เรียกไบนารีที่อยู่ใน root ของ repository ด้วยบรรทัดคำสั่ง git rev-parse –show-toplevel ซึ่งเป็นการตรวจหา root ของ repository แบบเดียวกับที่เอกสารของ VS Code ของ Microsoft อธิบายไว้ ตัวอย่างการโจมตี (Proof of Concept) ของ Mindgard ใช้โปรแกรมเครื่องคิดเลขของ Windows ที่เปลี่ยนชื่อเป็น git.exe แล้ว commit ลงใน root เพียงโคลน เปิด ก็เสร็จ ภาพหน้าจอแสดงให้เห็นหน้าต่างเครื่องคิดเลขเด้งขึ้นมาเรื่อยๆ เองในขณะที่โปรเจกต์ยังเปิดค้างอยู่
ข้อจำกัดหนึ่งของหลักฐานคือการยืนยันล่าสุดที่มีวันที่กำกับของ Mindgard คือวันที่ 30 เมษายน 2569 ทดสอบกับ Cursor เวอร์ชัน 3.2.16 ขณะที่เวอร์ชันปัจจุบันคือ 3.11 ที่ปล่อยเมื่อวันที่ 10 กรกฎาคม รายงานระบุว่าช่องโหว่ยังคงอยู่ในเวอร์ชันล่าสุดที่ทดสอบ แต่ไม่ได้ระบุชื่อเวอร์ชันนั้น ทั้งนี้ The Hacker News ได้ตรวจสอบประกาศความปลอดภัยทั้ง 33 ฉบับที่ Cursor เผยแพร่แล้วไม่พบรายการที่ครอบคลุมปัญหานี้ ณ วันที่ 15 กรกฎาคม และยังไม่มีการกำหนดหมายเลข CVE ให้ช่องโหว่นี้
เรื่องราวอีกด้านคือการตอบสนองต่อรายงาน หน้าเว็บด้านความปลอดภัยของ Cursor ระบุว่าบริษัทจะ “รับทราบรายงานช่องโหว่ภายใน 5 วันทำการ” แต่คำตอบที่มีเนื้อหาจริงครั้งแรกจาก Cursor มาถึง 1 เดือนหลังจากรายงานในเดือนธันวาคม โดยประธานเจ้าหน้าที่ความปลอดภัย (CISO) ของ Cursor อธิบายว่าระบบอัตโนมัติล้มเหลวในการเชิญบริษัทเข้าโครงการ HackerOne แบบส่วนตัว รายงานที่ส่งใหม่ถูกปิดในวันถัดมาโดยระบุว่าเป็นเพียงข้อมูลและอยู่นอกขอบเขต จากนั้นถูกเปิดใหม่เมื่อ Mindgard โต้แย้ง และ HackerOne ก็ทำซ้ำได้สำเร็จ หลังจากนั้นมีการขออัปเดตในเดือนกุมภาพันธ์ มีนาคม และเมษายน แต่ไม่มีคำตอบกลับมา จน Mindgard ตัดสินใจใช้การเปิดเผยแบบเต็มรูปแบบ (Full Disclosure) ซึ่งนาย Aaron Portnoy ผู้เขียนรายงานเรียกว่าเป็น “ทางเลือกสุดท้าย” ที่สงวนไว้สำหรับกรณีที่ทุกช่องทางอื่นล้มเหลว
รายละเอียดช่องโหว่
ต้นตอของช่องโหว่นี้คือปัญหาเส้นทางค้นหาที่ไม่น่าเชื่อถือ (Untrusted Search Path) กล่าวคือบน Windows โปรแกรมหลายตัวจะค้นหาไฟล์ช่วยเหลืออย่าง git.exe ตามลำดับการค้นหาเริ่มต้น ซึ่งจะตรวจไดเรกทอรีที่ทำงานอยู่ก่อนเส้นทางระบบที่เชื่อถือได้ การวางไบนารีไว้ในตำแหน่งที่การค้นหาจะเจอก่อนจึงเป็นการโจมตี Mindgard ไม่ใช่บริษัทแรกที่พบปัญหาคลาสนี้ ในเดือนมิถุนายน บริษัท Cymulate ได้เผยแพร่ผลการค้นพบปัญหาคลาสเดียวกันในเครื่องมือ AI หลายตัว โดย GitHub Copilot CLI รัน git.exe ในพื้นที่ทำงานตั้งแต่ตอนเริ่มต้นก่อนแสดงหน้าต่างขอความเชื่อถือโฟลเดอร์เสียอีก ส่วน Gemini CLI ก็ทำเช่นเดียวกันเมื่อเปิดจากพื้นที่ทำงาน และแอป Codex เดสก์ท็อปก็รันตอนเปิดโฟลเดอร์เหมือน Cursor
ที่น่าสนใจคือช่องโหว่คลาสนี้มีมานานแล้ว การที่ Windows ตรวจไดเรกทอรีปัจจุบันก่อน %PATH% เคยทำให้ Git Credential Manager Core มีช่องโหว่ในปี 2563 (CVE-2020-26233) จากการวาง git.exe อันตรายไว้ที่ root ของ repository แล้วถูกรันแทนตัวจริงระหว่างการโคลนแบบ recursive ซึ่งตัวอย่างการโจมตีในตอนนั้นก็ใช้เครื่องคิดเลขที่เปลี่ยนชื่อเป็น git.exe เช่นกัน หกปีผ่านไป เทคนิคเดิมกลับมาใช้ได้กับ IDE ที่รันการตรวจหาให้อัตโนมัติทันทีที่เปิดโฟลเดอร์ จนถึงตอนนี้มีผู้ผลิต 4 รายที่ถูกแสดงให้เห็นว่าไบนารีในพื้นที่ทำงานรันตัวเองได้ทันทีที่นักพัฒนาชี้เครื่องมือไปที่ repository ที่โคลนมา แต่สองรายตัดสินว่าไม่ใช่ช่องโหว่ และอีกสองรายยอมรับว่าใช่แต่ยังไม่ได้ปล่อยแพตช์
ผลกระทบต่อไทย
นักพัฒนาซอฟต์แวร์ในไทยที่ใช้เครื่องมือ AI ช่วยเขียนโค้ดอย่าง Cursor, GitHub Copilot CLI, Gemini CLI หรือ Codex บน Windows มีความเสี่ยงโดยตรง เพราะพฤติกรรมการโคลน repository จากแหล่งสาธารณะเพื่อทดลองหรือศึกษาโค้ดเป็นเรื่องปกติในงานพัฒนา หากโคลน repository ที่มีไฟล์ git.exe อันตรายฝังไว้แล้วเปิดด้วย Cursor ก็เท่ากับรันโค้ดอันตรายในสิทธิ์ของผู้ใช้ทันที ซึ่งอาจนำไปสู่การขโมยคีย์ SSH โทเคนคลาวด์ และซอร์สโค้ดของทั้งโปรเจกต์และองค์กร ยิ่งไปกว่านั้นเครื่องนักพัฒนามักมีสิทธิ์เข้าถึงระบบ CI/CD และคลาวด์ขององค์กร ทำให้การเจาะเครื่องเดียวอาจลุกลามไปทั้งระบบได้ เนื่องจากช่องโหว่นี้ยังไม่มีแพตช์ ทีมพัฒนาไทยจึงต้องพึ่งพาการป้องกันด้วยตนเองเป็นหลัก
คำแนะนำ
เนื่องจากยังไม่มีแพตช์ ทุกทางเลือกจึงเป็นวิธีแก้ชั่วคราว สำหรับเครื่อง Windows ที่บริหารจัดการแบบรวมศูนย์ Mindgard แนะนำให้ใช้กฎ AppLocker หรือ Windows App Control เพื่อบล็อกไฟล์ปฏิบัติการตามชื่อและเส้นทางภายใต้ root ของพื้นที่ทำงาน เช่น รูปแบบ %USERPROFILE%\source\repos*\filename.exe โดยควรใช้กฎแบบอิงเส้นทาง (Path Rule) ไม่ใช่อิงค่าแฮช เพราะไบนารีของผู้โจมตีมีแฮชต่างกันไป สำหรับผู้ใช้ทั่วไปควรเปิด repository ที่ไม่น่าเชื่อถือในเครื่องเสมือน (VM) แบบใช้แล้วทิ้งหรือ Windows Sandbox นอกจากนี้ควรทำตามคำแนะนำของ Cymulate ในการตรวจสอบ repository ที่โคลนมาหรือ archive ที่แตกออกก่อนเปิด เพราะไฟล์อย่าง git.exe, npx.exe, node.exe และ where.exe ไม่ควรปรากฏอยู่ใน root ของโปรเจกต์ โดยหลักการสำคัญคือให้ถือว่า repository ที่โคลนมาเป็นเนื้อหาที่รันได้ (Executable Content) เพราะแท้จริงแล้วมันเป็นเช่นนั้น