Atlassian Rovo ข้อมูลรั่วไหล: เกิดอะไรขึ้น และสิ่งที่ Jira Admin ควรตรวจสอบ

สรุปสั้น ๆ: การรั่วไหลของข้อมูลผ่าน Atlassian Rovo (Data Exfiltration) เป็นการโจมตีแบบ Indirect Prompt Injection ที่ PromptArmor รายงานให้ Atlassian ทราบเมื่อวันที่ 23 พฤษภาคม 2026 และเผยแพร่สู่สาธารณะเมื่อวันที่ 5 สิงหาคม 2026 โดยคำสั่งที่ซ่อนอยู่ในไฟล์ที่อัปโหลดจะสั่งให้ Rovo แนบเนื้อหาจาก Jira และ Confluence ไปกับ URL แล้วเปิดลิงก์ดังกล่าว ทำให้ผู้โจมตีสามารถดึงข้อมูลจากบันทึกเซิร์ฟเวอร์ (Server Logs) ของตนเองได้ ซึ่งการปิดฟังก์ชันค้นหาเว็บ (Web search) ไม่สามารถป้องกันการโจมตีนี้ได้

หากทีมของคุณใช้งาน Jira และ Confluence ร่วมกับ Rovo นี่เป็นเรื่องที่ผู้ดูแลระบบควรสละเวลาตรวจสอบสัก 20 นาที เพราะการโจมตีนี้ไม่ต้องมีการคลิก ไม่ต้องรอการอนุมัติ และไม่ต้องแฮ็กบัญชีใด ๆ ขอเพียงแค่มีไฟล์ที่อัปโหลดไว้หนึ่งไฟล์และคำขอใช้งานทั่วไปเพียงหนึ่งครั้งเท่านั้น

เนื้อหาด้านล่างนี้จะอธิบายขั้นตอนการโจมตีอย่างละเอียด เหตุใดการปิดการตั้งค่าทั่วไปจึงป้องกันไม่ได้ สถานะการแพตช์ล่าสุด ณ วันที่ 27 ตุลาคม 2026 พร้อมเช็กลิสต์ความปลอดภัยที่นำไปปรับใช้ได้ทันที พวกเราพัฒนา Sharkly ซึ่งเป็นพื้นที่ทำงานที่ Agent เขียนโค้ดสามารถรับงานจากบอร์ดร่วมกันได้ จึงเผชิญกับความท้าทายนี้เช่นเดียวกัน ปัญหา Prompt Injection ยังไม่มีทางแก้เบ็ดเสร็จในทุกระบบ คำถามสำคัญจึงอยู่ที่ว่าเครื่องมือแต่ละตัวจะเปิดโอกาสให้ Agent ที่ถูกควบคุมเข้าถึงสิ่งใดได้บ้าง

เจาะลึกสิ่งที่เกิดขึ้น: ลำดับขั้นตอนการโจมตี Rovo ผ่าน Prompt Injection

บทความวิเคราะห์ของ PromptArmor ได้อธิบายวงจรการโจมตีไว้ 5 ขั้นตอนดังนี้:

1. ไฟล์ฝังมัลแวร์คำสั่ง (The poisoned file) ผู้ใช้ที่เป็นเป้าหมายอัปโหลดเอกสารชื่อ “Backlog Guide” ซึ่งมีคำสั่งซ่อนอยู่ โดยมีเป้าหมายเพื่อสั่งการโมเดล AI โดยตรง ไม่ใช่เพื่อให้มนุษย์อ่าน
2. คำสั่งใช้งานทั่วไป (The ordinary request) ต่อมา ผู้ใช้สั่งให้ Rovo ช่วยจัดระเบียบตั๋วงานใน Jira ตามปกติ
3. การค้นหาและดึงข้อมูล (The search) Rovo ดึงข้อมูลตั๋วใน Jira และหน้า Confluence ขึ้นมาประมวลผล รวมถึงอ่านไฟล์ที่ฝังคำสั่งอันตรายไว้ด้วย
4. การรั่วไหลของข้อมูล (The leak) คำสั่งที่แฝงอยู่สั่งให้ Rovo แนบเนื้อหาเหล่านั้นต่อท้าย URL ของผู้โจมตี แล้วสั่งเปิดลิงก์ด้วยเครื่องมือดึงข้อมูล URL ของระบบ เซิร์ฟเวอร์ของผู้โจมตีจึงบันทึกคำขอดังกล่าวพร้อมข้อมูลที่ถูกขโมยออกไป
5. การกลบเกลื่อนร่องรอย (The cover) ผู้ใช้จะเห็นคำแนะนำการจัดระเบียบตั๋วที่ดูสมเหตุสมผลตามปกติ โดยไม่มีสัญญาณเตือนใด ๆ ว่าข้อมูลภายในเพิ่งถูกส่งออกไปภายนอก

ไม่มีขั้นตอนที่มนุษย์ต้องอนุมัติคำขอส่งข้อมูลออกภายนอกเลย PromptArmor จึงเรียกช่องโหว่นี้ว่าเป็นแบบ Zero-Click โดยสรุปขอบเขตความเสียหายไว้ว่า ครอบคลุมข้อมูลทุกอย่างที่ Agent สามารถเข้าถึงได้ในระบบของ Atlassian รวมถึงเนื้อหาที่เชื่อมต่อผ่าน Connector ต่าง ๆ ด้วย

ไฟล์เอกสารเป็นเพียงหนึ่งในช่องทางโจมตีเท่านั้น โดย PromptArmor ยังระบุถึงตั๋วฝ่ายสนับสนุนลูกค้า (Support Ticket) จากภายนอกองค์กร ผลลัพธ์จากการค้นหาเว็บเมื่อเปิดใช้งาน Web Search และ Connector ของบุคคลที่สาม ทั้งนี้ สิ่งใดก็ตามที่ Rovo สามารถอ่านได้ ย่อมเป็นจุดที่สามารถซ่อนคำสั่งอันตรายได้ทั้งสิ้น

ทำไมการปิด Web Search จึงไม่ช่วยป้องกัน

Atlassian มีตัวเลือกให้ผู้ดูแลระบบเปิดหรือปิด "Web search" สำหรับ Rovo ซึ่งหลายทีมเลือกที่จะปิดเพื่อความปลอดภัย แต่ PromptArmor รายงานว่าการโจมตียังคงสำเร็จแม้จะปิดสวิตช์ดังกล่าวแล้ว เพราะการตั้งค่านี้ไม่ได้ปิดการทำงานของเครื่องมือที่ใช้เปิด URL แต่อย่างใด และเครื่องมือดังกล่าวยังไม่มีการตรวจสอบ URL ที่ Agent สร้างขึ้นมาเองอีกด้วย

การตั้งชื่อการตั้งค่าตามฟังก์ชันการทำงาน ไม่ได้หมายความว่ามันจะตัดความสามารถนั้นออกไปอย่างสิ้นเชิง

ในหน้าคู่มือผู้ดูแลระบบเกี่ยวกับ การเข้าถึงเว็บและการค้นหาเว็บ (Web Access and Web Search) ของ Atlassian ปัจจุบันแสดงตัวเลือกตั้งค่าไว้ 2 ส่วน โดย “Web access” จะควบคุมว่า Rovo สามารถเข้าถึงหน้าเว็บสาธารณะได้หรือไม่ ส่วน “Web search” จะทำงานภายใต้การเปิดใช้งาน Web access ทั้งสองตัวเลือกนี้เปิดเป็นค่าเริ่มต้น (Default) นอกจากนี้ หน้าระบุคำเตือนไว้ด้วยว่า “แม้ว่าจะปิดใช้งานการเข้าถึงเว็บแล้ว เครื่องมือที่เชื่อมต่ออยู่อาจไม่ถูกปิดกั้นไปด้วย” [ตรวจสอบข้อมูล 27-10-2026: ยังไม่มีแหล่งข้อมูลสาธารณะใดยืนยันว่าการปิด Web access จะช่วยปิดกั้นช่องทางการดึง URL ที่ PromptArmor ใช้ได้หรือไม่ อย่าบอกผู้อ่านว่าทำได้]

ยังมีช่องทางอื่นในการขโมยข้อมูลอีกหรือไม่?

มีแน่นอน PromptArmor ชี้ว่า Rovo มีการแสดงผลรูปภาพแบบ Markdown ในผลลัพธ์ของมัน ซึ่ง URL ของรูปภาพที่ชี้ไปยังเซิร์ฟเวอร์ของผู้โจมตีจะส่งข้อมูลที่ถูกเข้ารหัสแฝงไว้ใน URL ออกไปทันทีที่เบราว์เซอร์โหลดภาพนั้นขึ้นมา PromptArmor ได้แจ้งเตือนเกี่ยวกับช่องทางนี้ไว้ แต่ยังไม่ได้แสดงรายละเอียดขั้นตอนการโจมตีแบบเต็มรูปแบบสำหรับ Rovo

ลำดับเหตุการณ์การเปิดเผยช่องโหว่และสถานะการแพตช์

ณ วันที่ 27 ตุลาคม 2026 เรายังไม่พบแถลงการณ์ คำแนะนำด้านความปลอดภัย หรือการยืนยันการแก้ไขช่องทางนี้จาก Atlassian แต่อย่างใด แม้แต่ใน กระทู้ Hacker News ที่พูดถึงบทความนี้ (306 คะแนน, 138 ความคิดเห็น) ก็ยังไม่มีคำตอบกลับจากทาง Atlassian เช่นกัน [ตรวจสอบก่อนเผยแพร่: ตรวจสอบประกาศความปลอดภัยของ Atlassian และหน้าเว็บไซต์ของ PromptArmor อีกครั้งว่ามีการอัปเดตหรือไม่]

กรณีนี้แตกต่างจาก RovoBlast อย่างไร?

ทั้งสองเป็นคนละช่องโหว่กัน โดย Varonis Threat Labs ได้เผยแพร่ข้อมูลเกี่ยวกับ RovoBlast ซึ่งใช้ลิงก์ที่สร้างขึ้นมาเป็นพิเศษเพื่อส่งคำสั่งอันตรายผ่านพารามิเตอร์ URL rovoChatPrompt เข้าไปยัง Rovo Chat ของเหยื่อ ทาง Varonis ได้รายงานผ่านโครงการ Bugcrowd ของ Atlassian และระบุว่าได้รับการแก้ไขเรียบร้อยแล้ว ทั้งนี้ RovoBlast จำเป็นต้องให้เหยื่อคลิกลิงก์ แต่การโจมตีที่ PromptArmor ค้นพบนั้น เหยื่อเพียงแค่ทำงานตามปกติของตนเองเท่านั้น การแก้ไขช่องโหว่หนึ่งจึงไม่ได้หมายความว่าอีกช่องโหว่หนึ่งจะได้รับการแก้ไขไปด้วย

รูปแบบเบื้องหลังการโจมตี: องค์ประกอบมรณะสามประการ (The Lethal Trifecta)

Simon Willison เรียกรูปแบบความเสี่ยงนี้ว่า the lethal trifecta (องค์ประกอบมรณะสามประการ) ซึ่งประกอบด้วย: Agent ที่สามารถเข้าถึงข้อมูลส่วนตัว, เปิดรับเนื้อหาที่ผู้โจมตีควบคุมได้, และมีช่องทางสื่อสารออกสู่ภายนอก หากมีครบทั้งสามองค์ประกอบนี้ ผู้โจมตีก็สามารถหลอกล่อให้ Agent ส่งข้อมูลภายในของคุณออกไปภายนอกได้ทันที

การทำงานของ Rovo บนระบบ Jira และ Confluence มีองค์ประกอบครบทั้งสามข้อนี้มาตั้งแต่การออกแบบ ซึ่งเป็นสิ่งเดียวกันที่ทำให้มันทำงานได้อย่างมีประสิทธิภาพและมีประโยชน์

การพูดคุยใน Hacker News ได้ข้อสรุปเกี่ยวกับแนวทางแก้ไขไว้สองสามวิธีดังนี้:

• จำกัดการดึงข้อมูลเฉพาะ URL ที่มนุษย์พิมพ์เองหรือมาจากเครื่องมือที่เชื่อถือได้เท่านั้น อย่าให้ดึงข้อมูลจาก URL ที่ Agent ประกอบขึ้นมาเองโดยเด็ดขาด โดย Simon Willison ชี้ให้เห็นว่าระบบ Wildcard DNS สามารถทำให้ข้อมูลรั่วไหลผ่าน Subdomain ได้อย่างง่ายดาย
• การจำกัดให้เข้าถึงเฉพาะ URL ที่ทำดัชนีไว้ล่วงหน้าช่วยได้ แต่ข้อมูลก็ยังรั่วไหลทีละนิดได้อยู่ดี Johann Rehberger (wunderwuzzi) ตั้งข้อสังเกตว่าผู้โจมตีอาจยังสามารถขโมยข้อมูลได้ทีละตัวอักษรต่อหนึ่งคำขอ
• การทำ Domain Allowlist เหมาะสำหรับ Agent ที่ทำงานเฉพาะทาง หาก Agent จำเป็นต้องใช้งานเพียง 3 โดเมน ก็ควรกำหนดสิทธิ์ให้เข้าถึงเพียง 3 โดเมนนั้นเท่านั้น

วิธีเหล่านี้ไม่ใช่การแก้ปัญหาที่ตัวโมเดล AI แต่เป็นการจำกัดช่องทางการส่งข้อมูลออกภายนอกให้แคบลง เพราะโมเดลยังมีโอกาสทำตามข้อความที่ถูกฉีดเข้ามาอยู่เสมอ ด้วยเหตุนี้ OWASP จึงจัดให้ Prompt Injection เป็นความเสี่ยงอันดับหนึ่งในรายการ LLM Risks ภายใต้รหัส LLM01

เช็กลิสต์ความปลอดภัยของ Rovo: สิ่งที่ผู้ดูแลระบบ Jira ควรตรวจสอบทันทีในวันนี้

แต่ละขั้นตอนจะช่วยลดทอนองค์ประกอบเสี่ยงแต่ละด้านของ Trifecta ลงได้

1. สำรวจขอบเขตข้อมูลที่ Rovo สามารถเข้าถึงได้ ตรวจสอบรายการแอปพลิเคชัน โปรเจกต์ Space และ Connector ทั้งหมด เนื่องจาก Rovo อิงตามสิทธิ์ของผู้ใช้งาน เซสชันที่ถูกแทรกแซงจึงสามารถเข้าถึงทุกอย่างที่ผู้ใช้คนนั้นมองเห็นได้ แม้ว่า Atlassian จะระบุว่าไม่สามารถปิด Rovo ได้โดยสิ้นเชิง แต่ผู้ดูแลระบบสามารถบล็อกการเข้าถึงของ Rovo เป็นรายแอปได้
2. ค้นหาเนื้อหาที่มาจากภายนอก ตั๋วงานจากฝ่ายบริการ (Service Desk), ฟังก์ชัน Email-to-Issue, ไฟล์แนบ และเอกสารที่ซิงค์เข้ามา ล้วนมีข้อความที่ทีมงานของคุณไม่ได้เขียนขึ้นเอง ซึ่งสิ่งเหล่านี้คือพื้นผิวการโจมตี (Attack Surface) สำหรับการฉีดคำสั่ง
3. ตรวจสอบ Connector อย่างละเอียด ตัดการเชื่อมต่อของ Connector ที่ไม่ได้ใช้งาน สำหรับ Google Drive และ SharePoint ให้ใช้ฟังก์ชัน Blocklist หรือ Allowlist ของ Connector และควรแยกข้อมูลด้านกฎหมาย, ฝ่ายบุคคล (HR), การเงิน รวมถึงข้อมูลการรับมือเหตุการณ์ความปลอดภัย (Incident Response) ออกจากขอบเขตการเข้าถึง ตามที่ Varonis แนะนำไว้เช่นกัน
4. ตรวจสอบการตั้งค่าเว็บทั้งสองส่วน ปิดการใช้งาน Web Search และ Web Access หากไม่มีผู้ใดจำเป็นต้องใช้ แต่อย่าเพิ่งด่วนสรุปว่าวิธีนี้แก้ไขช่องโหว่ดังกล่าวได้จนกว่า Atlassian จะออกมายืนยัน
5. เฝ้าระวังการส่งข้อมูลออก (Egress) คอยสังเกตและแจ้งเตือนโดเมนภายนอกที่น่าสงสัย ไม่ว่าจะเป็นโดเมนของรูปภาพหรือลิงก์แปลกปลอมใน Proxy Log
6. ทดสอบด้วยการฝังคำสั่งจำลอง ทดลองใส่คำสั่งที่ไม่เป็นอันตรายในตั๋วทดสอบ เพื่อสั่งให้ Rovo ดึงข้อมูลจาก URL ที่คุณควบคุม หากมีคำขอส่งเข้ามาที่เซิร์ฟเวอร์ของคุณ แสดงว่าระบบยังมีช่องโหว่นี้อยู่
7. แจ้งเตือนและให้ความรู้แก่ทีมงาน ชี้แจงให้ทราบว่าแม้แต่คำสั่งธรรมดาอย่าง “ช่วยจัดระเบียบตั๋วงานให้หน่อย” ก็อาจสั่งให้คำสั่งอันตรายที่แอบแฝงอยู่ในไฟล์แนบทำงานได้

หากคุณใช้ Jira เป็นจุดที่ Agent เขียนโค้ดเข้ามารับงานไปทำ สามารถอ่านเพิ่มเติมได้ที่ การมอบหมายตั๋วงาน Jira ให้กับ AI Agent

คำถามเดียวกันนี้ก็นำมาใช้กับ Agent เขียนโค้ดได้เช่นกัน

Agent เขียนโค้ดต้องอ่านข้อความที่ไม่น่าไว้วางใจอยู่ตลอดเวลา ทั้งเนื้อหาของ Issue, ความคิดเห็นใน Pull Request, ไฟล์ README ของ Dependency ตลอดจนเอกสารที่ดึงเข้ามา ยิ่งไปกว่านั้น Agent ยังถือซอร์สโค้ดของคุณและมักจะได้รับสิทธิ์เข้าถึงเครือข่าย นี่จึงเป็นองค์ประกอบมรณะ (Trifecta) ที่ย้ายจากหน้าต่างแชตมาอยู่บนเทอร์มินัล เราได้อธิบายว่าทำไมโมเดลที่ฉลาดขึ้นจึงไม่สามารถทดแทนการจำกัดขอบเขตสิทธิ์ได้ไว้ในบทความเรื่อง Prompt Injection และกรอบความปลอดภัยของ Agent

Sharkly ไม่ได้ทำให้ Agent ปลอดจากปัญหา Injection ได้อย่างสมบูรณ์ และไม่มีเครื่องมือใดในปัจจุบันที่กล้ารับประกันสิ่งนั้นได้ แต่เราช่วยให้คุณกำหนดขอบเขตสิทธิ์ได้ล่วงหน้าก่อนที่ Agent จะเริ่มทำงาน โดย Agent จะทำงานบน Computers ที่คุณเชื่อมต่อ ผ่านทางเซอร์วิสภายในเครื่องที่เปิดการเชื่อมต่อส่งออกไปภายนอก ทำให้การตั้งค่าทั่วไปไม่จำเป็นต้องเปิด Inbound Port ผู้ใช้ภายนอก (Guest) จะเข้าถึงได้เฉพาะ Space ที่ได้รับอนุญาตโดยตรงเท่านั้น การสั่งการของบุคคลที่สามในเวิร์กโฟลว์อัตโนมัติจะต้องผ่าน Connector ที่คุณอนุญาต และในเอกสารคู่มือยังเน้นย้ำว่าห้ามเก็บรหัสผ่าน โทเคน หรือคีย์ต่าง ๆ ไว้ในคำสั่ง Skill เด็ดขาด ตลอดจนควรให้สิทธิ์เข้าถึงคลังโค้ด (Repository) เท่าที่จำเป็นต่องานนั้น ๆ ตามหลัก Least Privilege

Agent มีหน้าที่ค้นคว้า ดำเนินการ และรายงานผล ส่วนมนุษย์มีหน้าที่กำหนดขอบเขตอำนาจและตรวจสอบยอมรับผลลัพธ์ สำหรับรายละเอียดเพิ่มเติม สามารถอ่านได้ที่ สิ่งใดที่ควรและไม่ควรอนุญาตให้ Agent เขียนโค้ดทำ และ จุดที่ควรวางขั้นตอนการอนุมัติการทำงานของ Agent

บทสรุป

การโจมตี Rovo นี้ไม่ได้มีความซับซ้อนแปลกใหม่อะไรเลย เพียงแค่ไฟล์หนึ่งไฟล์ คำสั่งใช้งานธรรมดาหนึ่งคำสั่ง และเครื่องมือจัดการ URL ที่ไม่มีการจำกัดขอบเขตการเข้าถึงก็เพียงพอแล้ว ขณะที่การตั้งค่าเปิดปิดที่หลายทีมเลือกใช้ก็ไม่ได้ครอบคลุมเครื่องมือดังกล่าว ยิ่งไปกว่านั้น ณ ขณะที่เขียนบทความนี้ ยังไม่มีการยืนยันการแก้ไขช่องทางโจมตีผ่านเนื้อหาแฝงนี้เลย

จงใช้การจำกัดขอบเขตสิทธิ์ (Scope) เป็นเกราะป้องกันที่คุณควบคุมได้เอง สำรวจสิ่งที่ Rovo สามารถอ่านได้ ตัดการเชื่อมต่อ Connector ที่ไม่จำเป็น และทดสอบช่องทางการส่งข้อมูลออกด้วยตัวคุณเอง จากนั้นตั้งคำถามสำคัญ 3 ข้อกับ Agent ทุกตัวที่ทีมของคุณใช้งาน: มันสามารถอ่านข้อมูลอะไรได้บ้าง, มีข้อความที่ไม่น่าไว้วางใจส่วนใดเข้าถึงมันได้บ้าง, และมันสามารถส่งข้อมูลออกไปที่ไหนได้บ้าง หากคุณต้องการบริหารจัดการ Agent เขียนโค้ดให้อยู่บนบอร์ดเดียวกันพร้อมกำหนดขอบเขตการทำงานอย่างชัดเจนเป็นรายงาน Sharkly เปิดให้ใช้งานฟรีสำหรับองค์กรที่มีสมาชิกไม่เกิน 5 คน

คำถามที่พบบ่อย (FAQ)

การโจมตีเพื่อขโมยข้อมูลผ่าน Atlassian Rovo (Data Exfiltration) คืออะไร?

เป็นการโจมตีแบบ Indirect Prompt Injection ที่ PromptArmor เผยแพร่เมื่อวันที่ 5 สิงหาคม 2026 โดยคำสั่งที่ซ่อนอยู่จะสั่งให้ Rovo แนบข้อมูลจาก Jira และ Confluence ไปกับ URL ของผู้โจมตี แล้วทำการเปิดลิงก์นั้น

การปิด Web Search ของ Rovo ช่วยปกป้องข้อมูลได้หรือไม่?

จากข้อมูลของ PromptArmor พบว่าไม่สามารถช่วยได้ เนื่องจากการปิดตัวเลือกดังกล่าวไม่ได้เป็นการปิดเครื่องมือที่ใช้เปิด URL

Atlassian ได้ออกแพตช์แก้ไขช่องโหว่ Prompt Injection ของ Rovo แล้วหรือยัง?

ณ วันที่ 27 ตุลาคม 2026 เรายังไม่พบแถลงการณ์หรือการยืนยันการแก้ไขช่องทางที่ PromptArmor ค้นพบจาก Atlassian แต่อย่างใด ส่วนช่องโหว่ RovoBlast ที่เป็นคนละกรณีกันนั้นได้รับการแก้ไขแล้ว

Rovo Dev ได้รับผลกระทบด้วยหรือไม่?

Rovo Dev เป็น Agent สำหรับการเขียนโค้ดของ Atlassian ซึ่งเป็นคนละผลิตภัณฑ์กับ Rovo ใน Jira และ Confluence โดยรายงานของ PromptArmor ไม่ได้ครอบคลุมถึงเครื่องมือนี้ สามารถอ่านเพิ่มเติมได้ที่ คู่มือการใช้งาน Rovo Dev เวอร์ชันฟรี ของเรา

Agent เขียนโค้ดมีช่องโหว่ต่อการโจมตีลักษณะเดียวกันนี้หรือไม่?

มีเช่นกัน Agent ใดก็ตามที่ต้องอ่านข้อความที่ไม่น่าไว้วางใจและสามารถเข้าถึงเครือข่ายได้ล้วนมีความเสี่ยงเดียวกันนี้ ดังนั้นจึงควรจำกัดสิ่งที่ Agent สามารถอ่านได้ จำกัดข้อมูลระบุตัวตน (Credentials) ที่ถือครอง และจำกัดปลายทางที่ Agent สามารถส่งข้อมูลออกไปได้