Atlassian Rovo 데이터 유출: 발생 경위와 Jira 관리자 필수 점검 사항

Atlassian Rovo 데이터 유출: 업로드된 파일 속 숨겨진 프롬프트로 Jira와 Confluence 데이터가 유출되는 방식, 웹 검색 토글로는 이를 막을 수 없는 이유, 패치 현황 및 관리자를 위한 7단계 점검 체크리스트.

Aiden Flux

Aiden Flux

5 11월 2026

Atlassian Rovo 데이터 유출: 발생 경위와 Jira 관리자 필수 점검 사항

핵심 요약: Atlassian Rovo의 데이터 유출 취약점은 PromptArmor가 2026년 5월 23일 Atlassian에 제보하고 2026년 8월 5일에 공개한 간접 프롬프트 주입(indirect prompt injection) 공격입니다. 업로드된 파일 속 숨겨진 명령어가 Rovo로 하여금 Jira 및 Confluence 데이터를 URL에 포함해 해당 URL을 열도록 유도합니다. 공격자는 자신의 서버 로그를 통해 유출된 데이터를 확인합니다. 웹 검색 기능을 꺼두더라도 이 공격을 막을 수 없습니다.

팀에서 Rovo를 활성화한 상태로 Jira와 Confluence를 운영하고 있다면, 관리자 입장에서 20분 정도 시간을 내어 살펴볼 가치가 충분합니다. 이 공격은 클릭이나 승인 팝업은 물론, 계정 탈취조차 필요하지 않습니다. 그저 업로드된 파일 하나와 평범한 요청 한 번이면 실행됩니다.

아래에서는 공격 진행 단계, 직관적인 설정 토글이 왜 공격을 막지 못하는지, 2026년 10월 27일 기준 패치 현황, 그리고 지금 바로 실행할 수 있는 체크리스트를 살펴봅니다. 저희는 코딩 에이전트가 공유 보드에서 작업을 가져와 처리하는 워크스페이스인 Sharkly를 개발하고 있기에 동일한 문제에 직면해 있습니다. 프롬프트 주입은 어디서나 아직 해결되지 않은 과제입니다. 관건은 에이전트가 장악되었을 때 각 도구가 어디까지 접근하도록 허용하는가입니다.

사건의 전말: 단계별로 살펴보는 Rovo 프롬프트 주입

PromptArmor의 분석 보고서에서는 5단계 체인을 다음과 같이 설명합니다.

  1. 오염된 파일: 피해자가 "백로그 가이드(Backlog Guide)"라는 문서를 업로드합니다. 이 문서에는 일반 독자가 아닌 모델을 겨냥한 숨겨진 명령어가 포함되어 있습니다.
  2. 평범한 요청: 이후 피해자가 Rovo에게 Jira 티켓 정리를 요청합니다.
  3. 데이터 검색: Rovo는 Jira 티켓과 Confluence 페이지를 불러오는 과정에서 오염된 파일을 함께 읽게 됩니다.
  4. 데이터 유출: 숨겨진 명령어는 해당 데이터를 공격자의 URL에 덧붙인 뒤 URL 호출 도구를 통해 열도록 Rovo에 지시합니다. 공격자의 서버에는 데이터가 포함된 요청이 그대로 기록됩니다.
  5. 은폐: 피해자에게는 지극히 정상적인 티켓 추천 내용만 표시되며, 데이터가 외부로 유출되었다는 흔적은 전혀 나타나지 않습니다.

외부로 나가는 요청을 사람이 승인하는 절차가 전혀 없기 때문에 PromptArmor는 이를 '제로클릭(zero-click)'이라고 부릅니다. 이들이 요약한 접근 범위는 커넥터를 통해 유입되는 콘텐츠를 포함하여 에이전트가 Atlassian 내에서 접근할 수 있는 모든 데이터입니다.

파일은 여러 진입점 중 하나일 뿐입니다. PromptArmor는 회사 외부에서 인입된 지원 티켓, 웹 검색이 켜져 있을 때의 웹 검색 결과, 서드파티 커넥터 등도 진입점이 될 수 있다고 지적합니다. Rovo가 읽는 모든 곳이 악의적인 명령어가 숨어들 수 있는 자리가 됩니다.

웹 검색을 비활성화해도 소용없는 이유

Atlassian은 관리자에게 Rovo용 '웹 검색(Web search)' 토글을 제공하며, 많은 팀이 예방 조치로 이를 꺼두었습니다. 하지만 PromptArmor에 따르면 이 설정을 꺼도 공격은 여전히 동작합니다. 해당 토글이 URL을 여는 도구 자체를 제거하지는 않기 때문입니다. 게다가 그 도구는 에이전트가 직접 조합한 URL에 대해 아무런 검증도 거치지 않았습니다.

특정 기능의 이름이 붙은 설정이라고 해서 그 기능의 기반 역량까지 완전히 제거해 주는 것은 아닙니다.

Atlassian의 웹 접근 및 웹 검색 관리 페이지에는 현재 두 개의 토글이 안내되어 있습니다. '웹 접근(Web access)'은 Rovo가 공개 웹 페이지에 접근할 수 있는지를 제어하며, '웹 검색(Web search)'은 이 설정에 종속됩니다. 두 설정 모두 기본적으로 켜져 있습니다. 해당 페이지는 "웹 접근을 비활성화하더라도 연결된 도구는 차단되지 않을 수 있다"고도 경고합니다. [확인 필요(2026-10-27): 웹 접근을 끄는 것이 PromptArmor가 사용한 URL 호출 경로를 차단하는지에 대해 공개적으로 확인된 출처는 없습니다. 독자들에게 차단된다고 안내하지 마십시오.]

또 다른 유출 경로가 존재할까?

그렇습니다. PromptArmor는 Rovo가 출력 결과에 마크다운 이미지를 렌더링한다는 점에 주목했습니다. 공격자의 서버를 가리키는 이미지 URL은 브라우저가 이미지를 로드하는 순간 URL에 인코딩된 모든 데이터를 유출합니다. PromptArmor는 이 경로의 위험성을 짚었으나, Rovo에서의 구체적인 실행 체인을 전부 시연하지는 않았습니다.

공개 타임라인 및 패치 현황

일자 내용
2026-05-23 PromptArmor가 Atlassian에 문제 제보
2026-05-25 Atlassian에서 접수 확인 및 케이스 번호 부여
2026-06-04 PromptArmor의 후속 문의, 실질적인 답변 없음
2026-07-29 PromptArmor의 2차 후속 문의, 실질적인 답변 없음
2026-08-05 PromptArmor 취약점 공개, Rovo는 여전히 취약한 상태

2026년 10월 27일 기준, 해당 경로에 대한 Atlassian의 공식 성명, 보안 권고문, 또는 패치 확인 내역은 확인되지 않았습니다. 해당 보고서를 다룬 Hacker News 스레드(추천 306개, 댓글 138개)에도 Atlassian 측의 답변은 없었습니다. [발행 전 확인 필요: Atlassian의 보안 권고문과 PromptArmor 페이지에 업데이트 내용이 있는지 재확인하십시오.]

RovoBlast와는 어떻게 다른가?

서로 별개의 취약점입니다. Varonis Threat Labs가 공개한 RovoBlast는 조작된 링크를 통해 rovoChatPrompt URL 파라미터를 악용하여 피해자의 Rovo Chat에 명령어를 주입하는 방식이었습니다. Varonis는 Atlassian의 Bugcrowd 프로그램을 통해 이를 제보했으며 현재는 수정되었다고 밝혔습니다. RovoBlast는 사용자의 클릭이 필요했던 반면, PromptArmor의 공격은 피해자가 일상적인 업무를 수행하는 것만으로 유발됩니다. 따라서 한쪽이 패치되었다고 해서 다른 쪽까지 해결된 것은 아닙니다.

공격의 근본적 패턴: 치명적인 3요소(Lethal Trifecta)

사이먼 윌리슨(Simon Willison)은 이러한 취약 구조를 치명적인 3요소(the lethal trifecta)라고 명명했습니다. 바로 비공개 데이터 접근 권한, 공격자가 제어하는 콘텐츠로의 노출, 그리고 외부 통신 수단을 모두 갖춘 에이전트를 뜻합니다. 이 세 가지가 결합되면 공격자는 에이전트를 속여 내부 데이터를 외부로 전송하도록 만들 수 있습니다.

Jira 및 Confluence 환경의 Rovo는 설계상 이 세 가지를 모두 갖추고 있습니다. 사실상 그렇기 때문에 유용한 도구로 작동하는 것이기도 합니다.

Hacker News 토론에서는 다음과 같은 몇 가지 해결책이 집중적으로 논의되었습니다.

  • 사람이 직접 입력했거나 신뢰할 수 있는 도구가 반환한 URL만 호출: 에이전트가 자체적으로 조합한 URL은 절대 호출하지 않도록 제한합니다. 사이먼 윌리슨은 와일드카드 DNS를 이용하면 서브도메인만으로도 데이터가 유출될 수 있다고 지적했습니다.
  • 사전 색인된 URL 활용(느린 유출 가능성 존재): 요한 레버거(Johann Rehberger, wunderwuzzi)는 이 방식을 적용하더라도 공격자가 요청당 한 글자씩 느린 속도로 데이터를 유출할 수 있다고 언급했습니다.
  • 도메인 허용 목록: 한정된 목적의 에이전트에 유효: 에이전트에 필요한 도메인이 세 개뿐이라면 딱 세 개만 허용하는 방식입니다.

이 대책 중 모델 자체를 수정하는 방법은 없습니다. 모델이 주입된 지시문을 따르는 현상은 여전히 발생하기 때문에, 외부로 나가는 경로를 좁히는 방식을 취하는 것입니다. OWASP가 LLM 보안 위험 목록에서 프롬프트 주입을 1순위(LLM01)로 지정한 것도 바로 이 때문입니다.

Rovo 보안 체크리스트: Jira 관리자가 지금 점검해야 할 사항

각 단계는 치명적인 3요소 중 하나씩 통제 범위를 좁히는 역할을 합니다.

  1. Rovo의 접근 범위 파악: 연동된 모든 앱, 프로젝트, 스페이스(Space), 커넥터를 빠짐없이 파악하세요. Rovo는 사용자 권한을 그대로 따르므로 세션이 장악될 경우 요청한 사용자가 볼 수 있는 모든 데이터에 접근할 수 있습니다. Atlassian에 따르면 Rovo 자체를 끌 수는 없지만 관리자가 앱별로 Rovo 접근을 차단할 수는 있습니다.
  2. 외부 유입 콘텐츠 식별: 서비스 데스크 티켓, 이메일 연동 티켓, 첨부 파일, 동기화된 문서 등에는 내부 팀이 작성하지 않은 외부 텍스트가 포함됩니다. 이러한 항목들이 바로 프롬프트 주입의 공격 표면이 됩니다.
  3. 커넥터 점검: 사용하지 않는 커넥터는 연결을 해제하세요. Google Drive와 SharePoint의 경우 커넥터 차단 목록 또는 허용 목록을 활용하십시오. Varonis가 권고한 대로 법무, 인사(HR), 재무, 인시던트 대응 관련 문서는 연동 범위에서 제외해야 합니다.
  4. 웹 관련 두 가지 토글 확인: 반드시 필요한 상황이 아니라면 웹 검색(Web search)과 웹 접근(Web access)을 모두 끄세요. 다만 Atlassian의 공식 발표가 있기 전까지는 둘 중 어느 쪽도 이번 공격을 완전히 막는 해결책으로 여겨서는 안 됩니다.
  5. 아웃바운드 트래픽 모니터링: 프록시 로그에서 예상치 못한 외부 이미지나 링크 도메인 호출이 발생하는지 감시하고 이상 징후를 탐지하세요.
  6. 테스트 프롬프트 주입 점검: 테스트 티켓에 관리자가 제어하는 URL을 호출하도록 유도하는 무해한 명령어를 삽입해 보세요. 해당 URL로 실제 요청이 인입된다면 취약점이 존재한다는 뜻입니다.
  7. 팀원 공유 및 주의 당부: "티켓 정리해 줘" 같은 평범한 요청 하나만으로도 첨부 파일에 숨겨진 악의적 지시문이 실행될 수 있다는 점을 사내에 알리세요.

코딩 에이전트가 Jira에서 작업을 가져와 처리하는 환경이라면, AI 에이전트에 Jira 티켓 할당하기를 참고하시기 바랍니다.

코딩 에이전트에도 동일하게 적용되는 질문들

코딩 에이전트는 하루 종일 이슈 본문, PR 코멘트, 의존성 패키지의 README, 가져온 문서 등 신뢰할 수 없는 텍스트를 읽습니다. 또한 소스 코드에 접근할 수 있으며 대개 네트워크 접근 권한도 가지고 있습니다. 이는 채팅창 대신 터미널에서 앞서 언급한 3요소가 그대로 재현되는 격입니다. 더 뛰어난 모델을 쓴다고 해서 권한 범위 설정을 대체할 수는 없는 이유를 프롬프트 주입과 에이전트 가드레일에서 다룬 바 있습니다.

Sharkly가 에이전트에 프롬프트 주입 완전 면역을 부여하는 것은 아니며, 오늘날 그 어떤 도구도 이를 보장할 수는 없습니다. 대신 Sharkly는 에이전트 실행이 시작되기 전에 권한 범위를 명확히 정의할 수 있는 환경을 제공합니다. 에이전트는 사용자가 연결한 Computers 상에서 외부로 아웃바운드 연결을 여는 로컬 서비스를 통해 실행되므로, 일반적인 환경에서는 인바운드 포트를 열 필요가 없습니다. 게스트는 명시적으로 추가된 스페이스(Space)에만 접근할 수 있습니다. 자동화 워크플로 내 서드파티 작업은 사용자가 승인한 커넥터만을 거칩니다. 공식 문서에서도 Skill 지침 내에 비밀번호, 토큰, API 키를 절대 저장하지 말고, 작업(Task)에 필요한 최소한의 권한만 저장소에 부여할 것을 권장하고 있습니다.

에이전트는 조사하고 실행하며 보고합니다. 권한을 부여하고 그 결과를 승인하는 주체는 사람입니다. 자세한 내용은 코딩 에이전트에 허용해야 할 권한과 허용하지 말아야 할 권한 및 코딩 에이전트 승인 게이트 설정 위치를 확인해 보세요.

마치며

이번 Rovo 공격은 결코 생소한 방식이 아닙니다. 파일 하나, 평범한 요청 하나, 그리고 호출 대상에 제한이 없는 URL 도구만으로 충분했으며, 대다수 팀이 임시 조치로 찾았던 토글은 해당 도구를 막지 못했습니다. 본 글을 작성하는 시점까지도 콘텐츠를 매개로 한 유출 경로에 대해 확인된 공식 패치는 없습니다.

권한 범위(scope) 관리를 직접 통제할 수 있는 핵심 수단으로 삼으십시오. Rovo가 읽을 수 있는 데이터 범위를 파악하고, 쓰지 않는 커넥터는 정리하며, 외부 호출 경로를 직접 점검하세요. 그런 다음 팀에서 운영 중인 모든 에이전트에 대해 세 가지 질문을 던져보십시오. 에이전트가 무엇을 읽을 수 있는가? 신뢰할 수 없는 어떤 텍스트가 에이전트에게 도달하는가? 에이전트가 데이터를 어디로 전송할 수 있는가? 작업별로 이러한 권한 범위를 명확히 설정하고 코딩 에이전트들을 단일 보드에서 관리하고 싶다면, 최대 5인 조직까지 무료로 제공되는 Sharkly를 활용해 보세요.

FAQ

Atlassian Rovo 데이터 유출 공격이란 무엇인가요?

PromptArmor가 2026년 8월 5일에 공개한 간접 프롬프트 주입 공격입니다. 숨겨진 명령어를 통해 Rovo가 Jira 및 Confluence 데이터를 공격자의 URL에 덧붙여 호출하도록 유도합니다.

Rovo의 웹 검색을 끄면 데이터를 보호할 수 있나요?

PromptArmor에 따르면 그렇지 않습니다. 해당 토글을 꺼도 URL을 여는 도구 자체가 제거되지는 않습니다.

Atlassian은 Rovo 프롬프트 주입 취약점을 패치했나요?

2026년 10월 27일 기준, PromptArmor가 보고한 경로에 대한 Atlassian의 공식 성명이나 확인된 패치는 없습니다. 별개의 취약점이었던 RovoBlast는 패치되었습니다.

Rovo Dev도 영향을 받나요?

Rovo Dev는 Atlassian의 코딩 에이전트로, Jira 및 Confluence에 탑재된 Rovo와는 다른 제품이며 PromptArmor의 보고서에서도 다루지 않았습니다. 자세한 내용은 Sharkly의 Rovo Dev 무료 티어 가이드를 참고하세요.

코딩 에이전트도 동일한 공격에 취약한가요?

그렇습니다. 신뢰할 수 없는 텍스트를 읽고 네트워크에 접근할 수 있는 에이전트라면 누구나 동일한 위험에 노출되어 있습니다. 에이전트가 읽을 수 있는 데이터, 보유하는 인증 정보, 그리고 데이터를 전송할 수 있는 대상을 제한해야 합니다.

더 둘러보기

프로젝트 보드를 모니터링하는 ChatGPT, 이벤트 기반 에이전트에 다음으로 필요한 것은?

프로젝트 보드를 모니터링하는 ChatGPT, 이벤트 기반 에이전트에 다음으로 필요한 것은?

이제 ChatGPT는 MCP Events와 팀 작업을 통해 프로젝트 보드를 모니터링할 수 있습니다. 트리거는 쉬운 절반에 불과합니다. 계획의 담당자가 누구인지, 어디에 반영되는지, 그리고 어떻게 라우팅할지가 관건입니다.

5 11월 2026

코딩 에이전트가 생각할 때 멈춘 것처럼 보이는 이유: 첫 토큰까지 걸리는 시간(TTFT)

코딩 에이전트가 생각할 때 멈춘 것처럼 보이는 이유: 첫 토큰까지 걸리는 시간(TTFT)

최대 추론(Max reasoning) 상태에서 GPT-6 Sol이 첫 토큰을 출력하기까지 102초가 소요되었다. 터미널상에서 사고를 하는 에이전트와 멈춰버린 에이전트는 동일하게 보일 수 있다. 실행 상태를 구분하는 것이 얼마나 까다로운 문제인지, 그리고 장문의 사고를 조용히 중단시키는 작업별 타임아웃(per-Task timeout)의 존재가 이를 더욱 복잡하게 만든다.

4 11월 2026