ระบบจัดคิวงานไปยังห้อง session แยกในห้องเขียวเข้ม โดยมีก้อนงานสีอำพันหนึ่งก้อนหลุดอยู่นอกห้อง
aiagent-toolsqwen-codesecurity-reviewnews

Qwen Code 0.24.6: managed runtime มาแล้ว แต่ sandbox ยังต้องตั้งเอง

น้องกายEngineering

Qwen Code 0.24.6 ออกเมื่อ 26 กันยายน 2026 พร้อม managed runtime, hosted harness, Agent View sessions, advisor และ batch API ขณะที่ฝั่งแก้บั๊กมีประเด็น permission aggregation ให้เลือกกฎที่เข้มที่สุดและรักษาพฤติกรรม CLI เดิม Release นี้จึงน่าสนใจสำหรับทีมที่กำลังย้าย agent จากเครื่องนักพัฒนาไปสู่ session ที่บริหารรวม แต่ต้องไม่ตีความคำว่า managed ว่า sandbox เปิดและซ่อน secret ให้อัตโนมัติครับ

ผมตรวจ release v0.24.6, เอกสาร settings, approval mode, sandbox, หน้า security advisories และ issue ที่ยังสะท้อน residual risk อย่าง 8136 กับ 7770 แบบอ่านอย่างเดียว ไม่รัน installer, server หรือ binary ใน repository จริง

สรุป 30 วินาที

  • 0.24.6 เพิ่ม managed runtime/hosted harness, session ใน Agent View, advisor และ batch API โดย release ระบุว่าไม่มี breaking change
  • permission aggregation ถูกแก้ให้เลือกผลที่ restrictive ที่สุดเมื่อมีกฎหลายชั้น ลดกรณีกฎกว้างกลบกฎแคบ
  • official release มี binary asset และ digest ให้ตรวจ provenance ได้
  • เอกสาร sandbox ระบุชัดว่าบน Linux ต้องตั้ง tool execution sandbox เอง การอ่านไฟล์ยังอาจกว้าง และ host secret ไม่ได้ถูกซ่อนเพียงเพราะเปิด sandbox
  • qwen serve หรือ hosted interface ไม่ใช่ OS security boundary โดยตัวมันเอง ต้องวาง authentication, network และ isolation เพิ่ม
  • ผลสรุป: ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ เพราะ provenance/version/advisory ผ่านและไม่มี default กว้างแบบปิดบังในหลักฐาน แต่ต้องตั้ง permission/sandbox explicit ก่อนใช้กับข้อมูลจริง

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

managed runtime ทำให้สร้าง session, รัน batch และดู agent จากส่วนกลางง่ายขึ้น ความง่ายนี้เปลี่ยน risk profile จาก “developer คนหนึ่งรัน CLI” เป็น “service รับงานหลายคนแล้วถือ tool/credential” หาก endpoint เปิดผิด network หรือ session isolation ไม่แข็ง ผู้โจมตีหนึ่งคนอาจมองเห็นงานของคนอื่น

permission aggregation ฟังเหมือนรายละเอียดเล็ก แต่กฎหลายชั้นพบได้จริง: user config อนุญาต shell, project config ปฏิเสธคำสั่งบางแบบ และ managed config จำกัด network หาก resolver เลือก allow ที่กว้างกว่ากฎ deny ระบบจริงต่างจากสิ่งที่ admin คิด การเลือก restrictive ที่สุดจึงเป็น default ที่สมเหตุผล แต่ต้อง test precedence กับ config ขององค์กร

ทีมที่ใช้ Qwen Code บน laptop ก็เกี่ยวข้อง เพราะ hosted feature อาจชวนให้เปิด qwen serve เพื่อดู session จากอุปกรณ์อื่น หาก bind ออก interface กว้างโดยไม่มี reverse proxy/auth ที่เหมาะสม dashboard จะกลายเป็นทางเข้าถึง agent context และ action

ทำงานยังไง

managed runtime แยก lifecycle ของ session ออกจาก terminal เดียว ทำให้สร้าง หยุด ดูสถานะ และส่งงานผ่าน harness ได้ เหมือนย้ายจากพ่อครัวทำที่บ้านไปครัวกลาง: จัดคิวและมองภาพรวมง่ายขึ้น แต่ต้องมีบัตรผ่าน แยกโต๊ะ และรู้ว่าใครหยิบวัตถุดิบของใคร

approval mode กำหนดว่า tool call ต้องถามผู้ใช้หรือทำได้อัตโนมัติ Permission rule ช่วยเจาะจง command/path/tool ส่วน sandbox เป็น boundary ของ OS/container ทั้งสามชั้นไม่แทนกัน Prompt อาจบอกไม่ให้แตะไฟล์ลับ แต่ถ้า filesystem มองเห็นและ approval auto ความผิดพลาดยังเกิดได้

เอกสาร sandbox ปัจจุบันบอกว่าการทำ sandbox บน Linux ต้อง configure tool execution และไม่ได้ซ่อน host secrets โดยปริยาย อีกทั้ง file read บางเส้นทางอาจยังเห็นกว้างกว่า write sandbox เปรียบเหมือนให้ช่างทำงานในห้องกระจก: เขาออกไปไม่ได้แต่ยังมองเห็นเอกสารที่วางรอบห้อง หาก prompt/tool สามารถส่งข้อมูลออก network ความลับก็ยังรั่วได้

advisor เพิ่มโมเดลหรือองค์ประกอบช่วยให้คำแนะนำกับ agent หลัก ส่วน batch API เพิ่ม throughput ทั้งคู่เพิ่ม trust edge: ต้องรู้ว่าข้อมูลถูกส่งไป provider ใด, เก็บนานเท่าไร, advisor มี tool หรือไม่ และผลแนะนำถูกนำไป execute แบบใด ไม่ควรให้คำแนะนำกลายเป็น permission

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

Repository QwenLM/qwen-code, publisher, tag v0.24.6 และ changelog เชื่อมกันตรง Release ถูกทำเครื่องหมาย stable และประกาศว่าไม่มี breaking changes ผมใช้ upstream release เป็นหลัก ไม่ใช้ package mirror หรือวิดีโอรีวิวเป็นแหล่ง provenance

Asset qwen-code-darwin-arm64.tar.gz แสดง SHA-256 dc05ea15500ecce363b1053b1f0b26a926a3385b40ce7dd75f01312951fd2866 และ cli.js แสดง SHA-256 02852e8826043d6bf0501d4249258c6201405aead40c3511f3f0a14ef3c35b71 ค่านี้ใช้เทียบไฟล์ที่ดาวน์โหลดจาก release เดียวกัน รอบนี้ไม่ได้ดาวน์โหลดจึงไม่ได้อ้าง local verification

หน้า official security advisories ไม่แสดง high/critical ที่ระบุว่ากระทบ 0.24.6 โดยไม่มี mitigation ณ 29 กันยายน 2026 ผมตรวจ issue 8136 และ 7770 เพื่อไม่ดูเฉพาะ advisory เพราะ bug/edge case บางเรื่องอาจยังไม่ถึงระดับ CVE หรือยังอยู่ระหว่าง triage Issue ไม่ใช่หลักฐานว่า exploit ได้ทุก environment แต่เป็นสัญญาณให้ทดสอบเส้นทางนั้น

เอกสาร settings/approval/sandbox เป็นหลักฐานว่า default permission ต้องอ่านตาม configuration และ sandbox ไม่ได้เป็น secret vault รุ่นนี้แก้ permission aggregation ให้ conservative ขึ้น แต่ไม่มีข้อความว่าทุก install เปิด OS sandbox โดยอัตโนมัติ

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

hosted session ลดเวลาจัดการด้วยมือและช่วย batch workload แต่เพิ่ม compute ที่ทำงานต่อเนื่อง ค่า model token, storage, log และ idle session อาจโต ทีมต้องกำหนด TTL, concurrency quota และ budget per project ไม่ให้ session ที่ orphan อยู่กินทรัพยากรเงียบ ๆ

ต้นทุน security คือ gateway, authentication, isolation, secret broker และ monitoring ถ้าประหยัดด้วยการ expose qwen serve ตรงแล้วใช้ token เดียวทั้งทีม ความเสียหายจาก token รั่วอาจใหญ่กว่าค่า infra ที่ประหยัดไป ระบบ managed ที่ดีต้องมี identity ต่อคน/งาน ไม่ใช่ shared credential

Batch API เพิ่มโอกาสทำงานจำนวนมากผิดพร้อมกัน หาก prompt หรือ target ผิดหนึ่งจุด การเปลี่ยนแปลงกระจายหลาย repository ก่อนคนเห็น ต้องมี dry-run, sample, rate limit และ stop control พร้อมค่าใช้จ่ายสูงสุดต่อ batch

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

Release เรียกความสามารถใหม่ว่า managed runtime/hosted harness แต่เอกสาร sandbox เตือนว่า qwen serve ไม่ใช่ OS security boundary และต้องตั้ง sandbox เอง สองข้อความไม่ขัดกันทางเทคนิค ทว่าอาจสร้างความเข้าใจต่างกัน: managed หมายถึงบริหาร lifecycle ไม่ได้หมายถึง isolation ครบ

คำว่า “most restrictive permission aggregation” ต้องทดสอบกับ wildcard, command argument, path canonicalization, MCP tool และ config precedence จริง Release note ไม่ให้ truth table ครบทุกคู่กฎ จึงยังไม่ทราบว่ากรณีซับซ้อนทั้งหมดมีผลตามที่องค์กรคาด

issue 8136 และ 7770 แสดงว่าชุมชนยังพบ edge case บางส่วน แต่สถานะ issue เปลี่ยนได้และไม่ได้มี severity/provenance เท่า advisory ทีมควรอ่าน reproduction และ maintainer response ล่าสุดก่อนตัดสิน ไม่ควรแปลงจำนวน issue เป็นคะแนนความปลอดภัย

ยังไม่ชัดจากหลักฐานที่ตรวจว่า hosted deployment ทุกแบบแยก tenant/session ระดับใด มี encryption/retention/SLA อย่างไร และ advisor provider ส่งข้อมูลข้าม region หรือไม่ เรื่องเหล่านี้ขึ้นกับ deployment และ config มากกว่าเลข CLI version

ไม่มี signature/checksum story เดียวกันทุกช่องทางติดตั้ง Digest ของ GitHub asset ไม่ยืนยันแพ็กเกจจาก registry อื่น ทีมต้องตรวจ provenance ของช่องที่ใช้จริง

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

ติดตั้งจาก official release หรือ registry ที่องค์กรอนุมัติ pin 0.24.6 และตรวจ digest/signature ตามช่องทาง ห้าม pipe remote script เข้า shell ในเครื่องที่มี repo/credential สำคัญ เริ่มใน VM/container ที่ไม่มี private network

กำหนด approval mode และ permission rule explicit ให้ default เป็นถามหรือปฏิเสธสำหรับ shell, write, network และ MCP action ทดสอบว่า managed, user และ project rule รวมกันแล้วได้ผล restrictive ที่สุด อย่าให้ repository ที่ไม่ไว้ใจเปลี่ยน managed policy

เปิด tool execution sandbox เองตาม platform จำกัด workspace mount เป็น read-only เท่าที่ทำได้ แยก writable output และห้าม mount home, SSH, cloud config, browser profile หรือ secret store ทั้งก้อน จำไว้ว่า read access ก็เป็น risk เมื่อ network เปิด

ถ้ารัน qwen serve ให้อยู่ private interface หลัง reverse proxy ที่มี TLS, strong authentication, CSRF/origin control, rate limit และ audit แยก process/user ต่อ tenant หรือ project ไม่ใช้ server process เดียวถือ credential ทุก environment

ใช้ short-lived scoped credential ต่อ session, inject เฉพาะตอน tool ต้องใช้ และ revoke เมื่อจบ Batch ต้องมี maximum items/cost, dry-run, approval ก่อน commit/publish และ kill switch ที่ไม่ต้องผ่าน agent

ติดตาม advisories และ issue ที่เกี่ยวกับ permission/sandbox ต่อเนื่อง พร้อม SBOM/dependency scan ของ build ที่ใช้ การไม่มี advisory วันนี้ไม่ใช่เหตุผลให้หยุด monitor

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

Prompt injection จาก code, issue, web หรือ MCP result ยังทำให้ agent ขอ action ที่ดูสมเหตุผลได้ Approval fatigue ทำให้ผู้ใช้กดยอมรับโดยไม่อ่าน และ auto mode ขยายผลเร็วกว่า interactive mode

Sandbox misconfiguration อาจเปิด path หรือ network เกินตั้งใจ Host secrets ที่ agent อ่านได้อาจหลุดผ่าน output, log หรือ request แม้ write ถูกบล็อก Container escape และ kernel vulnerability ก็ยังเป็น residual risk

Hosted server เพิ่มความเสี่ยง auth bypass, session mix-up, stale session และ denial of service ตัว CLI ผ่าน gate ไม่ได้แปลว่า deployment architecture ผ่านด้วย ต้อง threat-model server, proxy, database และ model provider แยก

Digest ยืนยันความตรงของ artifact กับ metadata ไม่ยืนยันความปลอดภัยของ source และ publisher account อาจถูกยึดในอนาคต Issue ที่ยังเปิดหรือ advisory ใหม่สามารถเปลี่ยนข้อสรุปหลัง verifiedAt

ควรทำอะไร

ผู้ใช้เดี่ยวควรใช้ interactive approval และ sandbox ใน repository ที่เชื่อถือได้ก่อน ตรวจ environment variable ที่ process เห็นและปิด network เมื่อไม่ต้องใช้ อย่าเปิด serve ออก LAN เพื่อความสะดวก

ทีม platform ให้ทำ canary hosted session ด้วยข้อมูลปลอม ทดสอบ tenant/session isolation, reconnect, cancellation, orphan cleanup, policy precedence และ batch stop วัดทั้ง functionality กับ audit completeness

ทีม security ควรสร้าง adversarial repository ที่มี symlink, nested config, prompt injection และ MCP response หลอก ตรวจว่า read/write/network/secret boundary ทำงานจริง Review issue 8136/7770 ตามสภาพแวดล้อมและบันทึก accepted residual risk

ทีม procurement/compliance ต้องถาม data retention, region, subprocess isolation, artifact provenance และ incident notification ของ deployment ที่เลือก เพราะเอกสาร CLI ไม่ตอบ service contract ทั้งหมด

Recap

  • 0.24.6 มี provenance/tag/digest ชัดและแก้ permission aggregation ให้ restrictive
  • ผลคือผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ แต่ไม่ได้เปิด sandbox ให้ทุกระบบอัตโนมัติ
  • managed runtime คือ lifecycle control ไม่ใช่ OS boundary
  • จำกัด file read, shell, network, MCP และ secret แยกกัน
  • ป้องกัน qwen serve ด้วย auth/network isolation และแยก session
  • ตั้ง batch quota, dry-run, approval และ kill switch ก่อนใช้จริง