Claude Code 2.1.284: ปิดทางลัด symlink และเข้ม permission ของ plugin

Claude Code 2.1.284 ออกเมื่อ 28 กันยายน 2026 พร้อมรองรับ Sonnet 5.5 และมีชุดแก้ความปลอดภัยที่น่าสนใจกว่าชื่อฟีเจอร์: เพิ่ม approval ครั้งเดียวสำหรับการอ่านไฟล์ภายนอก, แก้ symlink จาก .claude/rules ที่ชี้ออกนอกขอบเขต, จำกัด plugin ไม่ให้ preapprove tool เมื่อองค์กรตั้ง allowManagedPermissionRulesOnly และแก้การรับมือ MCP elicitation ที่ถูก block ครับ

ผมตรวจ release v2.1.284, เอกสาร permissions, เอกสาร sandboxing, หน้า security advisories และ advisory เก่า GHSA-7835-87q9-rgvv แบบอ่านอย่างเดียว ไม่ติดตั้งหรือรัน binary ที่ไม่ผ่านการอนุมัติใน repository นี้

สรุป 30 วินาที

• 2.1.284 เพิ่ม Sonnet 5.5 และปรับ default บางส่วนของ interactive terminal/VS Code เมื่อไม่ได้กำหนด mode
• แก้ external rules symlink ให้ขออนุมัติ, เพิ่ม one-time external read approval และเข้ม plugin preapproval ภายใต้นโยบาย managed
• แก้ MCP elicitation block, Bash sandbox error, workflow sandbox hardening และ sanitize markup ใน auto-memory
• official release มี artifact digest และไฟล์ลายเซ็น checksum ให้ตรวจ provenance ได้
• advisory high เดิมที่ตรวจถูกแก้ก่อน 2.1.163 จึงไม่กระทบ 2.1.284 ตาม version range ที่ประกาศ และไม่พบ high/critical เปิดอยู่ที่ระบุว่ารุ่นนี้ได้รับผลโดยไม่มี mitigation ณ เวลาตรวจ
• ผลสรุป: ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ แต่ default mode และ plugin/MCP boundary ต้อง regression test ใน policy ขององค์กรจริง

ทำไมเรื่องนี้เกี่ยวกับคุณ

ไฟล์ .claude/rules และ plugin มักถูกมองเป็น “คำแนะนำโครงการ” แต่จริง ๆ มีอิทธิพลต่อสิ่งที่ agent อ่านและ tool ที่ขอใช้ หาก repository มี symlink ชี้ออกไปยังไฟล์ส่วนตัว แล้วระบบโหลดโดยไม่ขอ การ clone repository ที่ไม่ไว้ใจอาจพา agent อ่านข้อมูลนอก workspace ได้ Fix เรื่อง external symlink จึงเป็น boundary ที่สำคัญ

นโยบาย allowManagedPermissionRulesOnly มีไว้ให้องค์กรบอกว่าเฉพาะกฎที่ผู้ดูแลจัดการเท่านั้นจึง preapprove tool ได้ หาก plugin ยัง preapprove เอง นโยบายบนกระดาษไม่ตรงกับ runtime 2.1.284 แก้ช่องนี้ แต่ทีมต้องตรวจว่าตั้งค่า managed จริงและ plugin ที่ติดตั้งมาจากไหน

MCP elicitation คือเส้นทางที่ server ขอข้อมูลหรือคำยืนยันเพิ่มจากผู้ใช้ หาก block handling ผิด อาจเกิดทั้ง workflow ค้างหรือข้อมูลที่ไม่ควรถูกขอไหลผ่าน UI การแก้ใน release นี้ลดปัญหาที่รู้แล้ว แต่ MCP server ยังเป็นคู่สัญญาภายนอกที่ต้อง trust แยกจาก Claude Code

ทำงานยังไง

permission rule ตัดสินว่า tool call ใดอนุญาต ถาม หรือปฏิเสธ ส่วน sandbox จำกัดสิ่งที่ process ทำได้จริง ลองนึกถึงพนักงานถือคีย์การ์ด: กฎ permission คือสมุดว่าใครควรเข้าห้องไหน ส่วน sandbox คือระบบประตู แม้สมุดเขียนผิด ประตูที่จำกัดดีก็ยังลดห้องที่เปิดได้ และแม้ประตูแข็งแรง การแจกคีย์ master ก็ทำให้ขอบเขตกว้างเกิน

one-time external read approval ให้ผู้ใช้อนุญาตการอ่านนอก workspace เฉพาะครั้งแทนการเพิ่มสิทธิ์ถาวร เหมาะกับไฟล์อ้างอิงหนึ่งชิ้น แต่ UI ต้องแสดง path จริงหลัง resolve symlink ไม่ใช่ path สวยก่อน resolve หากอนุมัติ directory กว้างโดยไม่รู้ ก็กลับไปมีความเสี่ยงเดิมในขนาดใหญ่ขึ้น

symlink ใน rules ทำงานเหมือนป้ายหน้าห้องเขียนว่า “คู่มืออยู่ตู้ข้าง ๆ” แต่ตู้จริงอาจอยู่นอกอาคาร หาก loader ตามป้ายโดยไม่ตรวจ boundary repository สามารถชักจูงให้เปิดไฟล์อื่น Fix ต้องตรวจ canonical target และขอ approval เมื่อออกนอก scope ไม่ใช่ดูเฉพาะชื่อ path ที่อยู่ใต้ .claude

managed permission ป้องกัน plugin เปลี่ยนรายการ allow เองเมื่อองค์กรต้องการ centralized policy ประโยชน์เกิดเมื่อ admin-vouched/official source ถูกกำหนดชัดและมีการ review version หากทุก plugin ถูกติดป้าย trusted โดยอัตโนมัติ policy ยังเหลือเพียงชื่อ

หลักฐานที่ตรวจ

Publisher และ repository คือ anthropics/claude-code ซึ่งเป็นต้นทางทางการ Tag v2.1.284 ถูกเผยแพร่เป็น stable release ไม่ใช่ prerelease และ changelog ระบุรายการ permission/sandbox/MCP ที่กล่าวถึง ผมไม่ใช้หน้า download ภายนอกหรือ package mirror เป็นแหล่งหลัก

Asset claude-darwin-arm64.tar.gz แสดง SHA-256 เป็น 75603fec942fff2cbda25cfec94801402d029b4a7827b9875f64a7a326f46451 ส่วน SHASUMS256.txt.sig แสดง digest 4f49cc169ae9d32a586ceefbbcc2ebbaf0fb8870197913cfc6089ccb4d2c944f ค่าเหล่านี้ช่วยตรวจ artifact จาก release เดียวกัน รอบนี้ไม่ได้ดาวน์โหลดจึงไม่ได้อ้างว่า local binary ผ่าน checksum/signature verification

หน้า advisories มี GHSA-7835-87q9-rgvv ระดับ high ในอดีต โดย version ที่ได้รับผลถูกแก้ก่อน 2.1.163 ดังนั้น 2.1.284 อยู่นอกช่วงตามประกาศ ไม่พบรายการ high/critical ที่ official page ระบุว่ากระทบ 2.1.284 โดยไม่มี mitigation ณ verifiedAt แต่ advisory ที่ยังไม่เปิดเผยและ dependency zero-day ยังคงเป็น unknown

เอกสาร permission/sandbox ระบุว่าเครื่องมือและ filesystem/network behavior ขึ้นกับ mode กับ config การมี fix ใน release ไม่ได้ทำให้ default ทุกสภาพแวดล้อมเป็น deny-all และ release ยังกล่าวถึงการเปลี่ยน interactive terminal/VS Code ไป auto mode เมื่อไม่มี config จึงต้องตรวจ effective settings หลังอัป

เรื่องเงินและผลกระทบ

การอัปเดตลดความเสี่ยงจาก known boundary bugs แต่เพิ่มต้นทุน regression ของ terminal, IDE, plugin และ MCP ถ้าองค์กรมี managed policy หลายชั้น ต้องทดสอบทั้ง user config, project config และ managed setting เพราะ precedence ผิดอาจทำให้คนทำงานติด approval loop หรืออนุญาตกว้างเกิน

การรองรับ Sonnet 5.5 อาจเปลี่ยน latency, token และ tool behavior แม้ CLI version เป็นเรื่องเดียวกัน ทีมควรแยก rollout ตัว client กับ rollout model เพื่อรู้ว่าความต่างมาจากชั้นไหน เปลี่ยนพร้อมกันแล้ว metric ดีหรือเสียจะวิเคราะห์ยาก

Auto-memory sanitization ลด markup ที่อาจปนใน memory แต่ memory ยังอาจเก็บข้อมูลผิดหรือล้าสมัย ต้องกำหนด retention และ review เพราะความจำที่ไม่ใช่ secret ก็ชักนำ agent ผิดซ้ำได้ ค่าเสียหายอาจเป็นเวลาวิศวกร ไม่ใช่เพียงค่า token

ข้อมูลที่ยังไม่ชัดและแหล่งที่ไม่ตรงกัน

Release notes บอกว่า external .claude/rules symlink จะมี approval แต่ไม่ได้เผย reproduction และ exploitability ครบทุก platform จึงยังบอกไม่ได้ว่ามีการใช้โจมตีจริงหรือไม่ เอกสาร permission อธิบาย desired behavior กว้างกว่า changelog และไม่ใช่ forensic report

คำว่า auto mode ใน terminal/VS Code ต้องอ่านร่วมกับ effective config ของแต่ละ environment เพราะ release note สั้นไม่พอจะสรุปว่าคำสั่งชนิดใดเปลี่ยนจาก ask เป็น allow ไม่มีหลักฐานให้เหมารวมว่า “auto” เท่ากับ bypass approval แต่ก็ไม่ควรปล่อยผ่านโดยไม่ snapshot config ก่อน-หลัง

แหล่ง official สอดคล้องกันว่า sandbox และ permissions เป็นกลไกแยกชั้น แต่ไม่ได้ให้ independent penetration test ของ 2.1.284 และไม่มีรายงานภายนอกที่ทดสอบ fix ทุกตัว ณ เวลาตรวจ ดังนั้นข้อสรุปผ่าน gate หมายถึง provenance และ known-risk criteria ผ่าน ไม่ใช่ผ่านการพิสูจน์ทุกเส้นทาง

ยังไม่ชัดว่าการ sanitize auto-memory ครอบคลุม markup ทุกชนิดและ content จาก tool server แปลก ๆ แค่ไหน ทีมที่ใช้ memory กับข้อมูล regulated ต้องทำ data-flow review แยก

วิธีใช้ให้ปลอดภัยขึ้น

ติดตั้งจาก official channel, pin version และตรวจ checksum/signature เมื่อใช้ release asset อย่ารัน remote installer ในเครื่องที่เปิด production credential ก่อน canary ใช้ user ทดสอบที่ไม่มี SSH/cloud key และ workspace สำเนา

กำหนด permission mode อย่าง explicit อย่าพึ่ง default ที่อาจเปลี่ยนระหว่างรุ่น เปิด sandbox สำหรับ Bash จำกัด filesystem เป็น workspace และ network เป็น allowlist ยืนยัน canonical path เมื่อ dialog ขออ่าน external file โดยเฉพาะ symlink

ใช้ allowManagedPermissionRulesOnly เมื่อองค์กรต้องการ policy กลาง และจำกัด plugin ให้ official หรือ admin-vouched พร้อม lock version Review manifest, hooks, MCP config และ tool declarations ก่อนเปิดใช้ ไม่ให้ plugin เพิ่ม wildcard allow rule

MCP server ควรใช้ identity/credential แยก, scope ต่ำ, network segment แยก และ log elicitation โดย redact secret ตั้ง timeout และ disable server ที่ตอบผิด schema หรือขอข้อมูลเกินหน้าที่ อย่าส่ง environment ทั้งชุดให้ plugin/MCP โดยสะดวก

ทดสอบชุด adversarial ใน repository ปลอม: symlink จาก .claude/rules ออกนอก workspace, nested instructions, plugin ขอ preapprove shell, MCP ขอ secret, malformed markup ใน memory และ Bash ที่พยายามออก network ตรวจว่าระบบถามหรือปฏิเสธตาม policy จริง

ความเสี่ยงคงเหลือ

ผู้ใช้อาจอนุมัติ external read เพราะ path ดูคล้ายไฟล์งาน ทั้งที่ canonical target เป็นไฟล์ sensitive UI และ training ช่วยลดแต่ไม่กำจัด social engineering การอนุมัติครั้งเดียวก็พอให้ข้อมูลรั่วครั้งเดียว

Plugin หรือ MCP server ที่ได้รับ trust แล้วอาจถูกยึดภายหลัง Signature/provenance ลดโอกาส package ปลอมแต่ไม่หยุด malicious update จากบัญชี publisher ที่ถูกยึด ต้องมี pin, review diff และ kill switch

Sandbox ของ OS มีช่องโหว่ได้ และ tool ที่ไม่ได้ผ่าน Bash เช่น cloud API อาจเปลี่ยน state นอก filesystem boundary Permission design ต้องครอบคลุม semantics ของ tool ไม่ใช่เช็กแค่ process execution

Model output และ memory ยังอาจผิด ความปลอดภัยไม่เท่าความถูกต้อง ทีมต้องมี test, code review และ human decision สำหรับ production แม้ไม่มี advisory เปิดอยู่

ควรทำอะไร

ผู้ใช้เดี่ยวให้อัปใน environment ทดลอง ตรวจ claude version, effective permission และ sandbox แล้วเปิด repository ที่มี symlink test ดูว่าถามตามคาด ลบ token จาก shell environment ก่อนทดลอง plugin ใหม่

ทีม platform ควรทำ canary แยก terminal กับ VS Code เก็บ config snapshot ก่อน-หลัง และทดสอบ managed policy precedence เพิ่ม audit สำหรับ external read และ plugin preapproval โดยไม่เก็บเนื้อหาไฟล์ลับ

ทีม security ควรเทียบ plugin/MCP inventory กับ owner, version และสิทธิ์จริง ตรวจ advisory feed ต่อเนื่องและกำหนด SLA เมื่อมี high/critical ใหม่ สร้าง playbook revoke token และ disable plugin จากส่วนกลาง

ทีมที่ใช้ version ต่ำกว่า 2.1.163 ควรให้ความสำคัญกับ advisory เก่าด้วย ไม่ควรคิดว่าอัปเฉพาะ config แก้ binary bugได้ ส่วนทีม 2.1.281 ควรอ่าน breaking/default change ของ 2.1.284 ก่อน rollout

Recap

• 2.1.284 มี fix สำคัญที่ external symlink, plugin permission และ MCP block
• provenance และ digest ตรวจได้; advisory high เก่าถูกแก้ก่อน version นี้
• ผลคือผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ พร้อม residual risk
• กำหนด permission/sandbox explicit และตรวจ effective mode หลังอัป
• จำกัด plugin/MCP ด้วย version pin, least privilege และ kill switch
• ทดสอบ symlink, external read, managed rules, memory และ IDE แยกกัน