ปลอดภัยพอใช้ ถ้ารันเวอร์ชันล่าสุด เปิดให้เข้าได้แค่จากเครื่องตัวเอง (127.0.0.1) และเปลี่ยนค่า default ที่ใครก็รู้แล้ว แต่จะเสี่ยงสูงถ้าเปิดพอร์ตออก network, เปิด tunnel, วาง reverse proxy ไว้ข้างหน้าด้วยเวอร์ชันเก่า หรือเอา token ของ subscription ที่จ่ายเงินจริงมาใส่ ตั้งแต่พฤษภาคมถึงกรกฎาคม 2026 9Router ประกาศช่องโหว่ไปแล้ว 19 รายการ ซึ่งแก้ไปแล้วทั้งหมดในเวอร์ชันหลัง 0.5.55 แต่ยังมีจุดอ่อนเชิงออกแบบบางข้อที่ code ล่าสุดยังมีอยู่ (ข้อมูล ณ 30 ตุลาคม 2026)
ผมเขียนวิธีติดตั้งและใช้งาน 9Router ไว้ใน
บทความหลักเรื่อง 9Routerแล้ว บทความนี้ตอบคำถามที่หลายคนถามตามมา คือ
มันปลอดภัยไหมผมไม่ได้อยากเขียนให้ใครเลิกใช้ และไม่ได้อยากบอกว่าไม่มีอะไรต้องห่วง แค่อยากเอาข้อเท็จจริงจากประกาศของโปรเจกต์เอง, code ล่าสุด และ audit อิสระมาวางให้ดูครบๆ แล้วตามด้วยวิธีตั้งค่าที่ทำได้เลย
ขอบอกก่อนว่าผมเองไม่ได้อยู่ในกลุ่มที่ปลอดภัยที่สุด ผมดูแล 9Router ที่รันด้วย Docker เป็น
เซิร์ฟเวอร์ให้คนในทีมใช้ผ่านโดเมน ไม่ใช่แค่ localhost บทความนี้จึงเขียนจากมุมของคนที่ต้องตั้งค่าให้รัดกุมจริงๆ
ทำไม 9Router ต้องระวังเรื่องความปลอดภัยมากกว่าเครื่องมือทั่วไป?
เพราะมันนั่งอยู่ตรงกลางระหว่างเครื่องมือเขียนโค้ดกับ provider ทุกเจ้า ของที่ผ่านมือมันมีทั้ง:
API key ของ provider และ
OAuth token ของ subscriptionอย่าง Claude, Codex หรือ Copilot
prompt, โค้ด และไฟล์ที่ AI อ่าน ทุก request
ถ้าเปิดฟีเจอร์ MITM มันจะติดตั้ง
root certificateลงเครื่อง และเก็บ
รหัสผ่าน sudoไว้ด้วย
ใครเจาะ 9Router ได้ ก็เท่ากับได้บัญชี AI ของเราไปใช้ หรือแย่กว่านั้นคือสั่งรันคำสั่งบนเครื่องเราได้ ช่องโหว่ของเครื่องมือแบบนี้จึงหนักกว่าช่องโหว่ของแอปทั่วไป
9Router มีช่องโหว่อะไรบ้างในปี 2026?
ตามหน้า Security Advisories บน GitHub ของ 9Router มีประกาศทั้งหมด
19 รายการระหว่าง 13 พฤษภาคม ถึง 16 กรกฎาคม 2026 เป็นระดับ critical 6 รายการ, high 11 และ medium 2 ส่วนใหญ่มีคนนอกรายงานเข้ามาและแก้กันแบบเปิดเผย ผมจัดกลุ่มตามประเภทไว้แบบนี้:
ประเภท | จำนวน | ตัวอย่างที่สำคัญ | แก้แล้วตั้งแต่ |
|---|---|---|---|
รันคำสั่งบนเครื่องจากระยะไกล (RCE) | 4 | route ของ MCP plugin ไม่มีการตรวจสิทธิ์ (CVE-2026-46339) และ route ติดตั้ง Tailscale ที่ส่งข้อมูลเข้า sudo sh ได้โดยไม่ล็อกอิน | 0.5.2 |
ข้ามการยืนยันตัวตน (auth bypass) | 9 | JWT secret สำรองที่ hardcode ไว้ (CVE-2026-49352), ปลอม header Host หรือ X-9r-Real-Ip ให้ดูเหมือนมาจาก localhost, nginx ส่งต่อผ่าน 127.0.0.1 แล้วถูกนับเป็น local (CVE-2026-56675) | 0.5.55 (ตัวแก้ X-9r-Real-Ip ที่สมบูรณ์) |
ข้อมูลลับรั่ว (secret leak) | 2 | /api/providers แก้ไขได้โดยไม่ล็อกอิน และ API key หลุดทาง /api/usage/stats, import/export ฐานข้อมูลขโมย credential ได้ทั้งหมด (CVE-2026-55500) | 0.4.80 |
SSRF (หลอกให้เซิร์ฟเวอร์ยิง request ไปที่อื่น) | 4 | /v1/web/fetch, image prefetch ผ่าน DNS rebinding (CVE-2026-56676), การทดสอบ OIDC provider (CVE-2026-56677) | 0.5.6 |
(14 สิงหาคม 2026) เพราะเป็นเวอร์ชันที่ปิดการเชื่อ header X-9r-Real-Ip แบบสมบูรณ์ และไม่ยอมออก session ให้คนที่ล็อกอินจากระยะไกลด้วยรหัสผ่าน default อีกต่อไป แต่ในทางปฏิบัติ
ใช้ตัวล่าสุดเลยซึ่งตอนที่เขียนคือ 0.5.112
ข้อสังเกตเล็กน้อยสำหรับคนที่จะไปอ่านประกาศเอง: บางประกาศเว้นช่องเวอร์ชันที่แก้ไว้ หรือเขียนว่า "none yet" ทั้งที่ code ปัจจุบันปิดไปแล้ว และหลายเวอร์ชันที่ประกาศอ้าง (เช่น 0.4.44, 0.4.82, 0.5.6) ไม่เคยออกบน npm เลย ถ้าคุณติดตั้งผ่าน npm จึงควรดูแค่ว่าเวอร์ชันของคุณ
ใหม่กว่าเลขนั้น
Audit อิสระของ StationX พบอะไร และ code ล่าสุดยังมีอยู่ไหม?
StationX เผยแพร่รีวิวชื่อ "9router Review: Is It Safe?" ในเดือนกรกฎาคม 2026 เป็นการอ่าน source code ณ commit หนึ่งของเดือนนั้น ไม่ใช่การเจาะระบบจริง ข้อสรุปของเขาคือ
ยังไม่ควรเอา credential จริงมาผ่าน 9Routerแต่ก็บอกชัดว่า
ไม่พบหลักฐานว่าเป็น malware หรือส่ง key ไปให้ผู้พัฒนาและถ้ารันบน localhost คนเดียวโดยปิด tunnel ความเสี่ยงจริงก็ต่ำ
เมื่อเทียบข้อที่เขาเจอกับ code ล่าสุด (master วันที่ 28 ตุลาคม 2026, เวอร์ชัน 0.5.112) ได้ผลแบบนี้:
สิ่งที่ StationX พบ | สถานะใน code ล่าสุด |
|---|---|
ฟีเจอร์ MITM ปิดการตรวจ TLS certificate ตอนส่งต่อไปยัง provider จริง | ยังอยู่ (มีผลเฉพาะตอนเปิด MITM) |
OAuth token และ API key ของ provider เก็บใน SQLite แบบไม่เข้ารหัส | ยังอยู่ |
รหัสผ่าน sudo ที่ cache ไว้ เข้ารหัสด้วย key ที่สร้างจาก machine ID กับ salt ที่ hardcode ไว้ | ยังอยู่ |
รหัสผ่าน default 123456 ออก session ให้ได้แม้ล็อกอินจากระยะไกล | แก้แล้ว: ล็อกอินจากระยะไกลด้วยรหัส default จะถูกปฏิเสธ (บนเครื่องตัวเองยังใช้ได้) |
ปิด requireLogin แล้ว API ที่มีข้อมูลลับไม่ต้องล็อกอิน | ยังเป็นแบบนั้นโดยตั้งใจ แต่ route อันตรายที่สุดยังจำกัดให้เข้าจาก localhost เท่านั้น |
Tunnel วิ่งผ่าน relay ที่ผู้พัฒนาดูแล | ยังอยู่ แต่ปิดเป็นค่าเริ่มต้น |
อัปเดตตัวเองโดยไม่ตรวจลายเซ็น | แค่บางส่วน: เช็กเวอร์ชันใหม่อัตโนมัติ แต่จะติดตั้งก็ต่อเมื่อเรากดเอง และไม่มีการตรวจอะไรเพิ่มจาก npm |
private key ของ root CA เขียนลงดิสก์โดยไม่จำกัดสิทธิ์ไฟล์ | ยังอยู่ (สร้างเฉพาะตอนใช้ MITM) |
ไม่มี lockfile | ยังอยู่ |
มีอีกข้อใน code ที่ StationX ไม่ได้พูดถึง ตั้งแต่เวอร์ชัน 0.5.95 ถ้าการเชื่อมต่อไปยัง provider เจอ TLS certificate ที่ไม่ผ่าน 9Router จะ
ลองใหม่โดยไม่ตรวจ certificateเพื่อให้ใช้ได้หลัง proxy หรือ antivirus ของบริษัท ปิดพฤติกรรมนี้ได้ด้วย environment variable STRICT_SSL=true (ตัวแปรนี้ยังไม่มีใน README) ใน instance ที่ผมดูแล ผมกลับค่าเริ่มต้นนี้ให้ตรวจ certificate เสมอ เพราะ retry แบบนี้ครอบคลุมทั้งการแลก OAuth token และทุก request ที่มี key ของ provider
สรุปจากตารางนี้: ช่องโหว่ที่คนนอกเจาะได้จากระยะไกลถูกแก้ไปเยอะแล้ว ส่วนที่เหลือเป็นเรื่อง
การเก็บความลับบนเครื่องและ
ฟีเจอร์ MITMซึ่งเราจัดการเองได้ด้วยการตั้งค่า

ตั้งค่า 9Router ให้ปลอดภัยต้องทำอะไรบ้าง?
ทำตามลำดับนี้ ข้อ 1–5 สำคัญที่สุด ทุกคนควรทำ:
- 1.อัปเดตเป็นเวอร์ชันล่าสุด
อย่างน้อย 0.5.55
npm install -g 9router@latest # หรือ docker pull decolua/9router:latest - 2.Bind แค่ 127.0.0.1
ค่าเริ่มต้นของ CLI คือ 0.0.0.0 ซึ่งแปลว่าเครื่องอื่นใน Wi-Fi เดียวกันก็เข้าได้ (ตัว CLI จะขึ้นคำเตือน "Network-exposed" ให้เห็น) ถ้าใช้ Docker ให้ผูกพอร์ตไว้ที่ 127.0.0.1 ฝั่ง host
9router --host 127.0.0.1 # หรือ Docker docker run -d -p 127.0.0.1:20128:20128 -v "$HOME/.9router:/app/data" decolua/9router - 3.ตั้งรหัสผ่านใหม่ทันที
INITIAL_PASSWORD ใช้ได้แค่ก่อนบันทึกรหัสผ่านครั้งแรก ถ้าไม่ได้ตั้งไว้ รหัสจะเป็น 123456 ให้เข้า dashboard จากเครื่องตัวเองแล้วเปลี่ยนเลย
- 4.เปิด "Require API key"
ในหน้า Dashboard → Endpoint ข้อนี้ต้องระวัง README ยังเขียนถึง environment variable REQUIRE_API_KEY แต่ code ปัจจุบันไม่ได้อ่านตัวแปรนี้แล้ว ใช้สวิตช์ในหน้า dashboard แทน
- 5.อย่าปิด requireLogin
ถึงจะใช้คนเดียวก็ตาม เพราะถ้าวันหนึ่งเปิด tunnel ขึ้นมา API ที่มีข้อมูลลับจะไม่ต้องล็อกอิน
- 6.ตั้ง secret ของตัวเอง
JWT_SECRET ไม่ต้องตั้งก็ได้ เพราะเวอร์ชันใหม่สุ่มให้และเก็บไว้ใน DATA_DIR/jwt-secret แล้ว (ช่องโหว่ CVE-2026-49352 คือของเวอร์ชันเก่าที่ใช้ค่าสำรองแบบ hardcode) ตั้งเองเฉพาะตอนต้องใช้หลาย instance ร่วมกัน ส่วน API_KEY_SECRET และ MACHINE_ID_SALT มีค่า default เป็นข้อความคงที่ที่อยู่ใน README ควรสุ่มค่าใหม่ก่อนสร้าง API key ตัวแรก
openssl rand -hex 32 - 7.ปิด tunnel ถ้าไม่ได้ใช้
ซึ่งปิดเป็นค่าเริ่มต้นอยู่แล้ว ถ้าจำเป็นต้องเปิด ให้ปิด "dashboard access" ผ่าน tunnel ด้วย เพราะค่าเริ่มต้นของตัวเลือกนี้คือเปิด และจำไว้ว่า tunnel แบบ Cloudflare วิ่งผ่าน relay ของบุคคลที่สาม
- 8.ไม่เปิด MITM ถ้าไม่จำเป็น
ฟีเจอร์นี้ติดตั้ง root certificate และเก็บรหัส sudo ไว้ ถ้าเคยเปิดแล้วเลิกใช้ ให้ถอน certificate ออกจาก keychain ด้วย
- 9.อัปเดตเมื่อพร้อม ไม่ใช่อัตโนมัติ
เวลา 9Router บอกว่ามีเวอร์ชันใหม่ ให้ดู changelog ก่อนกด ถ้าไม่อยากให้เช็กทุกครั้งที่เปิด ใช้ --skip-update และถ้าอยากให้ล้มเหลวแทนที่จะยอมรับ certificate ที่ผิด ให้ตั้ง STRICT_SSL=true
- 10.อย่าวาง nginx หรือ reverse proxy ไว้ข้างหน้าเวอร์ชันที่ต่ำกว่า 0.5.2
นี่คือกรณีของ CVE-2026-56675 ที่ request จากอินเทอร์เน็ตถูกมองว่ามาจาก localhost ถ้าต้องให้เข้าจากที่อื่น ใช้ VPN อย่าง Tailscale ที่ไม่เปิดพอร์ตสาธารณะจะปลอดภัยกว่า
- 11.ล็อก DATA_DIR
ค่าเริ่มต้นคือ ~/.9router ข้างในมี token แบบไม่เข้ารหัส, backup และ private key ของ CA อย่าให้โฟลเดอร์นี้อยู่ใน iCloud, Google Drive หรือ Dropbox
chmod 700 ~/.9router - 12.ใช้ API key แบบจ่ายตามใช้แทน OAuth ของ subscription และแยก key ต่อเครื่องมือ
API key ที่หลุดยัง revoke และตั้งวงเงินได้ แต่ token ของบัญชี subscription หลุดเมื่อไรก็เท่ากับบัญชีหลุด และสร้าง key ของ 9Router แยกให้แต่ละเครื่องมือ หลุดตัวไหนก็ลบตัวนั้น
ถ้าต้องรัน 9Router บนเซิร์ฟเวอร์ ต้องเช็กอะไรเพิ่ม?
9Router ที่ผมดูแลรันบนเซิร์ฟเวอร์ จึงเช็กจากภายนอกว่าคนที่ไม่มี key หรือไม่ได้ล็อกอินเข้าอะไรได้บ้าง ผลกับเครื่องของผม ณ 30 ตุลาคม 2026:
เช็กอะไร | ผลที่ควรได้ | ของผม |
|---|---|---|
เวอร์ชัน | ล่าสุด | 0.5.112 (ล่าสุด) |
เข้าผ่าน HTTPS | ใช่ | ใช่ |
เรียก /v1/models โดยไม่มี key | 401 | 401 |
เปิด /dashboard โดยไม่ล็อกอิน | ถูกพาไปหน้า login | ถูกพาไปหน้า login |
เรียก /api/settings และ /api/providers โดยไม่ล็อกอิน | 401 | 401 |
รหัสผ่าน dashboard | ไม่ใช่ค่า default | ตั้งรหัสใหม่แล้ว |
API key ของ 9Router | แยกต่อคนหรือต่อเครื่องมือ | แยก key ให้แต่ละคน |
เช็กของคุณเองได้ด้วยสองคำสั่งนี้ (เปลี่ยน your-domain เป็นโดเมนของคุณ):
curl -s -o /dev/null -w "%{http_code}\n" https://your-domain/v1/models
curl -s https://your-domain/api/versionบรรทัดแรกต้องได้ 401 ถ้าได้ 200 แปลว่าใครก็ใช้โควตาของคุณได้ บรรทัดที่สองบอกเวอร์ชันที่รันอยู่ (endpoint นี้เปิดสาธารณะโดยตั้งใจ) ของผมยังเปิดหน้า login ให้เข้าได้จากทุกที่ โดยพึ่งรหัสผ่านที่แข็งแรงกับระบบล็อกเมื่อเดาผิดหลายครั้งของ 9Router ซึ่งใช้ได้ แต่ถ้าทำได้ การจำกัดหน้า dashboard ให้เข้าได้เฉพาะผ่าน VPN หรือจาก IP ที่กำหนดจะปลอดภัยกว่า เพราะหน้า login ที่เปิดสู่อินเทอร์เน็ตคือเป้าให้คนลองเดารหัส และถ้าใช้ Docker หลัง reverse proxy ให้ publish พอร์ตไว้ที่ 127.0.0.1 ของ host เพื่อให้เข้าได้ผ่าน proxy ทางเดียว
FAQ
9Router เป็น malware ไหม?
ไม่มีหลักฐานว่าเป็น code เป็น open source (MIT) อ่านได้ทั้งหมด และ audit ของ StationX ก็สรุปว่าไม่ใช่ malware และไม่พบการส่ง key ไปให้ผู้พัฒนา ปัญหาที่พบคือช่องโหว่และการเก็บความลับไม่ดีพอ ไม่ใช่เจตนาร้าย ถึงอย่างนั้นก็ควรติดตั้งจาก npm หรือ Docker image ทางการเท่านั้น
ใช้ 9Router กับ Claude Max ปลอดภัยไหม?
เป็นสองเรื่องที่ต้องแยกกัน เรื่องแรกคือความปลอดภัย token ของ subscription เก็บไว้ในเครื่องแบบไม่เข้ารหัส เรื่องที่สองคือเงื่อนไข หน้า Legal and compliance ของ Claude Code เขียนว่า OAuth ของ subscription มีไว้สำหรับ Claude Code และแอปของ Anthropic เอง ห้าม developer ภายนอกเก็บหรือส่งต่อ token เหล่านี้ และ Anthropic อาจบังคับใช้โดยไม่แจ้งล่วงหน้า (เช็กเมื่อ 30 ตุลาคม 2026) ถ้าอยากสบายใจ ทางที่ดีกว่าคือใช้ API key
ถ้าเคยรันเวอร์ชันเก่าแบบเปิดออก network ควรทำอะไร?
ถือว่า credential อาจหลุดไปแล้ว อัปเดตเป็นเวอร์ชันล่าสุดก่อน แล้ว rotate ทุกอย่าง ทั้ง API key ของ provider, ออกจากระบบหรือ revoke OAuth ของ Claude, Codex และ Copilot, สร้าง key ของ 9Router ใหม่ และเปลี่ยนรหัสผ่าน dashboard จากนั้นดู usage ของแต่ละ provider ว่ามีการใช้งานที่ไม่ใช่ของเราไหม
claude-code-router ปลอดภัยกว่าไหม?
ดูจากประวัติก็ใช่ claude-code-router มีประกาศบน GitHub แค่ 1 รายการระดับ low ส่วน StationX บอกว่ามันไม่ปิดการตรวจ TLS และฟีเจอร์เสี่ยงต้องเปิดเอง แต่ทั้งสองตัวเก็บ token แบบไม่เข้ารหัสเหมือนกัน และประกาศน้อยไม่ได้แปลว่าไม่มีช่องโหว่ อาจแค่มีคนตรวจน้อยกว่า ดูการเทียบแบบละเอียดได้ใน
บทความเทียบ 9Router กับ claude-code-router, OmniRoute, CLIProxyAPI และ LiteLLMต้องเลิกใช้ 9Router ไหม?
ไม่จำเป็น ถ้าใช้คนเดียวบนเครื่องตัวเอง อัปเดตเป็นเวอร์ชันล่าสุด bind แค่ 127.0.0.1 และทำตาม checklist ข้างบน ความเสี่ยงที่เหลือส่วนใหญ่ต้องให้คนร้ายเข้าถึงเครื่องเราได้ก่อน แต่ถ้าจะเปิดให้ทีมหรือเปิดออกอินเทอร์เน็ต ควรคิดให้หนักและพิจารณาเครื่องมือที่ออกแบบมาสำหรับทีม
สรุป
9Router มีประวัติช่องโหว่หนักในช่วงกลางปี 2026 แต่ก็แก้ไปอย่างเปิดเผยและเร็ว สิ่งที่ยังต้องระวังในเวอร์ชันล่าสุดคือ token ที่เก็บแบบไม่เข้ารหัส, ฟีเจอร์ MITM และการ bind 0.0.0.0 เป็นค่าเริ่มต้น
✅ เวอร์ชันล่าสุด + localhost อย่างเดียว + เปลี่ยนรหัสผ่าน + Require API key = ใช้ได้อย่างมีเหตุผล
❌ เปิดพอร์ต, เปิด tunnel ทั้งที่ไม่ได้ตั้งค่า, ใช้ nginx กับเวอร์ชันเก่า หรือใช้ token ของ subscription ที่สำคัญ = เสี่ยง
Last verified: 30 ตุลาคม 2026 จาก 9Router 0.5.112 (master 1fe586b), GitHub Security Advisories 19 รายการ และ CHANGELOG
แหล่งอ้างอิง:


