
Claude Code 2.1.286 ลด secret รั่วใน MCP แต่ permission ยังต้องคุมเอง
Claude Code 2.1.286 ออกเมื่อ 30 กันยายน 2026 พร้อมแก้ MCP error ไม่ให้เผยค่า credential และขยายการปิดบัง secret หลายรูปแบบครับ รุ่นนี้ยังปรับ permission prompts, lifecycle ของ Remote Control และกติกาติดตั้ง plugin แต่ไม่ได้ทำให้ agent ควรได้สิทธิ์ shell, filesystem หรือ network กว้างขึ้น
สรุป 30 วินาที
- release ทางการ 2.1.286 แก้ redaction สำหรับ bearer token ที่ percent-encode, key ที่มีอักขระมองไม่เห็น และ password ใน URL ที่มีเครื่องหมายพิเศษ พร้อมลดโอกาส credential หลุดผ่าน MCP error
- Remote Control จะตัดการเชื่อมต่อเมื่อ policy องค์กรปิดความสามารถนี้ และ UI แสดงจำนวน permission requests ที่เข้าคิว ช่วยให้เห็นงานรออนุมัติ แต่คนยังต้องอ่านขอบเขตจริง
- โหมด
--bareถูกทำให้จำกัดองค์ประกอบมากขึ้น ส่วน plugin install ปฏิเสธ dependency แบบ git/folder และรับเฉพาะ registry dependency ตาม release note ซึ่งช่วยลดเส้นทาง supply chain บางแบบ - ตรวจ release, เอกสาร permission/sandbox, advisory และ asset digests แบบ read-only ไม่รัน installer หรือ binary กับ repository/credential จริง
- 2.1.286 ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ สำหรับ canary แบบ deny-by-default ที่ตรึงเวอร์ชันและตรวจ plugin/MCP ทีละตัว ไม่ใช่คำรับรองว่าปลอดภัยแน่นอน
ทำไมเรื่องนี้เกี่ยวกับคุณ
secret มักไม่ได้หลุดเพราะ agent ตั้งใจขโมยครับ แต่มันหลุดระหว่าง error handling, log, URL หรือข้อความ diagnostic ที่ถูกคัดลอกไป issue อีกทอด MCP server อาจตอบ error พร้อม Authorization header แล้ว client เอาไปแสดงเต็ม ๆ หรือ token ถูก encode จน regex เดิมมองไม่เห็น การแก้ redaction หลายรูปแบบจึงมีประโยชน์ในเส้นทางที่คนไม่ค่อยคิดถึง
อย่างไรก็ดี redaction เป็นตาข่ายดักหลังข้อมูลเข้า process แล้ว วิธีที่ดีกว่าคือไม่ส่ง secret ที่ agent ไม่จำเป็นต้องใช้ตั้งแต่ต้น ถ้า mount home directory, export token อายุยาว และเปิด network ทุกปลายทาง การหวังให้ตัวกรองข้อความจับ secret ทุกรูปแบบก็เหมือนเปิดตู้เซฟทิ้งไว้แล้วฝากพนักงานลบเลขบัญชีออกจากรูปถ่ายทีหลัง
permission queue และ Remote Control เกี่ยวกับทีมที่ใช้ agent ระยะไกลหรือปล่อยงานหลายขั้น การเห็นจำนวนคำขอช่วยลด approval ที่ตกหล่น แต่ก็สร้างแรงกดให้คนกดผ่านเร็ว ๆ จึงต้องออกแบบ policy ให้คำขอมี target, command, path และเหตุผลชัด ไม่ใช่ popup แบบ “Allow” ที่ตีความไม่ได้
ทำงานยังไง: ด่านหน้ากับตะแกรงปลายท่อ
permission และ sandbox คือด่านหน้าที่กัน action ก่อนเกิด ส่วน secret redaction คือตะแกรงปลายท่อที่พยายามกันข้อมูลอ่อนไหวไม่ให้โผล่ใน output/log ทั้งสองชั้นจำเป็น แต่ทำหน้าที่ไม่เหมือนกัน
เอกสาร permissions อธิบายการควบคุม tool และการอนุมัติ ผู้ดูแลควรนิยาม allow/deny ให้แคบตาม repository ส่วน เอกสาร sandboxing ครอบการจำกัด filesystem กับ network แนวคิดสำคัญคือ shell command ที่ syntax ดูปกติอาจเรียก subprocess, อ่านไฟล์ หรือออก network ได้ จึงต้อง enforce ที่ระบบปฏิบัติการ/สภาพแวดล้อมด้วย ไม่ใช่ตรวจเฉพาะข้อความ command
ใน 2.1.286 ตัวกรอง secret ถูกขยายให้เห็นรูปแบบหลบตาหลายชนิด เช่นค่า bearer ที่ผ่าน percent encoding, ชื่อ key แทรกอักขระที่มองไม่เห็น และ password ใน URL ที่มี punctuation จุดนี้ช่วยเมื่อ error หรือ output จำเป็นต้องผ่าน UI แต่ไม่ได้ครอบ secret ที่ไม่ตรง pattern, ข้อมูลธุรกิจที่ไม่ใช่ token หรือค่าที่ถูกแบ่งเป็นหลายชิ้น
การตัด Remote Control เมื่อ org policy ปิด เปรียบเหมือนยกเลิกบัตรผ่านทันทีเมื่อฝ่ายอาคารเปลี่ยนนโยบาย แทนที่จะรอ session จบ ส่วนการจำกัด plugin dependency ให้มาจาก registry ลดการชี้ไปยัง git/folder แบบเปลี่ยนเนื้อหาได้ง่าย แต่ registry package เองยังถูกยึดหรือมี maintainer risk ได้ ต้องตรึง version/lockfile และตรวจ provenance ต่อ
โหมด --bare ลดองค์ประกอบบางส่วน เช่นให้ใช้เฉพาะ named MCP และไม่พ่วง system reminders/background tasks ตาม release note ชื่อ “bare” ไม่ได้แปลว่า “sandboxed” ต้องตรวจ permission, environment และ network แยกอยู่ดี
หลักฐานที่ตรวจ
ตรวจ publisher/repository anthropics/claude-code, tag v2.1.286, release note วันที่ 30 กันยายน 2026, เอกสาร permissions และ sandboxing บนโดเมนทางการ รวมถึง security advisories ณ วันที่ 1 ตุลาคม 2026 การตรวจทั้งหมดเป็น metadata และเอกสาร ไม่รัน remote installer, npm package หรือ release binary
GitHub metadata แสดง SHA-256 ของ claude-darwin-arm64.tar.gz เป็น 0b0333f25613cf8ba8035f6c806abc45c72b2bdd4dc8ef59ce7582a2a0e76744 digest ของ SHASUMS256.txt เป็น ed712b013ca2062d536af4533c736f731c7c26220d7888a4514fa68454e299c4 และ digest ของ signature asset เป็น c87fd01e04990744bb90ca9f36ff8983365c8bb5c0a4ff1e5219db3eb3364e92 ตัวเลขเหล่านี้ใช้ผูก artifact กับ release metadata ไม่ได้ยืนยันความปลอดภัยของโค้ดภายใน
หน้า advisory ถูกตรวจว่ามีรายการที่กระทบ release นี้โดยตรงหรือไม่ เราไม่พบ known high/critical advisory สาธารณะที่ระบุว่า 2.1.286 ยังได้รับผลโดยไม่มี mitigation ณ เวลา verifiedAt แต่ประวัติ advisory ของโครงการย้ำว่าการเรียก shell, trust boundary และเครื่องมือเสริมต้องเฝ้าระวังต่อ การไม่มีประกาศใหม่ไม่ใช่ใบรับรองความปลอดภัย
publisher, tag/version, changelog และ provenance ชัดเจน รุ่นนี้แก้พฤติกรรมที่ตรงกับ secret/permission boundary จึงผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ สำหรับการทดลองที่ไม่ใช้ production credential
วิธีใช้ให้ปลอดภัยขึ้น
ตรึง 2.1.286 และตรวจ checksum/signature ตามคู่มือผู้ผลิตใน disposable environment ใช้ repository จำลองหรือ worktree แยกที่ไม่มี .env, cloud profile และ SSH key ให้ writable path เฉพาะงาน ปิด network โดยค่าเริ่มต้นและเปิดปลายทางทีละรายการผ่าน proxy/allowlist
เริ่มโดยไม่มี MCP และ plugin จากนั้นอ่าน manifest, command, dependency, permission และ secret flow ก่อนเพิ่มหนึ่งตัว ใช้ OAuth/token แยกต่อ server อายุสั้น scope ต่ำ และเพิกถอนได้ ตรวจว่า error, debug log และ transcript ไม่แสดงค่าจริงด้วย canary secret ที่สร้างเพื่อทดสอบ ห้ามใช้ secret ของจริงเป็นตัวล่อ
กำหนด permission rule จาก action กับ resource ไม่ใช่ชื่อ tool กว้าง ๆ งานอ่าน code ไม่ควรได้สิทธิ์ push งานสร้าง PR ไม่ควรได้ production access และ Remote Control ต้องอยู่หลัง org policy, device trust และ audit log ถ้า policy เปลี่ยน ให้ทดสอบว่าการเชื่อมต่อเดิมถูกตัดจริง
plugin ควรมี allowlist, version pin และ lockfile ตรวจ owner change กับ advisory ก่อนอัปเดต อย่ารัน install hook ที่ไม่จำเป็น ให้ external gate เช่น tests, secret scan, code review และ branch protection เป็นผู้ตัดสินก่อน merge แม้ agent รายงานว่างานเสร็จแล้ว
ความเสี่ยงคงเหลือ
redaction เป็น pattern-based defense จึงอาจพลาด secret รูปแบบใหม่ token ที่ถูกแบ่ง/เข้ารหัส หรือข้อมูลลูกค้าที่ไม่มีรูป token MCP server อาจส่งข้อมูลออกเองแม้ client ไม่แสดง error และ plugin จาก registry ยังมี dependency confusion, account takeover หรือ malicious update ได้
ผู้ใช้สามารถอนุมัติ permission ผิดจาก fatigue ได้ โดยเฉพาะเมื่อคำขอเข้าคิวหลายรายการ Sandbox บางโหมดอาจเปิด network หรือ path มากกว่าที่ทีมคาด และ shell สามารถสร้างผลข้างเคียงผ่านโปรแกรมลูกได้ Remote Control เพิ่มพื้นผิวการเชื่อมต่อ จึงต้องมีการเพิกถอนและ observability ภายนอก client
เราไม่ได้รัน artifact จึงยังไม่ยืนยัน behavior บน macOS/Linux/Windows ขององค์กร ไม่ได้ตรวจ source diff ทุก dependency และไม่สามารถรับรองว่า advisory ใหม่จะไม่ถูกเผยแพร่หลังวันที่ตรวจ residual risk จึงยังอยู่ที่ prompt injection, supply chain, approval error และ credential exposure นอก pattern
สิ่งที่ยังไม่ชัด และแหล่งข่าวพูดไม่ตรงกันตรงไหน
release note อธิบาย bug fixes เป็นรายการสั้น ส่วนเอกสาร permissions/sandboxing อธิบาย behavior ทั่วไป จึงยังไม่เห็น coverage matrix ว่า redaction ใช้กับทุก log channel, plugin output และ remote transcript หรือไม่ ต้องทดสอบ deployment จริงและถามผู้ผลิตหากเป็น requirement ด้าน compliance
คำว่า registry-only สำหรับ plugin dependency ลดบางเส้นทาง แต่ release note ไม่ได้แปลว่า registry package ได้รับ security review ทุกตัว อีกทั้ง queue count บอกจำนวนคำขอ ไม่ได้จัดลำดับความเสี่ยงให้ผู้อนุมัติ เราจึงไม่ควรขยายผลเกินหลักฐาน
ควรทำอะไร
นักพัฒนารายบุคคลควรทดสอบด้วยข้อมูลจำลองและอ่าน permission ทุกครั้ง ทีม platform ควรแจก policy template กับ MCP allowlist ทีม security ควรทำ canary-redaction test และตรวจ egress ส่วนองค์กรที่ใช้ Remote Control ควรกำหนด kill switch, session TTL และ incident playbook ก่อนเปิดให้หลายคน
Recap
- ตรึง 2.1.286 และตรวจ checksum/signature จาก release ทางการ
- แยก secret ออกจาก agent ก่อนพึ่ง redaction
- ปิด MCP/plugin/network แล้วเปิดทีละตัวด้วยสิทธิ์แคบ
- ทดสอบ org policy ว่าตัด Remote Control session เดิมได้จริง
- ล็อก plugin version และตรวจ dependency/provenance ต่อเนื่อง
- ให้ tests, secret scan, review และ branch protection คุมการ merge
2.1.286 แก้รูรั่วในทางเดินของ error และ secret ได้ตรงจุดครับ แต่ตะแกรงปลายท่อไม่ควรเป็นเหตุผลให้เราเทข้อมูลทุกอย่างเข้าท่อตั้งแต่แรก