ช่องโหว่ Windows ที่เพิ่งถูกเปิดเผย (CVE-2026-35603) ช่วยให้ผู้ใช้ทั่วไปที่ไม่ใช่ผู้ดูแลระบบสามารถวางไฟล์กำหนดค่า (configuration file) ที่เป็นอันตรายลงในโฟลเดอร์ C:\ProgramData ที่ใช้ร่วมกันได้ ซึ่งเป็นจุดที่เครื่องมือช่วยเขียนโค้ดที่ขับเคลื่อนด้วย AI หลายตัวจะอ่านการตั้งค่าโดยอัตโนมัติ เมื่อผู้ดูแลระบบรันเครื่องมือเหล่านั้นในภายหลัง—เช่น Claude Code, Cursor, Codex CLI หรือ Gemini CLI—ไฟล์ที่เป็นอันตรายจะถูกรันด้วยสิทธิ์ระดับระบบสูงสุด (full system privileges) ทำให้ผู้โจมตีสามารถควบคุมเครื่องได้โดยไม่มีการแจ้งเตือนใดๆ

ทำไมปัญหานี้จึงสำคัญ

เครื่องมือช่วยเขียนโค้ดด้วย AI กลายเป็นส่วนหนึ่งที่พบได้ทั่วไปในกระบวนการพัฒนาซอฟต์แวร์ (development pipelines) ซึ่งมักจะถูกรันด้วยสิทธิ์ที่สูงขึ้นเพื่อเข้าถึงคอมไพเลอร์ (compilers), ตัวจัดการแพ็กเกจ (package managers) หรือคลังเก็บข้อมูลภายใน (internal repositories) ความสามารถในการฉีดโค้ด (inject code) ที่ทำงานในฐานะผู้ดูแลระบบนั้นสามารถข้ามผ่าน sandbox ระดับผู้ใช้ทั่วไปที่ใช้ปกป้องเวิร์กสเตชันได้ ในทางปฏิบัติ บัญชีที่มีสิทธิ์ต่ำสามารถวางไฟล์ทิ้งไว้ รอให้ผู้ดูแลระบบเปิดใช้งานเครื่องมือช่วยเขียนโค้ด แล้วจากนั้นเครื่องมือดังกล่าวก็จะรันคำสั่งตามอำเภอใจ เปลี่ยนแปลงไฟล์ระบบ หรือขโมยข้อมูลประจำตัว (credentials) ผลกระทบมีตั้งแต่การแอบฝังตัวเงียบๆ เพื่อติดตั้งมัลแวร์ที่ฝังตัวถาวร ไปจนถึงการเข้าควบคุมเวิร์กสเตชันขององค์กรอย่างสมบูรณ์

ช่องโหว่นี้ทำงานอย่างไร

เครื่องมือทั้งสี่ตัวมีทางเลือกในการออกแบบที่เหมือนกันอย่างหนึ่งคือ: พวกเขาจัดเก็บไฟล์กำหนดค่าที่ใช้ร่วมกันทั้งเครื่องไว้ใน C:\ProgramData และโหลดไฟล์เหล่านั้นโดยอัตโนมัติเมื่อเริ่มทำงาน ในระบบ Windows ไดเรกทอรีดังกล่าวสามารถอ่านและเขียนได้โดยผู้ใช้มาตรฐานทั่วไป เครื่องมือเหล่านี้ไม่ได้ตรวจสอบเจ้าของไฟล์หรือความถูกต้องสมบูรณ์ (integrity) ของไฟล์ก่อนที่จะทำการประมวลผล (parsing)

เครื่องมือ ไฟล์กำหนดค่าที่คาดหวัง
Claude Code managed-settings.json
Cursor hooks.json
Codex CLI config.toml
Gemini CLI system-defaults.json

ผู้โจมตีจะสร้างไฟล์ที่มีชื่อตรงกับที่เครื่องมือเรียกหา วางไว้ในโฟลเดอร์ที่เกี่ยวข้องภายใต้ C:\ProgramData แล้วรอ เมื่อผู้ดูแลระบบเปิดใช้งานเครื่องมือช่วยเขียนโค้ด โปรแกรมจะอ่านไฟล์ที่ผู้โจมตีควบคุมอยู่และรันเนื้อหาภายในไฟล์นั้น ในกรณีของ Codex CLI ไฟล์กำหนดค่าที่เป็นอันตรายยังสามารถปิด sandbox ด้านความปลอดภัยที่มีมาให้ในตัว ซึ่งเป็นการขยายขอบเขตการโจมตีให้กว้างขึ้นไปอีก

Anthropic ผู้สร้าง Claude Code ได้ย้ายการตั้งค่าไปยังตำแหน่งที่ได้รับการคุ้มครองแล้ว ซึ่งเป็นการปิดช่องโหว่สำหรับผลิตภัณฑ์นั้นได้อย่างมีประสิทธิภาพ ส่วนผู้ผลิตรายอื่นยังไม่ได้ออกตัวแก้ไข (fix) ณ เวลาที่จัดทำรายงานการวิจัยนี้ ทำให้ผู้ใช้งานยังคงมีความเสี่ยง

ใครได้ประโยชน์ ใครเสียประโยชน์

  • ผู้โจมตี ได้รับเส้นทางการยกระดับสิทธิ์ (privilege-escalation) ที่ตรงไปตรงมา โดยไม่จำเป็นต้องใช้การเจาะช่องโหว่ของเคอร์เนล (kernel bugs) หรือโค้ด zero-day
  • นักพัฒนาและองค์กร ที่พึ่งพาเครื่องมือเหล่านี้ในการทำงานประจำวัน ต้องเผชิญกับความเสี่ยงจากการถูกขโมยข้อมูลประจำตัวอย่างเงียบๆ, การฉีดโค้ด หรือการแพร่ระบาดของแรนซัมแวร์ (ransomware)
  • ผู้ผลิตเครื่องมือ เสี่ยงต่อความเสียหายด้านชื่อเสียงและอาจต้องรับผิดชอบทางกฎหมายหากไม่ได้รับการแก้ไขช่องโหว่อย่างทันท่วงที

ค่าใช้จ่ายจากการถูกบุกรุกอาจสูงมาก: SSH keys, cloud tokens และ Git credentials ที่ถูกขโมยไปอาจเป็นประตูไปสู่การบุกรุกเครือข่ายที่กว้างขึ้น แม้แต่เวิร์กสเตชันที่ถูกเจาะเพียงเครื่องเดียวก็สามารถกลายเป็นฐานในการเคลื่อนที่ในแนวราบ (lateral movement) ภายในสภาพแวดล้อมขององค์กรได้

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

จนกว่าผู้ผลิตจะส่งตัวแก้ไข (patches) ออกมา ผู้ดูแลระบบสามารถเสริมความแข็งแกร่งให้กับโฟลเดอร์เหล่านั้นได้ด้วยตนเอง คำสั่ง PowerShell ต่อไปนี้ (ซึ่งต้องรันด้วยสิทธิ์ที่สูงขึ้น) จะสร้างไดเรกทอรีที่จำเป็น (หากยังไม่มีอยู่) และล็อกโฟลเดอร์เหล่านั้นเพื่อให้เฉพาะระบบและผู้ดูแลระบบเท่านั้นที่มีสิทธิ์เขียนข้อมูลได้:

# Create the directories
$paths = @(
    "C:\ProgramData\ClaudeCode",
    "C:\ProgramData\Cursor",
    "C:\ProgramData\openai\codex",
    "C:\ProgramData\gemini-cli"
)
foreach ($p in $paths) { New-Item -ItemType Directory -Path $p -Force }

# Remove inherited permissions and grant only the needed accounts
foreach ($p in $paths) {
    icacls $p /inheritance:r
    icacls $p /grant "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F" "Users:(OI)(CI)RX"
}

หลังจากใช้ ACLs (access-control lists) แล้ว ให้สแกนโฟลเดอร์เพื่อหาไฟล์ใดๆ ที่เป็นของผู้ใช้มาตรฐาน การพบไฟล์ดังกล่าวเป็นสัญญาณบ่งชี้ที่ชัดเจนว่าเครื่องอาจถูกบุกรุกแล้ว ในกรณีนั้น ให้ทำการเปลี่ยน (rotate) private keys, cloud access tokens และข้อมูลประจำตัวของระบบควบคุมเวอร์ชัน (version-control credentials) ทั้งหมดทันที

สิ่งที่ควรเฝ้าระวัง

  • ตัวแก้ไขจากผู้ผลิต – คอยติดตามบันทึกการเปลี่ยนแปลง (release notes) จากผู้ผลิตที่ได้รับผลกระทบ การย้ายไปยังตำแหน่งที่ได้รับการคุ้มครองหรือการตรวจสอบความถูกต้องของไฟล์กำหนดค่าจะช่วยแก้ปัญหานี้ได้
  • การอัปเดตเครื่องมือด้านความปลอดภัย – แพลตฟอร์มการตรวจจับที่ปลายทาง (Endpoint detection platforms) อาจเพิ่มลายเซ็น (signatures) สำหรับรูปแบบการสร้างไฟล์ใน C:\ProgramData นี้ การติดตั้งอัปเดตเหล่านั้นจะช่วยให้มีการแจ้งเตือนล่วงหน้าได้
  • การเปิดเผยข้อมูลจากชุมชน – นักวิจัยด้านความปลอดภัยอาจเผยแพร่โค้ดต้นแบบสำหรับการโจมตี (proof-of-concept exploits) หรือสคริปต์การตรวจจับ ซึ่งสามารถนำมาใช้ในการตรวจสอบภายในได้

ข้อโต้แย้ง

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

บทสรุป

CVE-2026-35603 แสดงให้เห็นว่าการตัดสินใจในการออกแบบที่ดูเหมือนไม่มีอันตราย—อย่างการอ่านค่าคอนฟิกูเรชันจากโฟลเดอร์ที่ทุกคนสามารถเขียนไฟล์ลงไปได้—สามารถกลายเป็นเส้นทางการยกระดับสิทธิ์ที่ทรงพลังได้อย่างไรเมื่อมีการใช้เครื่องมือ AI เข้ามาเกี่ยวข้อง จนกว่าผู้ผลิตจะแก้ไขช่องโหว่นี้ การป้องกันที่เชื่อถือได้เพียงอย่างเดียวคือการจำกัดสิทธิ์การเข้าถึงโฟลเดอร์ย่อยใน C:\ProgramData ที่ผู้ช่วยเหล่านี้ใช้งาน และให้ถือว่าไฟล์ใดๆ ที่ไม่คาดคิดในนั้นเป็นสัญญาณของการถูกบุกรุก การเพิกเฉยต่อปัญหานี้จะเปิดช่องทางโดยตรงให้บัญชีที่มีสิทธิ์ต่ำสามารถเข้าควบคุมเวิร์กสเตชัน Windows ได้อย่างสมบูรณ์