เครื่องมือแก้ไขโค้ดของ Cursor ยังคงรันไฟล์ git.exe ที่เป็นอันตรายซึ่งถูกวางไว้ในโฟลเดอร์โปรเจกต์ ซึ่งเป็นช่องโหว่ zero-day ที่ร้ายแรงและยังไม่ได้รับการแก้ไขมานานถึงเจ็ดเดือน บั๊กนี้ทำให้ไฟล์ executable ใดๆ ที่ปลอมแปลงเป็น Git สามารถทำงานได้โดยอัตโนมัติด้วยสิทธิ์ของผู้ใช้ ทำให้เหล่านักพัฒนาเสี่ยงต่อการถูกรันโค้ดจากระยะไกล (remote code execution) โดยไม่ต้องคลิกหรือมีการแจ้งเตือนใดๆ

ช่องโหว่นี้ถูกค้นพบโดยนักวิจัยด้านความปลอดภัย Mindgard เมื่อวันที่ 15 ธันวาคม 2025 และได้รายงานในวันเดียวกัน แต่ยังคงปรากฏอยู่ในเวอร์ชันเดือนกรกฎาคม 2026 แม้ว่าจะมีการอัปเดตย่อยไปแล้วมากกว่า 197 ครั้ง และบริษัทมีมูลค่าสูงถึง 6 หมื่นล้านดอลลาร์ก็ตาม

กลไกการทำงานของบั๊ก

Cursor จะสแกนไดเรกทอรีของโปรเจกต์เพื่อหาไฟล์ไบนารีของ Git ในหลายตำแหน่ง รวมถึงที่ root ของ repository เมื่อพบไฟล์ที่ชื่อว่า git.exe โปรแกรมจะรันไฟล์นั้นทันทีเพื่อใช้งานฟีเจอร์การควบคุมเวอร์ชัน (version-control) การรันนี้เกิดขึ้นอย่างเงียบเชียบโดยไม่มีหน้าต่าง UI แจ้งเตือน และจะได้รับสิทธิ์ (permissions) ตามผู้ใช้ปัจจุบันที่ใช้งานอยู่

ผู้โจมตีที่สามารถเพิ่มไฟล์ลงใน repository ได้ จะสามารถแทนที่ไฟล์ไบนารี Git ที่ควรจะเป็นด้วยไฟล์ executable ใดๆ ก็ได้ Mindgard ได้สาธิตผลกระทบโดยการเปลี่ยนชื่อโปรแกรม Windows Calculator เป็น git.exe แล้วนำไปวางไว้ใน repo จากนั้นจึงเปิดโฟลเดอร์นั้นด้วย Cursor ผลปรากฏว่าหน้าต่างเครื่องคิดเลขเด้งขึ้นมาซ้ำๆ ตราบเท่าที่โปรเจกต์ยังเปิดอยู่ ซึ่งเป็นการแสดงให้เห็นว่ามัลแวร์ของจริงสามารถทำงานในลักษณะเดียวกันนี้ได้อย่างไร

ลำดับเหตุการณ์การเปิดเผยข้อมูล

  • 15 ธ.ค. 2025 – Mindgard ส่งอีเมลรายงานฉบับเต็มไปยังที่อยู่อีเมลด้านความปลอดภัยของ Cursor
  • 15 ม.ค. 2026 – ประธานเจ้าหน้าที่ฝ่ายความปลอดภัยสารสนเทศ (CISO) ของ Cursor ตอบกลับในหนึ่งเดือนต่อมา
  • 16 ม.ค. 2026 – HackerOne ซึ่งเป็นแพลตฟอร์ม bug-bounty ที่ Cursor ใช้งาน จัดประเภทรายงานว่าอยู่นอกขอบเขต (out of scope)
  • 16 ม.ค. 2026 – Mindgard ส่ง proof-of-concept ให้ดู ส่งผลให้ HackerOne ยอมเปิดตั๋ว (ticket) อีกครั้ง
  • 20 ม.ค. 2026 – HackerOne ยืนยันว่า Cursor ได้รับรายงานอย่างเป็นทางการแล้ว

หลังจากวันที่ 20 มกราคม ข้อความติดตามผลจาก Mindgard ไม่ได้รับการตอบกลับใดๆ Cursor ยังคงปล่อยฟีเจอร์ใหม่ๆ และระดมทุนเพิ่มเติมต่อไป แต่ช่องโหว่นี้ยังคงค้างอยู่ใน codebase

ทำไมความล่าช้านี้จึงเป็นเรื่องที่น่ากังวล

ปัญหานี้คือความเสี่ยงด้านห่วงโซ่อุปทาน (supply-chain risk) แบบคลาสสิก: ผู้ร่วมพัฒนา (contributor) คนใดก็ตามที่สามารถ push ไฟล์ลงใน repository ที่ใช้ร่วมกันได้ จะสามารถฝังโค้ดที่เป็นอันตรายซึ่งจะไปรันบนเครื่องของนักพัฒนาทุกคนได้

ขั้นตอนการบรรเทาความเสี่ยงที่คุณสามารถทำได้ทันที

สภาพแวดล้อม Windows ระดับองค์กร

  • ติดตั้งนโยบาย AppLocker หรือ Windows App Control เพื่อบล็อกไม่ให้ไฟล์ executable ใดๆ ที่ชื่อ git.exe ทำงานภายในไดเรกทอรีของ workspace
  • หลีกเลี่ยงการใช้ allowlist แบบอิงตามค่า hash เนื่องจากผู้โจมตีสามารถเปลี่ยนค่า hash ของไฟล์ได้ง่ายๆ ในขณะที่ยังคงชื่อเดิมไว้

นักพัฒนาทั่วไป

  • เปิด repository จากแหล่งที่ไม่น่าเชื่อถือภายใน virtual machine หรือ Windows Sandbox เท่านั้น
  • อย่าพึ่งพา blocklist ที่อิงตามค่า hash ของไฟล์ เพราะจะทำให้เกิดความรู้สึกปลอดภัยที่ผิดพลาด (false sense of security)

แนวทางปฏิบัติที่ดีที่สุดทั่วไป

  • มองว่าทุก repository ใหม่เป็นช่องทางที่อาจเกิดความเสี่ยงด้านห่วงโซ่อุปทาน (supply-chain vector) ตรวจสอบแหล่งที่มา (provenance) ของไฟล์ไบนารีทั้งหมดก่อนที่จะมีการรัน

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