Claude Code 2.1.288 อุดช่อง Bash permission และ hook fail-open—อัปเดตแล้วก็ยังต้องจำกัดสิทธิ์

Claude Code 2.1.288 ออกวันที่ 3 ตุลาคม 2026 เวลาไทย พร้อมแก้เส้นทางที่คำสั่ง rm อันตรายใน bash -c หรือ sh -c อาจรันโดยไม่ถามเมื่อใช้ bypass permissions หรือ shell allow rule ครับ รุ่นนี้ยังเปลี่ยนให้ PreToolUse และ PermissionRequest hook บล็อกคำสั่ง เมื่อการ match หรือ serialize input ล้มเหลว แทนการข้าม hook ซึ่งเป็นทิศทาง fail-closed ที่สำคัญกว่าฟีเจอร์หน้าจอหลายข้อใน changelog

ผมตรวจแบบอ่านอย่างเดียวจาก release ทางการ, feed ที่ผูก tag, metadata ของ npm, เอกสารสิทธิ์/ความปลอดภัย และ รายการ advisory ไม่ได้รัน installer, package, plugin, MCP server หรือ Claude Code binary กับ repository นี้ และไม่ได้ให้เครื่องมือเข้าถึง credential หรือ private network ผลสรุปคือ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ไม่ใช่คำรับรองว่าปลอดภัยทุกสภาพแวดล้อม

สรุป 30 วินาที

• รุ่น 2.1.288 เป็น release ทางการ immutable tag v2.1.288 commit 1c229fc และ npm registry ระบุรุ่นเดียวกันเป็น latest ตอนตรวจ
• npm metadata มี integrity แบบ SHA-512 sha512-tnc8XuK5xQkyE6oowhhSPIjLuNc0S3MkjIHqycDsKP6yJlLtIjMt6v1TOkYLUiumcZ9jOgJZ6h9Vn3/f0murdQ== พร้อม registry signatures สองรายการภายใต้ key id เดียวกัน
• จุดความปลอดภัยหลักคือถาม permission ก่อนคำสั่งลบอันตรายที่ซ่อนใน shell string แม้อยู่ใน bypass/allow path และเปลี่ยน hook matching/serialization failure ให้ block
• รุ่นนี้ยังแก้ MCP tool call ที่อาจรันซ้ำเมื่อผลเกิน 16 MB หรือ parse ไม่ได้, เพิ่ม re-authentication เมื่อ MCP ขอ OAuth scope มากขึ้น และแก้ login ที่เคยรายงานสำเร็จแม้เก็บ credential ไม่ได้
• อย่างไรก็ตาม --dangerously-skip-permissions ยังมีอยู่, plugin/mod/hook ยังรัน logic เพิ่ม, MCP และ network ยังขยายขอบเขตสิทธิ์ และ shell allow rule ที่กว้างยังเสี่ยง
• คำแนะนำคืออัปเดตจากรุ่นก่อน แล้วใช้ workspace ที่แยก, permission allowlist แคบ, network/secret จำกัด และ human approval สำหรับคำสั่งทำลายหรือส่งข้อมูลออก

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

coding agent ต่างจาก autocomplete เพราะมันอ่านไฟล์ รัน shell แก้ repository และเรียกเครื่องมือภายนอกได้ Bug ในชั้น permission จึงไม่ได้ทำให้คำตอบผิดอย่างเดียว แต่อาจลบไฟล์ ส่งข้อมูล หรือข้าม approval ที่ทีมคิดว่ามีอยู่

ถ้าทีมใช้ allow rule เช่นอนุญาต bash -c กว้าง ๆ เพื่อไม่ต้องกดยืนยันบ่อย ช่องโหว่ใน parser ของคำสั่งย่อยทำให้ rule นั้นเหมือนบัตรผ่านประตูหน้าที่เปิดห้องเก็บของทุกห้องครับ Release note ของ 2.1.288 ยกตัวอย่างคำสั่งลบ / หรือ home directory และผูกกับ issue #96300 จึงเป็นเหตุผลให้อัปเดตแม้ทีมไม่สนฟีเจอร์ใหม่

คนที่ใช้ hook เพื่อ enforce policy ก็ควรสนใจ การข้าม PreToolUse หรือ PermissionRequest เมื่อ match/serialization พัง คือ fail-open: กลอนเสียแล้วประตูเปิด รุ่นนี้เปลี่ยนให้ call ถูกบล็อก ซึ่งลด class ความเสี่ยง แต่ทีมยังต้องทดสอบว่า hook ของตัวเองรับ schema จริงและไม่สร้าง denial-of-service จาก input ที่คาดไม่ถึง

ทำงานยังไง: parser, policy และ executor ต้องเห็นคำสั่งเดียวกัน

ระบบ permission มีอย่างน้อยสามชั้น: รับ tool call, วิเคราะห์ว่าตรง rule ใด และส่งคำสั่งให้ shell รัน ถ้าชั้นวิเคราะห์เห็นเพียง bash -c ที่อนุญาต แต่ shell เห็น script ด้านในซึ่งมีคำสั่งทำลาย การตัดสินใจของ policy ก็ใช้ภาพคนละใบกับ executor

อุปมาเหมือนด่านตรวจรถบรรทุกครับ เจ้าหน้าที่อ่านใบหน้ากล่องว่า “ของใช้สำนักงาน” แต่ไม่ได้เปิดดูว่าข้างในเป็นสารอันตราย Fix ที่ดีต้องทำให้ด่านตรวจเข้าใจ payload ที่จะถูกขนจริง หรือหยุดถามคนเมื่อวิเคราะห์ไม่ได้ รุ่น 2.1.288 ระบุว่าคำสั่ง rm อันตรายใน shell script จะถามก่อนแม้อยู่ใน bypassPermissions หรือ allow rule

ส่วน hook เป็นด่านเสริมที่องค์กรเขียนเอง PreToolUse ตรวจและอาจ block ก่อน tool รัน ขณะที่ PermissionRequest แทรกในเส้นทางขอสิทธิ์ รุ่นนี้เปลี่ยน failure จาก matching หรือ JSON serialization ให้ call ถูก block นั่นคือ fail-closed แต่ไม่ทำให้ hook ถูกต้องอัตโนมัติ หาก hook เชื่อข้อมูลจาก repository ที่ไม่ไว้ใจหรือเรียก network โดยถือ secret มันยังสร้างช่องใหม่ได้

MCP เพิ่มอีกขอบเขตหนึ่ง Release note แก้กรณี result ใหญ่กว่า 16 MB หรือ parse ไม่ได้แล้ว tool call อาจรันซ้ำ การรันซ้ำเป็นเรื่องเล็กเมื่อ tool อ่านข้อมูล แต่หนักเมื่อ tool ส่งข้อความ สร้าง ticket หรือแก้ระบบภายนอก ทีมจึงต้องออกแบบ idempotency ที่ tool ฝั่ง server ด้วย ไม่พึ่ง client fix ชั้นเดียว

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

Publisher และ release provenance: repository anthropics/claude-code เผย release v2.1.288 เป็น immutable release และ feed ทางการชี้ tag เดียวกัน พร้อมเวลาปล่อย 2026-10-02T20:19:38Z ซึ่งตรงกับเช้าวันที่ 3 ตุลาคมในกรุงเทพฯ

Package provenance: npm registry ให้ @anthropic-ai/[email protected] เป็น latest ตอนตรวจ มี SHA-512 integrity และ signatures สองรายการ เราอ่าน metadata เท่านั้น ไม่ดาวน์โหลด tarball หรือรัน postinstall จึงยืนยันได้ว่า registry มีข้อมูล integrity แต่ไม่ได้พิสูจน์พฤติกรรม runtime ทุก path

Advisories: หน้าความปลอดภัยของ repository มี advisory ระดับ High/Moderate ในอดีต เช่น worktree path confusion, trust bypass, symlink write และ SSH host verification รุ่นที่ตรวจสูงกว่าช่วง patched ของ advisory ที่เปิดเผยซึ่งอ่านได้ ณ เวลาตรวจ ไม่พบ known High/Critical advisory ที่ระบุว่า 2.1.288 ยังอยู่ใน affected range แต่รายการ advisory เปลี่ยนได้หลังวันตรวจ

Install/update path: เอกสาร Anthropic ระบุเส้นทางติดตั้งมาตรฐานและเตือนไม่ใช้ sudo npm install -g; ระบบมี auto-update หลายรูปแบบ รุ่นนี้แก้กรณี npm auto-updater รายงานสำเร็จทั้งที่ native binary ดาวน์โหลดล้มเหลว ทีมจึงควรตรวจ claude --version หลังอัปเดต แต่อย่ารัน installer จากบทความนี้ตรง production

Filesystem และ shell: เอกสาร permission รองรับ allowed/disallowed tools และ permission modes แต่ CLI ยังมี --dangerously-skip-permissions ซึ่งข้าม prompt ตามชื่อ รุ่น 2.1.288 ลดช่อง parser บางแบบ ไม่ได้ทำให้ bypass mode กลายเป็น least privilege

Network, MCP และ secret: MCP server ขอ OAuth scope เพิ่มได้และรุ่นนี้เพิ่ม re-authentication prompt ระหว่าง tool call เอกสาร security แนะนำ sandbox/permission controls แต่ connection ภายนอกยังเห็นข้อมูลตามสิทธิ์ที่ผู้ใช้มอบ Login และ cloud session มี credential flow ของตัวเอง จึงต้องแยกบัญชีและจำกัด secret ใน subprocess

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

release note บอกพฤติกรรมที่แก้ แต่ไม่ได้ให้ CVE หรือ severity สำหรับ issue rm ในเวลาที่ตรวจ เราจึงไม่เรียกมันว่า Critical/High อย่างเป็นทางการ แม้ผลกระทบเชิงศักยภาพสูง โดยเฉพาะเมื่อผู้ใช้เปิด bypass permissions

npm integrity และ signature ยืนยันข้อมูลจาก registry ตามกลไกที่เผยแพร่ แต่ไม่ได้เท่ากับ reproducible build จาก source ถึง binary ทุกแพลตฟอร์ม หน้า release มี assets หลายแบบและเราไม่ได้ดาวน์โหลดมา hash เทียบใน run นี้ จึงยังเหลือช่องว่าง supply-chain ระหว่าง source, package และ native binary

เอกสาร permission อธิบาย control ที่ตั้งได้ ขณะที่ release note แสดงว่ามี bug ในการตีความ rule จริง สองแหล่งไม่ขัดกันตรง ๆ แต่เตือนว่าการมี control ในเอกสารไม่พอ ต้อง regression test คำสั่งซ้อน, shell string, symlink, worktree และ tool input ผิดรูปด้วย

ยังไม่รู้ว่ามี exploit ที่ใช้ช่อง rm นี้ใน production จริงกี่ครั้ง ไม่มีข้อมูล telemetry สาธารณะที่ตอบ และไม่ควรสรุปว่าไม่เคยถูกใช้เพียงเพราะไม่มีรายงาน ทีมที่เคยรัน bypass mode ควรตรวจ shell history, agent transcript และ file recovery evidence ตาม retention ที่มี

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

1. อัปเดตในเครื่องทดลองก่อน แล้วตรวจ version จริงหลัง updater จบ อย่าเชื่อข้อความ success อย่างเดียว
2. ปิด --dangerously-skip-permissions เป็นค่าเริ่มต้น ใช้ plan/read-only mode สำหรับ repository ที่ยังไม่ trust และให้ workspace write เฉพาะงานที่ต้องแก้ไฟล์
3. เปลี่ยน shell allow rule จากคำกว้าง เช่น bash:* เป็นคำสั่ง/argument ที่จำเป็น แยกคำสั่งลบ ย้าย permission หรือ network egress ให้อนุมัติทุกครั้ง
4. รัน agent ใน worktree หรือ container ที่ไม่มี production credential, SSH agent, cloud token และ home directory จริง mount อยู่โดยไม่จำเป็น
5. allowlist MCP server ตาม publisher และ scope ตรวจ OAuth scope ทุกครั้งที่เพิ่ม ไม่กดยอมเพราะ prompt โผล่ระหว่างงานเร่ง
6. ทำ tool ที่มี side effect ให้ idempotent ด้วย request id โดยเฉพาะการสร้าง issue ส่งข้อความ จ่ายเงิน หรือ deploy เพราะ client/network retry ยังเกิดได้
7. ทดสอบ hook ให้ fail-closed ด้วย input ที่ serialize ไม่ได้, schema เปลี่ยน และ timeout พร้อม alert เมื่อ hook block มากผิดปกติ
8. เก็บ transcript และ audit เท่าที่นโยบายอนุญาต แต่ redact secret และกำหนดอายุข้อมูล เพราะ log ที่ละเอียดเกินไปอาจกลายเป็นคลัง credential

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

แม้อัปเดตแล้ว ผู้ใช้ยังสามารถให้สิทธิ์ shell, filesystem, network, MCP, plugin และ mod กว้างกว่าที่งานต้องใช้ Prompt injection จาก repository หรือผล tool ภายนอกอาจชักนำ agent ให้ขอสิทธิ์เพิ่ม และคนอาจกดยอมเพราะ approval fatigue

Sandbox ไม่ครอบคลุมทุก platform/path เหมือนกัน และประวัติ advisory แสดงว่าขอบ worktree, symlink, trust dialog กับ temporary file เคยเป็นพื้นที่ผิดพลาด ระบบที่ mount home หรือ credential เข้า sandbox จึงยังเสี่ยงหาก boundary มี bug ใหม่

Plugin/mod เพิ่ม code และ UI behavior ที่ไม่อยู่ใน core release review ชุดเดียว Release 2.1.288 เพิ่ม API สำหรับ mods และแก้ plugin หลายจุด ยิ่ง ecosystem ขยาย ยิ่งต้อง pin source, review update และแยก permission ของ extension

Cloud/remote session, telemetry และ gateway มีเส้นทางข้อมูลนอกเครื่อง การจำกัด local filesystem ไม่ได้ตอบ retention, region หรือ operator access ทั้งหมด องค์กรต้องอ่าน commercial terms และตั้ง policy ของบัญชีจริง

สุดท้าย known advisory คือข้อมูลย้อนหลัง ไม่ใช่เรดาร์สมบูรณ์ รุ่นนี้จึง ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ เพราะ provenance ชัด มี integrity/signature, ไม่พบ advisory High/Critical ที่ประกาศว่ากระทบรุ่นนี้โดยไม่มี mitigation และ permission risk ถูกเปิดเผย แต่ความเสี่ยงคงเหลือยังสูงพอให้ใช้ least privilege และ human review ต่อไป

ควรทำอะไร

ผู้ใช้เดี่ยว อัปเดตเป็น 2.1.288 หรือใหม่กว่าที่ผ่าน change review สำรองงานสำคัญ และเลิก alias ที่เปิด bypass permissions อัตโนมัติ

ทีมแพลตฟอร์ม สร้าง policy profile แยก read-only, workspace-write และ network-enabled พร้อม test suite สำหรับ nested shell, symlink, worktree และ hook failure ตรวจ version drift จาก registry กับเครื่องจริง

ทีม security ค้น transcript เก่าที่มี bash -c, sh -c, rm, hook error หรือ tool retry ผิดปกติ โดยไม่รัน payload ซ้ำ และเปิด incident review หากพบการลบ/ส่งข้อมูลที่ไม่มี approval

ทีมที่ใช้ MCP/plugin ทำ inventory publisher, version, scope และ secret path ปิดของที่ไม่ใช้ และบังคับ re-authentication เมื่อ scope เพิ่ม อย่าให้ plugin marketplace update เงียบใน production workflow

ผู้ดูแล CI ใช้ token อายุสั้นและสิทธิ์ต่ำ แยก runner จาก production และตั้ง timeout/idempotency สำหรับ action ทุกตัว การอัปเดต agent ไม่แทน branch protection หรือ review gate

การแก้ permission bug ครั้งนี้เป็นข่าวดีครับ แต่บทเรียนที่สำคัญกว่าคือ policy engine ไม่ควรเป็นกำแพงชั้นเดียว สิ่งที่ควรจับตาต่อคือ advisory ใหม่และ regression ของ shell/MCP paths คุณมี test ที่พิสูจน์หรือยังว่าคำสั่งทำลายจะหยุดถามคนเมื่อ parser อ่านไม่ออก

Recap

• Claude Code 2.1.288 เป็น immutable official release และ npm latest ตอนตรวจ
• npm มี SHA-512 integrity และ registry signatures; run นี้ไม่ดาวน์โหลดหรือรัน package
• รุ่นนี้ถามก่อน dangerous rm ใน shell string และ block เมื่อ permission hook วิเคราะห์ไม่ได้
• MCP duplicate-call, OAuth scope escalation และ credential-save feedback ได้รับการแก้/ปรับ
• ไม่พบ advisory High/Critical ที่ประกาศว่ากระทบ 2.1.288 โดยไม่มี mitigation ณ วันที่ตรวจ
• ปิด bypass permissions, ใช้ allowlist แคบ และแยก worktree/credential/network
• Residual risk ยังอยู่ที่ shell, plugin/mod, MCP, symlink/worktree, cloud session และ prompt injection
• สรุปได้เพียง “ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ” ไม่ใช่การรับรองความปลอดภัย