Zero-day ของ Cursor: เหตุใดการเปิดเผยทั้งหมดจึงกลายเป็นมาตรการป้องกันเดียวที่เหลืออยู่

 (mindgard.ai)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cursor สำหรับ Windows จะรัน git.exe ในรากของ workspace โดยอัตโนมัติเมื่อเปิดโปรเจกต์ ทำให้เพียงเปิด repository ที่มีไบนารีมุ่งร้ายก็อาจเกิดการ รันโค้ดใดก็ได้โดยไม่ต้องมีปฏิสัมพันธ์จากผู้ใช้
  • ขอบเขตการค้นหาเส้นทาง Git รวมถึงภายใน repository และไม่เพียงรันไฟล์โดยไม่มีคำเตือนหรือการอนุมัติเท่านั้น แต่ยัง รันซ้ำเป็นระยะ ระหว่างที่โปรเจกต์เปิดอยู่
  • Mindgard รายงานเมื่อวันที่ 15 ธันวาคม 2025 และส่งต่อพร้อมการ reproduce ผ่าน HackerOne แล้ว แต่แม้จะผ่านไปกว่า 6 เดือนและมี เวอร์ชันใหม่มากกว่า 197 เวอร์ชัน ปัญหาก็ยังคงอยู่ในเวอร์ชันทดสอบล่าสุด
  • สภาพแวดล้อม Windows แบบมีการจัดการควรใช้ กฎปฏิเสธตามเส้นทาง ของ AppLocker หรือ Windows App Control และผู้ใช้ทั่วไปควรเปิด repository ที่ไม่น่าเชื่อถือใน VM หรือ Windows Sandbox จนกว่าจะมีแพตช์
  • Mindgard เห็นว่ากระบวนการเปิดเผยแบบประสานงานไม่สามารถลดความเสี่ยงของผู้ใช้ได้ จึงเปิดเผยรายละเอียดทั้งหมด และเมื่อเลือกเครื่องมือพัฒนา AI ก็ควรใช้ ความสามารถในการตอบสนองและสื่อสารด้านความปลอดภัย ของผู้ให้บริการเป็นเกณฑ์ความน่าเชื่อถือด้วย

git.exe ที่ถูกเรียกใช้เพียงแค่เปิด repository

  • Cursor ค้นหาไบนารี Git จากหลายตำแหน่งเมื่อโหลดโปรเจกต์ และเป้าหมายการค้นหารวมถึง workspace ปัจจุบัน ด้วย
  • หากผู้โจมตีวาง git.exe ที่เป็นอันตรายไว้ที่รากของ repository Cursor จะรันโดยอัตโนมัติ โดยไม่มีคำเตือน กล่องโต้ตอบขออนุมัติ หรือการคลิกเพิ่มเติม
  • การโจมตีเริ่มขึ้นเพียงนักพัฒนาเปิดโปรเจกต์นั้น โดยไม่ต้องใช้ prompt injection, การบิดเบือนโมเดล, jailbreak, memory corruption หรือ exploit chain ที่ซับซ้อน
  • โค้ดที่ถูกเรียกใช้จะทำงานภายใน ขอบเขตสิทธิ์ ของผู้ใช้ Cursor ปัจจุบัน

ขั้นตอนการ reproduce และบันทึกการรันซ้ำ

  • เพื่อทำ proof of concept ที่ปลอดภัย Mindgard เปลี่ยนชื่อ Windows Calculator เป็น git.exe และวางไว้ที่รากของ repository
  • เมื่อเปิด repository ใน Cursor Calculator ก็ถูกเรียกขึ้นมา และเมื่อเปิดโปรเจกต์ค้างไว้ ก็มีหน้าต่างเพิ่มขึ้นอีกหลายหน้าต่าง
    • ไม่ใช่กรณีที่นักวิจัยเปิดหลายหน้าต่างด้วยตนเอง
    • แต่เป็นผลจากการ รันไฟล์ปฏิบัติการใน workspace ซ้ำเป็นระยะ ระหว่างการใช้งานปกติ ไม่ใช่พฤติกรรมตอนเริ่มต้นเพียงครั้งเดียว
  • ในการโจมตีจริง ผู้โจมตีสามารถวางโค้ดที่ตนควบคุมแทน Calculator ได้
  • บันทึกของ Sysinternals Process Monitor แสดงว่า Cursor.exe เรียกใช้ git.exe ภายใน repository พร้อมส่งคำสั่งต่อไปนี้
git rev-parse --show-toplevel
  • การตรวจสอบครั้งสุดท้ายทำเมื่อ 30 เมษายน 2026 บน Cursor 3.2.16 สำหรับ Windows

ช่องโหว่ที่ยังคงอยู่ในฐานผู้ใช้ขนาดใหญ่

  • Cursor เป็นสภาพแวดล้อมพัฒนาที่มี AI ช่วย ซึ่งถูกใช้งานในระดับต่อไปนี้
    • ผู้ใช้ active มากกว่า 7 ล้านคน
    • ผู้ใช้รายวันมากกว่า 1 ล้านคน
    • ผู้ใช้แบบชำระเงินมากกว่า 1 ล้านคน
    • บริษัทที่ใช้งานมากกว่า 50,000 แห่ง
  • มูลค่าตลาดที่มีรายงานอยู่ที่ 60,000 ล้านดอลลาร์
  • Mindgard พบช่องโหว่เมื่อวันที่ 15 ธันวาคม 2025 และรายงานในวันเดียวกัน
  • ตามเกณฑ์ที่กล่าวไว้ตอนต้น แม้จะผ่านไปกว่า 6 เดือนและมี เวอร์ชันใหม่มากกว่า 197 เวอร์ชัน ช่องโหว่ก็ยังอยู่ในเวอร์ชันทดสอบล่าสุด
  • เนื้อหาที่กล่าวถึงความคืบหน้าการตอบสนองระบุว่า ระหว่างที่มีการเพิ่มฟีเจอร์และประกาศต่าง ๆ มีการออก มากกว่า 70 เวอร์ชัน แต่ปัญหายังคงอยู่
  • ช่องโหว่รันโค้ดใดก็ได้ที่เรียบง่ายและ reproduce ได้ง่ายไม่ได้รับการแก้ไขเป็นเวลาหลายเดือน ส่งผลกระทบต่อทั้งบุคคลและองค์กรที่ deploy Cursor

มาตรการชั่วคราวที่ใช้ได้ก่อนมีแพตช์

  • บนระบบ Windows แบบมีการจัดการ สามารถใช้นโยบาย AppLocker หรือ Windows App Control เพื่อบล็อกชื่อไฟล์ปฏิบัติการดังกล่าวในไดเรกทอรี workspace สำหรับพัฒนาได้
  • เนื่องจาก hash อาจแตกต่างกันไปในแต่ละไบนารี กฎปฏิเสธตามเส้นทาง ที่จำกัดขอบเขตไว้ที่รากของ repository/workspace จึงเหมาะสมกว่า รายการบล็อกตาม hash
%USERPROFILE%\source\repos\*\filename.exe
  • Windows ไม่มีกฎ built-in ทั่วไปที่บล็อกไฟล์ปฏิบัติการลูกใด ๆ เฉพาะเมื่อถูกเรียกใช้โดย parent process บางตัว
    • การควบคุมที่รับรู้ parent process ต้องใช้ EDR หรือผลิตภัณฑ์ความปลอดภัย endpoint แบบปรับแต่งเอง
  • ผู้ใช้ทั่วไปควรเปิด repository ที่ไม่น่าเชื่อถือเฉพาะใน VM ที่แยกออกมา, Windows Sandbox หรือสภาพแวดล้อมที่ทิ้งได้ จนกว่า IDE จะถูกแพตช์
  • ไม่ควรเชื่อถือรายการบล็อกตาม file hash สำหรับช่องโหว่นี้ เพราะ hash อาจเปลี่ยนได้ทุกครั้งที่เปลี่ยนไบนารี

กระบวนการประสานงานที่หยุดชะงักหลังรายงาน

  • รายงานแรกถูกส่งไปยังอีเมลรายงานความปลอดภัยที่ระบุใน security.txt ของ Cursor แต่ไม่ได้รับการยืนยันว่าได้รับแล้ว
  • Mindgard พยายามหาผู้รับผิดชอบด้านความปลอดภัยที่เหมาะสมผ่านอีเมลติดตามผลและ คำขอติดต่อสาธารณะ
  • CISO ของ Cursor ตอบว่าระบบอัตโนมัติภายในล้มเหลว ทำให้กระบวนการ HackerOne ที่วางไว้ไม่เริ่มต้น และเชิญ Mindgard เข้าร่วมโปรแกรม bug bounty แบบส่วนตัวด้วยตนเอง
  • รายงานที่ส่งซ้ำผ่าน HackerOne ในตอนแรกถูกปิดเป็น Informative และอยู่นอกขอบเขต
    • Mindgard โต้แย้งคำตัดสินนั้น
    • หลังจาก HackerOne reproduce ปัญหาได้ รายงานจึงถูกเปิดใหม่ และยืนยันว่ารายละเอียดถูกส่งต่อให้ Cursor แล้ว
  • หลังจากนั้น แม้จะมีการขออัปเดต การ escalate ผ่าน HackerOne และการติดต่อโดยตรงไปยัง CISO และผู้บริหารของ Cursor ก็ไม่มีคำตอบที่มีความหมาย
  • Mindgard ไม่ได้รับหลักฐานว่าการแก้ไขเริ่มขึ้นแล้ว ทีมวิศวกรรมกำลังตรวจสอบอยู่ หรือความเสี่ยงถูกแจ้งไปยังผู้ใช้ที่ได้รับผลกระทบแล้ว

ไทม์ไลน์ตั้งแต่การรายงานจนถึงการเปิดเผยทั้งหมด

  • 15 ธันวาคม 2025

    • Mindgard พบช่องโหว่
    • รายงานไปที่ security-reports@cursor.com

  • 18 ธันวาคม 2025

    • ส่งการติดต่อเพิ่มเติมเพื่อขอการยืนยันว่าได้รับแล้ว

  • 13 มกราคม 2026

    • โพสต์บน LinkedIn เพื่อหาผู้ติดต่อของ Cursor
    • มีผู้ใช้คนหนึ่งในคอมเมนต์ชี้ไปที่ CISO ของ Cursor

  • 15 มกราคม 2026

    • CISO ของ Cursor แจ้งว่าระบบอัตโนมัติสำหรับคำเชิญ HackerOne private bounty ล้มเหลว และเชิญด้วยตนเอง
    • Mindgard ส่งช่องโหว่ผ่าน HackerOne

  • 16 มกราคม 2026

    • รายงานถูกปิดเป็น Informative และอยู่นอกขอบเขต
    • Mindgard โต้แย้งคำตัดสิน
    • หลังจาก reproduce สำเร็จ รายงานถูกเปิดใหม่

  • 20 มกราคม 2026

    • HackerOne ยืนยันว่าได้ส่งรายงานให้ Cursor แล้ว

  • 16 กุมภาพันธ์, 3 มีนาคม 2026

    • Mindgard ขออัปเดต แต่ไม่ได้รับคำตอบ

  • 17 มีนาคม 2026

    • ขออัปเดตโดยตรงจาก CISO ของ Cursor

  • 18 มีนาคม 2026

    • HackerOne แจ้งว่าได้ติดต่อ Cursor แล้ว

  • 1 เมษายน 2026

    • Mindgard ขออัปเดตอีกครั้ง แต่ไม่ได้รับคำตอบ
    • HackerOne ก็ยืนยันว่าไม่มีอัปเดตจาก Cursor

  • 1 มิถุนายน 2026

    • Mindgard แจ้ง HackerOne ว่าตั้งใจจะเปิดเผยต่อสาธารณะ

  • 3 มิถุนายน 2026

    • HackerOne ให้แนวทางการเปิดเผย

  • 14 กรกฎาคม 2026

    • เผยแพร่โพสต์ที่มีรายละเอียดช่องโหว่

เหตุใดการเปิดเผยแบบประสานงานจึงไม่นำไปสู่การปกป้องผู้ใช้

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

คำถามที่ bug bounty และระบบตอบสนองด้านความปลอดภัยของ AI ทิ้งไว้

  • ตั้งคำถามถึงความเป็นไปได้ต่อไปนี้เกี่ยวกับสาเหตุที่การแก้ไขล่าช้า
    • โปรแกรม bug bounty สมัยใหม่กำลังอยู่ในภาวะ overload หรือไม่
    • โมเดลที่มีความสามารถสูงขึ้นอย่าง Mythos ทำให้รับมือกับปริมาณรายงานได้ยากขึ้นหรือไม่
    • Cursor ลดลำดับความสำคัญของความปลอดภัยผู้ใช้ลงเพราะมุ่งเน้นการเข้าซื้อ SpaceX หรือไม่
    • เมื่อมีเงินหลายพันล้านดอลลาร์เป็นเดิมพัน ความปลอดภัยของผู้ใช้เป็นเรื่องที่สนใจจริงหรือไม่
  • การแพร่หลายของผลิตภัณฑ์ AI ทำให้จำนวนการค้นพบด้านความปลอดภัยเพิ่มขึ้นอย่างมาก และจำนวนมากไม่เข้ากับการจัดประเภทช่องโหว่แบบเดิมอย่างเรียบร้อย
  • กระบวนการจัดประเภทและรับเรื่องที่พึ่งพามาประมาณ 20 ปีกำลังล้มเหลวอย่างรวดเร็วในสภาพแวดล้อม AI เพราะสมมติฐานพื้นฐานถูกสั่นคลอน
  • หาก pipeline การเปิดเผยอยู่ในภาวะ overload อุตสาหกรรมควรเปิดเผยเรื่องนี้อย่างโปร่งใส เพื่อให้นักวิจัย ลูกค้า และผู้ใช้ประเมินสถานการณ์ได้
  • บริษัทที่เติบโตอย่างรวดเร็วควรแก้ไขความล้มเหลวด้านความปลอดภัย พร้อมปฏิบัติต่อผู้ใช้ในฐานะ ลูกค้าที่มีคุณค่า ไม่ใช่เป้าหมายทดลองซื้อ

เงื่อนไขในการเชื่อถือเครื่องมือพัฒนา AI

  • บริษัท AI ขอสิทธิ์เข้าถึงโค้ด repository เทอร์มินัล ข้อมูลลับ และ workflow อย่างกว้างขวางอย่างที่ไม่เคยมีมาก่อน และเส้นแบ่งระหว่างการเสนอแนะกับการลงมือทำก็ยิ่งพร่าเลือนลงเรื่อย ๆ
  • ผู้ใช้มอบ source code, credentials, intellectual property ที่เป็นกรรมสิทธิ์ และฟังก์ชันที่เป็นอัตโนมัติมากขึ้นให้กับซอฟต์แวร์ production
  • ไม่ควรเชื่อถือระบบเพียงเพราะช่วยเพิ่ม productivity แต่ต้องได้รับความไว้วางใจผ่านการตอบสนองต่อรายงานความปลอดภัย การสื่อสารกับผู้ใช้ที่ได้รับผลกระทบ และการจัดลำดับความสำคัญของการแก้ไข
  • ความเชื่อใจต้องมีความรับผิดชอบ และความรับผิดชอบต้องมีการสื่อสาร แต่เมื่อผู้ใช้ นักวิจัย และแพลตฟอร์มเปิดเผยไม่ได้รับแม้แต่อัปเดตสถานะพื้นฐานเป็นเวลาหลายเดือน ก็ยากที่จะยืนยันความรับผิดชอบนั้น
  • Mindgard เปิดเผยรายละเอียดทั้งหมดเพื่อให้องค์กรมีโอกาสประเมินขอบเขตการเปิดรับความเสี่ยง ใช้มาตรการควบคุมเสริม และตัดสินสถานะด้านความปลอดภัย
  • เมื่อการปกปิดข้อมูลต่อไปไม่ได้ปกป้องผู้ใช้ แต่ปกป้องเพียงความเงียบ ถึงแม้จะไม่สบายใจ ก็ต้องให้ความสำคัญกับ ความปลอดภัยของผู้ใช้ ก่อน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ในมุมของคนที่รับรายงานด้านความปลอดภัย ตอนนี้มีรายงานคุณภาพต่ำที่ LLM สร้างขึ้นหลั่งไหลเข้ามาจนแทบรับมือไม่ไหว และส่วนใหญ่มักไม่เข้าใจทั้งการออกแบบผลิตภัณฑ์หรือขอบเขตด้านความปลอดภัย บางครั้งก็มีรายงานที่ดีมากจริง ๆ จึงยังต้องตรวจทุกฉบับด้วยตัวเอง แต่การส่ง “หลักฐาน” ยืดยาวที่ LLM สร้างเพิ่มมาไม่ใช่ทางแก้ และบทความนี้เองก็ดูเหมือนจะเขียนด้วย LLM เป็นส่วนใหญ่
    กรณีนี้เองก็เช่นกัน ถ้าเป็นสถานการณ์ที่วางไบนารีอันตรายไว้ในสภาพแวดล้อมที่ซอฟต์แวร์สามารถรันโค้ดหรือไบนารีใด ๆ ได้อยู่แล้ว ก็ดูจะเป็นความรับผิดชอบฝั่งการแยกและปกป้อง workspace มากกว่า เว้นแต่ Cursor จะบอกว่าจะรับผิดชอบความปลอดภัยของสภาพแวดล้อมผู้ใช้ด้วย
    เวลาใช้ LLM ทำรายงาน CVE ควรใช้ในขั้นตอนการทำให้เกิดซ้ำได้อย่างชี้ขาด ส่วนเนื้อหารายงานควรเขียนเองให้กระชับ และตัดคำขยายกับการพูดเกินจริงแบบที่เป็นลักษณะของ LLM ออก

    • แค่เปิดรีโพที่เพิ่ง clone ใหม่ด้วย Cursor ก็ไม่ควรทำให้ไบนารีข้างในรันอัตโนมัติ
    • ตัวแปร PATH มีไว้เพื่อควบคุมปัญหาแบบนี้โดยตรง ถ้าเข้าใจถูก Cursor กำลังเพิ่มรีโพเข้า PATH ทันทีโดยไม่มีการอนุมัติจากผู้ใช้
    • ไม่มีทางแก้ง่าย ๆ และถ้าให้ความสำคัญกับความปลอดภัย ก็ต้องเพิ่มกำลังคนสำหรับการตรวจทานให้เหมาะกับสภาพแวดล้อมที่เปลี่ยนไป การเอาการตรวจด้วย LLM มาซ้อนอีกชั้นไม่ได้ช่วยแก้ปัญหา

  • รากของปัญหาคือ Cursor ไม่ได้มองการ clone รีโพกับการรันโค้ดว่าเป็นขอบเขตความปลอดภัยคนละชั้นกัน โดยพื้นฐานแล้ว Cursor ปิดใช้งาน Workspace Trust[0] และเพียงแค่เปิดรีโพที่มี "runOn": "folderOpen" อยู่ใน .vscode/tasks.json ก็ทำให้โค้ดใด ๆ ถูกรันได้แล้ว[1]
    [0] https://cursor.com/docs/agent/security#workspace-trust
    [1] https://www.oasis.security/blog/cursor-security-flaw

  • Mindgard ระบุว่าพบช่องโหว่นี้ครั้งแรกเมื่อ15 ธันวาคม 2025 และรายงานในวันนั้นรวมถึงอีกหลายครั้งหลังจากนั้น แต่แม้ผ่านไป 6 เดือนและมีเวอร์ชันใหม่เกิน 197 เวอร์ชันแล้ว ก็ยังคงอยู่ใน Cursor เวอร์ชันล่าสุด
    ตอนแรกเรื่องนี้ถูกปิดไปในฐานะรายงานเชิงข้อมูล/นอกขอบเขต หลังมีการคัดค้าน HackerOne จึงเปิดใหม่ ทำซ้ำได้ และส่งต่อให้ Cursor แต่หลังจากนั้นทั้งคำขออัปเดต คำถามเพิ่มเติม การยกระดับผ่าน HackerOne และแม้แต่การติดต่อผู้บริหารของ Cursor ก็ล้วนไม่ได้รับคำตอบ จึงยากจะเข้าใจว่าเหตุใด Cursor ถึงตอบสนองแบบนี้

    • กระบวนการจัดการ CVE พังไปแล้วทั้งระบบ ด้วยการเติบโตของ AI แบบ agentic ทั้งใน HackerOne และโครงการเปิดเผยช่องโหว่ของบริษัทต่าง ๆ มีทั้งรายงานคุณภาพต่ำและรายงานชั้นยอดเพิ่มขึ้นพร้อมกัน และเพราะ AI ตัวเดียวกันสามารถเขียนได้ทั้งสองแบบ จึงแทบแยกจากผิวเผินไม่ได้เลย
      ผลคือบริษัทต่าง ๆ ไม่ตอบสนองเหมือนเมื่อก่อนอีกต่อไป และในงานประชุมความมั่นคงไซเบอร์เมื่อเดือนมิถุนายน ก็มีบรรยากาศชัดเจนว่าการเปิดเผยอย่างรับผิดชอบนั้นตายไปแล้วหรือกำลังจะตาย ดังนั้นการเปิดเผยต่อสาธารณะอาจดีกว่า มีการอ้างถึง Microsoft และกรณี Nightmare Eclipse บ่อยครั้ง
    • ยังนึกถึงความเป็นไปได้ว่าอาจเป็นแบ็กดอร์โดยเจตนา หาก NSA หรือ FBI ใส่ git.exe ไว้ในรีโพที่เจาะจงเป้าหมาย แล้วทำให้เป้าหมาย clone รีโพนั้น ก็อาจทำให้เพย์โหลดถูกรันได้
      เนื่องจาก Cursor มีพื้นฐานมาจาก VS Code จึงสงสัยว่าใน VS Code เองจะเกิดเรื่องแบบเดียวกันหรือไม่

  • ยังเห็นด้วยได้ไม่เต็มที่ว่านี่เป็นช่องโหว่ร้ายแรง เพราะการนำไปใช้โจมตีจริง ผู้โจมตีต้องใส่ไฟล์รันอันตรายชื่อ git.exe เข้าไปในโฟลเดอร์โค้ดของผู้ใช้ก่อน ซึ่งคล้ายกับการเรียกสิ่งที่แก้ .bashrc ให้ ls ไปเรียก /tmp/mega-big-virus.sh ผ่าน alias ว่าเป็นช่องโหว่
    มันเป็นเส้นทางโจมตีจริงก็จริง แต่ถ้าไฟล์แบบนั้นเข้าไปอยู่ในไฟล์ซิสเต็มแล้ว ก็อาจถือได้ว่าเกิดการเจาะระบบล่วงหน้าไปก่อนแล้ว

    • แค่ clone รีโพจาก GitHub แล้วเปิดด้วย Cursor ซึ่งเป็น editor เริ่มต้น ก็อาจติดเชื้อได้ ซึ่งคล้ายกับการใส่ CD แล้ว autorun.exe ทำงานจน Windows ติดมัลแวร์
      อาจจะเถียงได้ว่าผู้ใช้ควรตรวจไฟล์ทั้งหมดในรีโพและไบนารีน่าสงสัยอย่าง git.exe ด้วยตัวเองในสภาพแวดล้อมแยก แต่ในโลกจริง สิ่งที่ควบคุมเรื่องนี้ไม่ใช่ผู้ใช้ แต่เป็นนโยบายความปลอดภัยที่ห้ามการรันอัตโนมัติ และ Cursor ก็ควรปิดไว้เช่นกัน
    • ไม่เหมือน .bashrc เพราะโฟลเดอร์โค้ดมักมาจากแหล่งที่ไม่น่าเชื่อถือบ่อยครั้ง แค่เปิดโปรเจกต์บน GitHub เพื่อตรวจดูก็ไม่ควรเท่ากับยอมให้เกิดการรันโค้ดตามอำเภอใจ
      อย่างไรก็ตาม ใน IDE หลัก ๆ ขอบเขตนี้พังมานานแล้ว และฟีเจอร์รีโมตอย่าง SSH กับ devcontainer ของ VS Code ก็ยอมให้เกิด remote code execution ตามการออกแบบอยู่แล้ว
    • ตั้งแต่สองประโยคแรกของย่อหน้าแรก หน้าเว็บก็อธิบายไว้ชัดแล้วว่า หลัง Cursor เปิดโปรเจกต์ มันจะค้นหา Git binary จากหลายตำแหน่งรวมถึง workspace ปัจจุบัน และถ้าวาง git.exe อันตรายไว้ที่รากรีโพ มันจะถูกรันโดยไม่ต้องมีการป้อนข้อมูลหรือการยืนยันจากผู้ใช้ บทความนี้ไม่ได้ซ่อนพฤติกรรมหลักไว้
    • แค่ clone รีโพแล้วเปิดใน IDE ก็เท่ากับให้สิทธิ์รันโค้ดจากระยะไกลแก่เจ้าของรีโพ ซึ่งยากจะมองว่าเป็นข้อตกลงโดยนัยที่รวมอยู่ในการเปิดโฟลเดอร์
    • เมื่อ 30 ปีก่อนก็มีการโจมตีตามลำดับการค้นหา DLL ที่ใส่ DLL ปลอมติดมัลแวร์ไว้ในโฟลเดอร์ MP3 หรือรูปภาพ แล้วให้ Winamp หรือ Windows Photo Viewer โหลดขึ้นมา ซึ่งคล้ายกับกรณีนี้มาก

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

    • ถ้ามีหน้าต่างยืนยันขึ้นมาว่า “ต้องการรัน git.exe หรือไม่?” ก็มีโอกาสสูงที่ผู้ใช้จะคิดว่า Cursor จำเป็นต้องใช้ Git และการตั้งค่าสิทธิ์แค่ผิดปกติ จึงกดยอมรับไป
    • ถ้าใช้ PS1 ที่แสดง Git branch ปัจจุบัน และใส่ไดเรกทอรีปัจจุบันไว้ใน PATH ก็อาจเกิดเรื่องเดียวกันได้ ถ้าอย่างนั้นควรส่งรายงานเป็น CVE ระดับความรุนแรงสูง ให้ Bash ด้วยหรือไม่ ก็น่าตั้งคำถาม

  • ดูเหมือนว่านี่จะไม่ใช่บั๊กเฉพาะของ Cursor เท่านั้น แต่เกี่ยวข้องกับ ลำดับการค้นหาแบบเฉพาะของ Windows ที่จะมองหาไฟล์รันได้ในไดเรกทอรีทำงานปัจจุบันก่อนดู PATH จึงมีความเป็นไปได้สูงที่โปรแกรมอื่น ๆ บน Windows จะเปิดช่องให้โจมตีลักษณะคล้ายกันได้

    • ซอฟต์แวร์ที่ให้ความสำคัญกับความปลอดภัยได้แก้ปัญหานี้ไปแล้ว
      ตามที่อธิบายใน https://go.dev/blog/path-security Command และ LookPath จะค้นหาโปรแกรมในไดเรกทอรีที่ระบุไว้ใน PATH ปัจจุบันตามธรรมเนียมของระบบปฏิบัติการ แต่ทุกวันนี้พฤติกรรมที่รวมไดเรกทอรีปัจจุบันไว้ด้วยมักเป็นสิ่งที่ไม่คาดคิดและนำไปสู่ปัญหาความปลอดภัย
      https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
    • สามารถบรรเทาได้ง่ายโดยค้นหา ไฟล์รัน Git ที่แท้จริง จาก system path ที่ทราบอยู่แล้ว หรือให้ผู้ใช้ตั้งค่า path เอง และเข้าใจว่า VS Code ก็จัดการด้วยวิธีนั้น
    • นี่คือ กับดักด้านความปลอดภัย แบบเก่าและเป็นที่รู้จักกันดี ซึ่งต้องป้องกันให้ได้เสมอเมื่อพัฒนาซอฟต์แวร์สำหรับ Windows
    • ถ้าอย่างนั้นก็ฟังดูเหมือนว่าท้ายที่สุดแล้วนี่คือบั๊กและช่องโหว่ใน Cursor เวอร์ชัน Windows

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

    • ไม่ชัดเจนว่าการช่วยให้แก้ปัญหาอย่างจริงใจควรทำอย่างไร และ ต้นทุนจม ที่พูดถึงในที่นี้หมายถึงอะไรกันแน่ โดยรวมแล้วฟังดูคลุมเครือเกินไป

  • สงสัยว่าเหตุใด Cursor จึงรันไฟล์รันได้โดยอัตโนมัติ และมันเกิดจาก ลำดับการตัดสินใจ แบบไหน แม้ Vim ก็เคยมีปัญหารันโค้ดไม่คาดคิดตอนโหลดไฟล์เพราะฟีเจอร์แบบ %{expr} ที่ระบุชัดเจน แต่ก็ยังเข้าใจยากว่าเหตุใด Cursor จึงต้องไปหา git.exe และมันเป็นฟีเจอร์ที่ช่วยใครกันแน่
    แม้ในมุมของคนที่ไม่เคยใช้ Cursor ก็ยังสงสัยว่าทำไม CVE ที่ดูซ้ำซ้อนและน่าจะแก้ได้ง่ายแบบนี้ถึงยังมีอยู่

    • ลักษณะการใช้งานที่พบบ่อยคือขอให้ Cursor สรุป repository ที่มีอยู่และเขียน README ให้ จากนั้น Cursor จะอ่าน repository และโค้ด แล้วรัน คำสั่ง Git เพื่อดึงข้อมูลเมตาอย่าง development branch หรือ tag ก่อนหน้าเพิ่มมาด้วย
      ปัญหาคือเมื่อสั่งให้ประเมิน remote repository แล้วมัน clone repository มาก่อน จากนั้นถ้ารัน git ... ใน working directory Windows อาจตัดสินใจว่าไฟล์ git ที่อยู่ในไดเรกทอรีนั้นคือสิ่งที่ต้องรัน เมื่อสลับไปยัง repository ที่ไม่น่าเชื่อถือหรือ branch ที่ถูกเจาะ ก็อาจมีการรันโค้ดได้ทันที
      วิธีแก้ทั่วไปคือใช้ path แบบเต็ม ของ Git ที่ติดตั้งอยู่ในระบบ ซึ่งแม้จะน่ารำคาญสำหรับคนพิมพ์เอง แต่สำหรับ Cursor เป็นงานเล็กน้อยมาก
    • ดูเหมือนมีเจตนาจะหา Git จริงของผู้ใช้เพื่อให้เอเจนต์ในตัวอ่านบริบทข้ามหลาย branch และ worktree ได้ แม้จะมีวิธีที่ปลอดภัยกว่า แต่ทางลัดเล็ก ๆ แบบนี้มักพลาดได้ง่ายใน เวิร์กโฟลว์ที่มี AI ช่วย และยังเป็นจุดที่การคัดแยกบั๊กด้วย AI มักปล่อยให้สัญญาณเตือนหลุดไปได้ง่าย

  • เนื่องจากมักให้สิทธิ์เอเจนต์พัฒนาในการดึงและส่งข้อมูลขึ้น Git repository อยู่แล้ว นี่จึงกลายเป็น เส้นทางโจมตี supply chain ขนาดใหญ่ หากเอเจนต์ Cursor ที่กำลังทำงานดึงไฟล์ล่าสุดมาแล้วผู้โจมตีได้ฝังไฟล์รันได้ไว้ในโปรเจ็กต์ ก็อาจทำให้จู่ ๆ ผู้ใช้หลายแสนคนรัน EXE ตามอำเภอใจภายใต้สิทธิ์ผู้ใช้ปกติได้

  • รายงานฉบับนี้อ่านแล้วค่อนข้างเหมือน ข้อความที่ AI เขียน การโจมตีจะเกิดขึ้นได้ต้องมีเพย์โหลดอันตรายอยู่ในพีซีแล้วผ่านการ clone หรือดาวน์โหลดอะไรบางอย่างก่อน จึงเข้าใจระดับความรุนแรง แต่ก็อดคาดหวังไม่ได้ว่าแต่แรกไม่ควรไปอยู่ในสถานการณ์แบบนั้น

    • เอเจนต์เขียนโค้ดสมัยใหม่เมื่อถูกถามถึง API ที่เอกสารไม่ชัดเจน ก็อาจ clone repository และอ่านโค้ด ดังนั้นช่องโหว่นี้จึงสามารถถูกใช้โจมตีได้จริง
    • เพย์โหลดอันตรายอาจอยู่ใน remote repository ก็ได้ แค่ git clone repository แล้วเปิดด้วย Cursor ก็ถือว่า ถูกเจาะสำเร็จ แล้ว
    • ถ้าเป็นนักพัฒนาโอเพนซอร์ส ก็อาจได้รับ pull request ที่มี git.exe รวมมาด้วย
    • ปกติเราไม่ได้มองว่าการดาวน์โหลด repository มาดูซอร์สเท่ากับการเปิดใช้งานเพย์โหลดอันตราย และตรงนั้นเองที่น่ากังวล ถึงสำนวนแบบ AI จะชวนรำคาญ แต่สิ่งที่ควรถูกวิจารณ์คือ ตัวเนื้อหาของช่องโหว่ ไม่ใช่วิธีการเขียน
    • ยากจะฟันธงว่าเพย์โหลดต้องมีอยู่ในพีซีล่วงหน้าเสมอ หาก prompt injection สามารถชักนำให้รันคำสั่งอย่าง download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;) ได้ ก็มีโอกาสที่เอเจนต์จะดาวน์โหลด git.exe แล้วรันมัน