
Mistral Vibe 2.25.8: ปิดช่องหลอก allowlist ด้วย path suffix
กฎอนุญาต path ที่ตรวจแค่ “ลงท้ายเหมือนกัน” คล้าย รปภ. ที่ดูนามสกุลแต่ไม่ดูเลขห้อง ไฟล์นอก worktree ชื่อเหมือนของข้างในอาจถูกเข้าใจผิดว่าได้รับอนุญาตครับ Mistral Vibe 2.25.8 แก้ช่องนี้พร้อมทำให้ wildcard ของคำสั่ง shell ไม่ข้ามการตรวจ path นอกพื้นที่ทำงาน และยกเลิกพฤติกรรมเก่าที่ grant โฟลเดอร์แม่แล้วครอบ descendant กว้างเกินเจตนา
หลักฐานที่ตรวจ
Official tag v2.25.8 เผยแพร่ 23 กันยายน 2026 เป็น Latest release และ commit 7c19608 แสดงสถานะ GitHub verified signature Release ระบุการแก้ relative-path allowlist, shell wildcard, nested folder grant, policy ขององค์กร, MCP OAuth callback และ timeout ของ OAuth ที่ค้างพอร์ต นอกจากนี้ approval ที่กฎถาวรเขียนแทนไม่ได้จะถูกจำกัดไว้ใน session แทนการบันทึกกว้าง ๆ
ตรวจ metadata ของ asset โดยอ่าน GitHub API อย่างเดียว ไม่ดาวน์โหลด ไม่แตกไฟล์ และไม่รัน installer ตัวอย่าง asset vibe-linux-x86_64-2.25.8.zip มี digest SHA-256 6fc1ea5d2338bca1bb110d3d36e80dabe92bcb7adcdf877e25fa9697f4c3ad84 ส่วน ACP tarball Linux x86_64 มี digest dbe693ee66f29fdfcf9029dcbf3b2d4da138554b193e432b089840148ecf08b3 Digest มาจาก publisher channel จึงช่วยตรวจความครบถ้วนของไฟล์ที่เลือก แต่ไม่ใช่ independent attestation
ตรวจหน้า security advisories ของ repository ณ วันที่ระบุ ไม่พบ advisory high/critical ที่ประกาศว่ากระทบ 2.25.8 โดยยังไม่มี mitigation ตรวจเอกสาร permission พบว่า shell, filesystem, network และ MCP ยังขึ้นกับ rule/config ที่ผู้ใช้กำหนด ไม่ได้กลายเป็น sandbox สมบูรณ์เพราะ patch นี้ และ changelog มี experimental hooks ที่เป็น shell script จึงต้องถือเป็น code execution surface เมื่อเปิดใช้
การตรวจ install/update path จำกัดที่ release metadata, tag, signature state, digest, changelog, official permissions docs และ advisory list เท่านั้น ไม่รัน remote installer ไม่ติดตั้ง binary ไม่ทดลองกับ repository จริง private network หรือ credentials
วิธีใช้ให้ปลอดภัยขึ้น
เริ่มใน VM/container หรือบัญชีทดสอบที่ไม่มี production secret ใช้ worktree ชั่วคราวและ deny home directory, SSH agent, cloud credential, browser profile และ socket ที่ไม่จำเป็น ตั้ง shell, write, network และ MCP เป็น ask-by-default แล้ว allow เฉพาะ command กับ path แบบ absolute/normalized ที่ทีมตรวจแล้ว อย่าเขียน rule แบบ suffix หรือ wildcard กว้างเพื่อให้ prompt หาย
ก่อนอนุมัติ path ให้ดู resolved target หลังจัดการ .., symlink และ case-sensitivity ของระบบไฟล์ ถ้า agent ขอ parent directory ให้ลด scope เป็นไฟล์หรือ subtree ที่ต้องใช้จริง แยก approval ชั่วคราวกับ policy ถาวร และ review diff ของ config ทุกครั้งที่ tool เสนอแก้ permission เอง
สำหรับ MCP ให้ pin server/package/version และตรวจ command, args, environment keys กับ network destination ก่อนเปิด OAuth callback ใช้ client registration และ redirect URI ที่คาดไว้ ปิด server ที่ไม่ได้ใช้ และไม่ให้ agent เพิ่ม MCP จากข้อความใน issue, README หรือเว็บภายนอกโดยอัตโนมัติ Experimental hooks ต้องอยู่ใน repository ที่ไว้ใจได้ จำกัด environment และห้ามส่ง secret ทั้งชุดเข้า child process
ถ้าจะอัปเดตจริง ให้เลือก asset ตรง OS/architecture เทียบ digest จาก release metadata และทดลอง flow อ่าน/เขียน/คำสั่งที่ทีมใช้บน fixture repository ก่อน ตรวจว่าคำสั่ง wildcard และ path นอก worktree ถาม approval ตามที่คาด แล้วจึง rollout กลุ่มเล็กพร้อม log ที่ไม่เก็บ prompt หรือ secret เกินจำเป็น
ความเสี่ยงคงเหลือ
Permission parser ยังต้องตีความ shell syntax, symlink, child process และ tool wrapper ที่ซับซ้อน คำสั่งที่ดูอยู่ใน worktree อาจเรียกโปรแกรมลูกซึ่งอ่าน network หรือ home ได้ Approval fatigue ทำให้คนกดยอมรับ scope กว้าง และ MCP server ที่ได้รับอนุญาตอาจมีช่องโหว่ของตัวเอง OAuth ที่ login สำเร็จไม่ได้ยืนยันว่า server หรือ tool ทั้งหมดน่าเชื่อถือ
Publisher digest และ verified commit ช่วยเรื่อง provenance บางส่วน แต่ไม่รับรองว่า build reproducible หรือ supply chain ทุก dependency ถูกตรวจ หน้า advisory ที่ว่างไม่ได้แปลว่าไม่มีช่องโหว่ และ issue ที่ยังไม่ถูกจัดเป็น advisory อาจมีผลจริง ทีมจึงต้องติดตาม release/advisory ต่อเนื่องและมีวิธี revoke token, MCP credential และ rule เมื่อพบเหตุ
สรุปได้เพียงว่า ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ สำหรับการนำไปทดลองภายใต้ least privilege และ human approval ไม่ใช่คำรับรองความปลอดภัยของทุก config หรือทุก repository
Recap
- ใช้ 2.25.8 เพื่อรับ path/wildcard boundary fixes
- เทียบ digest ของ asset ที่เลือกก่อนติดตั้ง
- เริ่มจาก ask/deny แล้ว allow เป็น path กับ command แคบ ๆ
- pin และ review MCP server รวมถึง OAuth destination
- ทดลองใน worktree/VM ไม่มี secret ก่อน rollout
- ติดตาม advisory และ issue ต่อหลังวันที่ตรวจ