สรุปสั้น
n8n แพลตฟอร์มออโตเมชันเวิร์กโฟลว์ยอดนิยม แจกบัญชีผิดคนตอนล็อกอิน บนอินสแตนซ์ Enterprise ที่ถูกตั้งค่าให้เชื่อถือผู้ออกโทเคน (token issuer) จากภายนอกมากกว่าหนึ่งราย ระบบจะจับคู่ JWT ที่เข้ามากับผู้ใช้ในระบบด้วยการดูค่า sub เพียงอย่างเดียว โดยละเลยค่า iss ผลก็คือโทเคนที่ถูกต้องจาก issuer A แต่พกค่า sub ที่เป็นของคนอื่นภายใต้ issuer B จะทำให้ผู้โจมตีล็อกอินเป็นคนคนนั้นได้ทันที โดยไม่ต้องใช้รหัสผ่านของเหยื่อเลย ช่องโหว่นี้ถูกติดตามในรหัส CVE-2026-59208 และ n8n ได้ปล่อยแพตช์แก้ไขเมื่อวันที่ 24 มิถุนายน 2569 ส่วนบันทึก CVE เพิ่งถูกเปิดเผยต่อสาธารณะเมื่อวันที่ 9 กรกฎาคม โดย n8n ให้เครดิตการรายงานแก่บัญชี GitHub ชื่อ bearsyankees ซึ่งโปรไฟล์ระบุถึง Strix ที่พัฒนาเอเจนต์ AI สำหรับทดสอบเจาะระบบ (penetration testing) และระบุว่าเอเจนต์ตัวนี้เป็นผู้ชี้จุดบกพร่องด้าน identity binding ในกระบวนการ token exchange
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 16 กรกฎาคม พ.ศ. 2569 ว่า มีการเปิดเผยช่องโหว่ CVE-2026-59208 ในแพลตฟอร์มออโตเมชัน n8n ที่เกี่ยวข้องกับกลไก token exchange โดย token exchange เป็นเส้นทางสำหรับลูกค้า Enterprise ในกลุ่มพันธมิตร OEM ที่ฝัง (embed) ผลิตภัณฑ์ของ n8n ไว้ในระบบตัวเอง ซึ่งเป็นการนำมาตรฐาน RFC 8693 มาใช้เพื่อให้ผู้ใช้ของพันธมิตรไม่ต้องเจอหน้าจอล็อกอินซ้ำอีกรอบ พันธมิตรจะเซ็น JWT อายุสั้นด้วยกุญแจของตนเอง จากนั้น n8n จะตรวจสอบกับกุญแจสาธารณะที่ตั้งค่าไว้ แล้วจับคู่ claim กับบัญชีในระบบ กุญแจที่เชื่อถือจะถูกใส่ไว้ใน N8N_TOKEN_EXCHANGE_TRUSTED_KEYS และเอกสารการติดตั้งยังกำกับว่าฟีเจอร์นี้อยู่ในสถานะพรีวิว
หัวใจของปัญหาคือ ตัวโทเคนนั้นถูกต้อง แต่การจับคู่ต่างหากที่เป็นบั๊ก ค่า sub รับประกันเพียงว่าไม่ซ้ำกันภายในขอบเขตของ issuer ที่สร้างมันขึ้นมาเท่านั้น ตามมาตรฐาน RFC 7519 ระบุว่า sub ควรถูก “กำหนดให้ไม่ซ้ำกันในบริบทของ issuer” หรือไม่ก็ต้องไม่ซ้ำกันในระดับสากล ตัวระบุผู้ใช้ที่แท้จริงจึงต้องเป็นคู่ของ iss บวกกับ sub แต่ n8n กลับใช้เพียงครึ่งเดียว ไม่มีอะไรห้าม issuer สองรายจากการปล่อยค่า subject เดียวกัน และเมื่อเกิดขึ้น ทั้งคู่ก็จะไปตกที่บัญชี n8n เดียวกัน ช่องโหว่นี้จะเข้าถึงอินสแตนซ์ได้ก็ต่อเมื่อเปิดใช้ token exchange และตั้งค่าให้เชื่อถือ external issuer อย่างน้อยสองราย ซึ่ง n8n ระบุว่าส่วนอื่นไม่ได้รับผลกระทบ เนื่องจากฟีเจอร์นี้จำกัดเฉพาะ Enterprise และยังอยู่ในสถานะพรีวิว กลุ่มที่เสี่ยงจึงเล็กและเฉพาะเจาะจง คือดีพลอยเมนต์แบบ OEM ที่การเชื่อถือ issuer รายที่สองเป็นการตั้งค่าที่รองรับอย่างเป็นทางการ
รายละเอียดช่องโหว่
สิ่งที่คำเตือนไม่ได้ระบุชัดเจนคือผู้โจมตีจะได้โทเคนมาอย่างไร บอกเพียงว่าสามารถหามาได้ คำถามในทางปฏิบัติคือ ผู้ใช้ทั่วไปที่ issuer ที่เชื่อถือ จะสามารถควบคุมค่า sub ที่ตนได้รับหรือไม่ ซึ่งบันทึกสาธารณะยังไม่ตอบคำถามนี้ เวกเตอร์ CVSS 4.0 ของ GitHub ระบุว่า attack requirements มีอยู่ (present) แต่ไม่ได้ให้รายละเอียดต่อ ในฐานะ CNA ของช่องโหว่นี้ GitHub ให้คะแนน CVE-2026-59208 ที่ 7.6 บน CVSS 4.0 ระดับสูง ขณะที่ NVD ให้คะแนนบั๊กเดียวกันที่ 6.8 บน CVSS 3.1 ระดับกลาง และยังไม่ได้ประเมินแบบ 4.0 เลย โดยบันทึกของ NVD กำกับ CWE-287 และ CWE-346 ส่วนการประเมิน SSVC ของ CISA เมื่อวันที่ 13 กรกฎาคม บันทึกว่าการโจมตีจริงยังเป็น none และ The Hacker News ระบุว่าไม่พบ proof-of-concept สาธารณะจากการค้นเมื่อวันที่ 16 กรกฎาคม
สองสัปดาห์ก่อนแพตช์วันที่ 24 มิถุนายน ทีมผู้ดูแลได้แก้ CVE-2026-54305 ซึ่งเป็นอีกช่องโหว่ที่จำกัดเฉพาะ Enterprise ยอมให้ผู้ใช้ที่ยืนยันตัวตนแล้วเขียนทับหรือเพิกถอนโทเคน OAuth ที่เก็บไว้ของผู้ใช้รายอื่นผ่าน endpoint Dynamic Credentials โดยตัวนั้นเป็นการขาดการตรวจสอบความเป็นเจ้าของ ไม่ใช่ปัญหา identity binding บั๊กคนละตัวแต่อยู่บนพื้นผิวเดียวกัน สำหรับ CVE-2026-59208 นี้ กระทบ n8n ทุกรุ่นที่ต่ำกว่า 2.27.4 และเวอร์ชัน 2.28.0 โดยแพตช์แรกลงใน 2.27.4 และ 2.28.1 ซึ่งเป็นเวอร์ชันขั้นต่ำ ณ วันที่ 16 กรกฎาคม แพ็กเกจ npm ของ n8n อยู่ที่ 2.30.6 ทั้งแท็ก latest และ stable โดย n8n ออกเวอร์ชัน minor ใหม่แทบทุกสัปดาห์ จึงควรตรวจแท็กและใช้ build เสถียรตัวใหม่สุดที่ดีพลอยเมนต์รองรับ
ผลกระทบต่อไทย
n8n เป็นเครื่องมือออโตเมชันเวิร์กโฟลว์แบบโอเพนซอร์สที่ได้รับความนิยมเพิ่มขึ้นเรื่อย ๆ ในหมู่องค์กรและนักพัฒนาไทย ทั้งสำหรับเชื่อมต่อระบบภายในและสร้างเวิร์กโฟลว์อัตโนมัติ อย่างไรก็ตามช่องโหว่นี้จำกัดขอบเขตค่อนข้างแคบ คือกระทบเฉพาะอินสแตนซ์ Enterprise ที่เปิดใช้ token exchange และเชื่อถือ external issuer ตั้งแต่สองรายขึ้นไป ซึ่งมักเป็นดีพลอยเมนต์แบบ OEM ที่ฝัง n8n ไว้ในผลิตภัณฑ์ องค์กรไทยส่วนใหญ่ที่ใช้ n8n แบบ self-hosted หรือ community edition ทั่วไปจึงไม่น่าได้รับผลกระทบโดยตรง แต่ผู้ให้บริการหรือองค์กรที่ฝัง n8n เข้าไปในแพลตฟอร์มของตนและรองรับผู้ใช้จากหลาย identity provider ควรถือเรื่องนี้เป็นเรื่องเร่งด่วน เพราะการที่ผู้โจมตีสวมรอยเป็นผู้ใช้คนอื่นได้โดยไม่ต้องใช้รหัสผ่านหมายถึงการเข้าถึงเวิร์กโฟลว์ ข้อมูลรับรอง และการเชื่อมต่อระบบภายในทั้งหมดที่บัญชีนั้นเข้าถึงได้ นอกจากนี้ยังเป็นบทเรียนว่าประกาศแจ้งเตือนช่องโหว่บางครั้งอยู่แค่ใน advisory ไม่ปรากฏใน changelog จึงอาจหลุดสายตาหากอัปเดตโดยดูแค่บันทึกการเปลี่ยนแปลง
คำแนะนำ
ผู้ดูแลอินสแตนซ์ n8n Enterprise ควรอัปเกรดเป็นเวอร์ชันเสถียรล่าสุดที่ดีพลอยเมนต์รองรับ อย่างน้อยต้องเป็น 2.27.4 หรือ 2.28.1 ขึ้นไป (ณ 16 ก.ค. 2569 แพ็กเกจ npm อยู่ที่ 2.30.6) หากยังอัปเกรดไม่ได้ทันที ให้ตรวจสอบว่าตนกำลังรันอะไรอยู่ โดยดูที่ N8N_TOKEN_EXCHANGE_TRUSTED_KEYS ซึ่งเก็บกุญแจเซ็นที่เชื่อถือ และแฟล็กพรีวิวที่ควบคุมว่าเปิดใช้ token exchange หรือไม่ มาตรการเฉพาะหน้าคือลดจำนวน issuer ที่เชื่อถือให้เหลือเพียงรายเดียว หรือปิดฟีเจอร์ token exchange ไปเลย ทั้งนี้ n8n ระบุว่ามาตรการเฉพาะหน้าทั้งสองไม่ได้แก้ความเสี่ยงอย่างสมบูรณ์ แต่ตามการนิยามขอบเขตของ n8n เอง อินสแตนซ์ที่ปิด token exchange อยู่แล้วจะไม่ได้รับผลกระทบ องค์กรจึงควรพิจารณาปิดฟีเจอร์นี้หากไม่ได้ใช้งานจริง และควรอัปเดตกระบวนการอัปเกรดให้อ้างอิง security advisory ไม่ใช่พึ่งพา changelog เพียงอย่างเดียว