สรุปสั้น
คำสั่งที่ผู้โจมตีควบคุมสามารถทำให้ผู้ช่วย AI ชื่อ Rovo ของบริษัท Atlassian รวบรวมข้อมูลใน Jira หรือ Confluence เท่าที่ผู้ใช้ซึ่งล็อกอินอยู่มีสิทธิ์เข้าถึง แล้วส่งข้อมูลนั้นออกไปยังเซิร์ฟเวอร์ภายนอกได้ บริษัทความปลอดภัยสองรายค้นพบพฤติกรรมนี้โดยอิสระจากกันและมาคนละเส้นทาง โดยเส้นทางหนึ่งได้รับการยืนยันแล้วว่าถูกปิด ส่วนอีกเส้นทางยังไม่มีการยืนยัน บริษัท PromptArmor ซึ่งทำงานด้านความปลอดภัยของ AI เลือกซ่อนคำสั่งไว้ในเนื้อหาที่ Rovo อ่าน และระบุว่าเพียงไฟล์ที่ผู้ใช้อัปโหลดเข้าไปหนึ่งไฟล์ก็เพียงพอที่จะทำให้ผู้ช่วยรวบรวมข้อมูลภายในและส่งออกผ่านคำขอ URL โดยไม่มีขั้นตอนขออนุมัติแยกต่างหาก ส่วนทีม Varonis Threat Labs ฝังคำสั่งไว้ในลิงก์แทน โดยพบว่าพารามิเตอร์ URL ชื่อ rovoChatPrompt สามารถโหลดคำสั่งของผู้โจมตีเข้าไปใน Rovo Chat ไว้ล่วงหน้าได้ ทำให้การคลิกเพียงครั้งเดียวของผู้ใช้ที่ผ่านการยืนยันตัวตนแล้วก็เพียงพอให้ Rovo รันคำสั่งเหล่านั้นด้วยสิทธิ์ของผู้ใช้คนนั้น
Varonis เรียกช่องโหว่ของตนว่า RovoBlast และเปิดเผยผ่าน Bugcrowd โดยบันทึกบน Bugcrowd แสดงว่า Atlassian แก้ไขบนฝั่งเซิร์ฟเวอร์เมื่อวันที่ 8 กรกฎาคม 2569 และผู้รายงานได้ตรวจสอบยืนยันการแก้ไขแล้ว ประเด็นสำคัญคือทั้งสองกรณีไม่มีแพตช์ให้ลูกค้าติดตั้งเอง เพราะช่องโหว่ผ่านลิงก์ถูกปิดที่ฝั่งของ Atlassian ส่วนเส้นทางที่มาผ่านเนื้อหานั้นเครื่องมือเดียวที่องค์กรมีคือการกำหนดขอบเขตว่าแอปใดและกลุ่มผู้ใช้ใดจะใช้ Rovo ได้บ้าง ทั้งนี้ไม่มีรายงานฉบับใดระบุว่าพบการนำเทคนิคเหล่านี้ไปใช้กับองค์กรจริง ซึ่งเป็นการบอกว่ารายงานทั้งสองฉบับมีเนื้อหาเท่านี้ ไม่ใช่ข้อสรุปว่าไม่เคยมีกิจกรรมลักษณะนั้นเกิดขึ้น
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 8 สิงหาคม พ.ศ. 2569 ว่า มีการเปิดเผยสองงานวิจัยที่แสดงให้เห็นว่าผู้ช่วย AI ของ Atlassian สามารถถูกหลอกให้ส่งข้อมูลภายในองค์กรออกไปยังปลายทางของผู้โจมตีได้ โดยงานทั้งสองมาจากคนละบริษัทและใช้คนละวิธี
สายแรกมาจาก PromptArmor ซึ่งเป็นการโจมตีแบบฉีดคำสั่งทางอ้อม กล่าวคือข้อความที่ผู้โจมตีควบคุมถูกวางไว้ในเนื้อหาที่ผู้ใช้สั่งให้ผู้ช่วยนำไปใช้งาน แล้วโมเดลตีความข้อความบางส่วนนั้นเป็นคำสั่ง ในตัวอย่างที่บริษัทเผยแพร่ ผู้ใช้อัปโหลดเอกสารที่ซ่อนคำสั่งฉีดไว้ แล้วขอให้ Rovo ช่วยจัดระเบียบตั๋วงานใน Jira ของตน Rovo ก็ค้นข้อมูลใน Jira และ Confluence ตามที่ถูกขอจริง แต่จากนั้นนำสิ่งที่ค้นได้ไปต่อท้าย URL ของผู้โจมตีแล้วเปิด URL นั้น ผู้โจมตีจึงอ่านเนื้อหาของตั๋วงานและหน้าเอกสารได้จากล็อกของเซิร์ฟเวอร์ตัวเอง PromptArmor ระบุว่าผู้ใช้ที่กลับเข้ามาดูแชตในภายหลังจะเห็นเพียงข้อเสนอแนะการแก้ตั๋วงาน โดยไม่มีร่องรอยของการส่งข้อมูลออกให้เห็นเลย
จุดที่ควรระวังในการอ่านคือปฏิสัมพันธ์นี้ไม่ได้อธิบายได้อย่างสะอาดว่าเป็นแบบ zero-click เพราะเหยื่อยังต้องเป็นคนนำ Rovo ไปเจอกับเนื้อหาที่ถูกวางยา และยังต้องออกคำสั่งตามปกติเสียก่อน ข้อกล่าวอ้างที่แคบกว่าและตรงกว่าของ PromptArmor คือขั้นตอนการส่งข้อมูลออกนั้นไม่ต้องผ่านการอนุมัติจากมนุษย์แยกต่างหาก
สายที่สองมาจาก Varonis Threat Labs และมีบันทึกหลักฐานที่หนักแน่นกว่า พารามิเตอร์ rovoChatPrompt สามารถบรรจุพรอมป์เต็มรูปแบบไว้ใน URL ของ Rovo ได้ โค้ดพิสูจน์แนวคิดสั่งให้ Rovo ค้นหาข้อมูลที่เหยื่อเข้าถึงได้ นำข้อมูลนั้นไปใส่ไว้ในพาธของ URL รูปภาพที่ผู้โจมตีควบคุม แล้วสั่งให้ดึงรูปนั้น คำขอดังกล่าวจึงส่งข้อมูลไปถึงเซิร์ฟเวอร์ของผู้โจมตี ผู้รายงานสาธิตการดึงคีย์ API ส่วนตัวออกจาก Confluence และ Bugcrowd ระบุว่าเทคนิคคลิกเดียวแบบเดียวกันถูกทดสอบกับ Jira และกับข้อมูลที่เข้าถึงได้ผ่านคอนเนกเตอร์ SharePoint และ Outlook ด้วย รายงานถูกจัดระดับความสำคัญ P2 บนมาตรวัดของ Bugcrowd ได้รับเงินรางวัล 6,000 ดอลลาร์ และถูกทำเครื่องหมายว่าแก้ไขแล้ว
ทั้งสองการเปิดเผยไม่มีหมายเลข CVE กำกับ และการค้นในฐานข้อมูล NVD กับแคตตาล็อก Known Exploited Vulnerabilities ของ CISA ก็ไม่พบรายการของทั้งสองกรณี ณ วันที่ 8 สิงหาคม 2569
วิธีการโจมตี
รากของปัญหาในสายของ PromptArmor ถูกอธิบายไว้ตรงไปตรงมา คือไม่มีกลไกใดตรวจสอบว่า URL ที่กำลังถูกเปิดนั้นเป็น URL ที่ตัวเอเจนต์ประกอบขึ้นมาเองหรือไม่ เมื่อไม่มีการแยกแยะตรงนี้ คำขอขาออกที่เกิดจากคำสั่งของผู้โจมตีจึงดูไม่ต่างจากคำขอที่เกิดจากการทำงานตามปกติ รายงานยังตั้งข้อสังเกตว่า Rovo เรนเดอร์รูปภาพแบบมาร์กดาวน์จากผลลัพธ์ของโมเดลด้วย ซึ่งเป็นช่องทางที่สองที่ข้อมูลอาจรั่วออกไปได้ แต่รายงานไม่ได้สาธิตสายการโจมตีเต็มรูปแบบผ่านช่องทางนี้กับ Rovo
ประเด็นเรื่องการค้นเว็บมีความสำคัญเป็นพิเศษ เพราะ Atlassian เปิดให้การค้นเว็บเป็นการตั้งค่าแยกในระดับองค์กร ซึ่งอนุญาตให้ผู้ใช้ขยายแหล่งข้อมูลของ Rovo ไปยังเว็บไซต์สาธารณะได้ PromptArmor ระบุว่าการปิดตัวเลือกนี้ไม่ได้หยุดสายการโจมตีของตน เพราะคำขอขาออกใช้ความสามารถในการดึง URL ซึ่งเป็นคนละส่วนกัน ข้อค้นพบนี้มาจากแหล่งเดียวและยังไม่มีการทำซ้ำโดยอิสระ ขณะที่หน้าเอกสารของ Atlassian สำหรับการตั้งค่าดังกล่าวก็ไม่ได้ระบุว่าคำขอที่ผู้ช่วยประกอบขึ้นเองและดึงเองนั้นอยู่ภายใต้การควบคุมเดียวกันหรือไม่ ซึ่งเป็นคำถามที่ผู้ดูแลระบบต้องตอบให้ได้ก่อนตัดสินใจว่าปุ่มเปิดปิดนี้มีค่าแค่ไหน
ไทม์ไลน์การเปิดเผยของ PromptArmor คือแจ้ง Atlassian เมื่อวันที่ 23 พฤษภาคม 2569 ได้รับหมายเลขเคสในอีกสองวันต่อมา ติดตามผลอีกครั้งเมื่อวันที่ 4 มิถุนายน และอีกครั้งเมื่อวันที่ 29 กรกฎาคม ก่อนจะเผยแพร่รายงานหลังจากที่บริษัทระบุว่าไม่ได้รับการติดต่อกลับเพิ่มเติม รายงานถูกเผยแพร่เมื่อวันที่ 5 สิงหาคม 2569 และเนื้อหายังบรรยายว่า Rovo มีช่องโหว่อยู่ ณ เวลาที่เผยแพร่
ข้อจำกัดของหลักฐานที่ต้องระบุให้ชัดคือเวลาที่รายงานของ PromptArmor ออกมานั้นห่างจากวันที่ Atlassian แก้ไขช่องโหว่ของ Varonis ไปเกือบหนึ่งเดือน และการเปิดเผยทั้งสองฉบับก็ไม่ได้บอกว่าการแก้ไขเมื่อ 8 กรกฎาคมนั้นแตะเส้นทางที่มาผ่านเนื้อหาด้วยหรือไม่ The Hacker News ระบุว่าไม่พบการอัปเดตรายงานของ PromptArmor หลังการเผยแพร่ ณ วันที่ 8 สิงหาคม 2569 ดังนั้นสถานะของเส้นทางนั้นหลังวันที่ 5 สิงหาคมจึงยังไม่ได้รับการยืนยัน
ผลกระทบ
สิ่งที่ต้องตีความให้ถูกคือขอบเขตของความเสี่ยง การเข้าถึงข้อมูลของ Rovo เป็นไปตามสิทธิ์ที่ตั้งค่าไว้ในผลิตภัณฑ์ของ Atlassian และในแอปของบุคคลที่สามที่เชื่อมต่ออยู่ ความเสี่ยงที่ถูกสาธิตจึงเป็นข้อมูลเท่าที่เหยื่อซึ่งล็อกอินอยู่เข้าถึงได้ ไม่ใช่การข้ามการอนุญาตในระดับทั้งองค์กร แต่ข้อแตกต่างนี้ควรใช้เพื่อกำหนดขอบเขตของความเสี่ยงให้ถูกต้อง ไม่ใช่เพื่อลดทอนความสำคัญของมัน เพราะในผู้ช่วยที่ถูกออกแบบมาให้เชื่อมต่อข้ามผลิตภัณฑ์และข้ามแอปภายนอกโดยตั้งใจ ระยะที่บัญชีเดียวเอื้อมถึงได้ก็คือคุณสมบัติของผลิตภัณฑ์ที่ทำงานตามที่ออกแบบไว้อยู่แล้ว
สิ่งที่การสาธิตทั้งสองเพิ่มเข้ามาคือเส้นทางให้ข้อมูลที่ผู้ใช้มีสิทธิ์เข้าถึงหลุดออกไปได้ โดยที่เจ้าของสิทธิ์นั้นไม่เคยเลือกจะส่งมันออกไปเลย นี่คือความแตกต่างระหว่างการรั่วไหลของข้อมูลกับการยกระดับสิทธิ์ และเป็นเหตุผลว่าทำไมการวัดความเสี่ยงของผู้ช่วย AI จึงต้องเริ่มจากคำถามว่าบัญชีของพนักงานคนหนึ่งมองเห็นอะไรได้บ้าง ไม่ใช่คำถามว่าระบบมีช่องโหว่ทางเทคนิคกี่ตัว
ในด้านความพร้อมของการโจมตี ควรบันทึกไว้ด้วยว่า Rovo เปิดใช้งานเป็นค่าเริ่มต้นสำหรับแอปในแผน Standard, Premium และ Enterprise และตามเอกสารของ Atlassian ทุกคนในองค์กรสามารถใช้คุณสมบัติของมันได้ หมายความว่าพื้นที่รับการโจมตีในองค์กรที่ยังไม่เคยตั้งค่าอะไรเลยนั้นกว้างเท่ากับจำนวนผู้ใช้ทั้งหมด
คำแนะนำ
เนื่องจากช่องโหว่ผ่านลิงก์ถูกปิดที่ฝั่งของ Atlassian ไปแล้ว การตอบสนองเฉพาะหน้าจึงแคบกว่าที่หัวข้อข่าวชวนให้คิด สิ่งที่องค์กรทำได้จริงคือจัดการกับความเสี่ยงที่มาผ่านเนื้อหา ด้วยการทบทวนว่าแอปใดและกลุ่มผู้ใช้ใดมีสิทธิ์เข้าถึง Rovo บ้าง กระชับสิทธิ์พื้นฐานของผู้ใช้ให้แคบลง และจำกัดขอบเขตของคอนเนกเตอร์ที่เชื่อมต่อกับระบบภายนอก โดยไม่ควรถือว่าปุ่มเปิดปิดการค้นเว็บเพียงอย่างเดียวคือเส้นแบ่งความปลอดภัยที่สมบูรณ์
ผู้ดูแลระบบไม่ได้มีทางเลือกแค่เปิดหรือปิดทั้งหมด องค์กรสามารถบล็อกคุณสมบัติของ Rovo สำหรับแอปที่รองรับได้ ซึ่งจะปิดคุณสมบัติ AI ทั้งที่มีอยู่และที่จะมาในอนาคตของแอปนั้น รวมถึง Agents และ Chat ส่วนประสบการณ์การจัดการสิทธิ์รุ่นใหม่ของแผน Enterprise ยังจัดการ Rovo แยกตามแอปและกลุ่มผู้ใช้ได้อีกด้วย
มีข้อควรระวังหนึ่งข้อที่ Atlassian ระบุไว้ในเอกสารและผู้ดูแลระบบมักพลาด คือบนไซต์ที่ติดตั้งแอปในตระกูล Jira หลายตัว การบล็อกแอปตัวใดตัวหนึ่งจะไม่ลบความสามารถที่ใช้ร่วมกันออกไป Rovo Search, Chat และ Create with Rovo จะยังใช้งานได้ตราบใดที่ยังมีแอป Jira ตัวใดตัวหนึ่งบนไซต์นั้นเปิด Rovo อยู่ องค์กรที่คิดว่าปิด Rovo ไปแล้วจึงควรตรวจสอบซ้ำว่าปิดครบทุกแอปในไซต์เดียวกันหรือยัง
ในเชิงการตรวจจับ ควรเฝ้าดูคำขอขาออกจากบริการผู้ช่วย AI ไปยังโดเมนภายนอกที่ไม่อยู่ในรายการที่คาดหมาย โดยเฉพาะคำขอที่มีข้อมูลยาวผิดปกติต่อท้ายอยู่ในพาธหรือใน query string เพราะทั้งสองการสาธิตอาศัยการแนบข้อมูลไปกับ URL เป็นหลัก