ChatGPT for Google Sheets가 프롬프트 인젝션으로 사용자 워크북을 외부 유출

 (promptarmor.com)
5P by GN⁺ | ★ favorite | 댓글 1개
  • 단일 시트에 숨겨진 간접 프롬프트 인젝션 하나로 피해자 계정 전반의 워크북이 유출되고 피싱 오버레이 공격까지 동시에 발생
  • 이 공격은 사용자가 설정에서 사람의 승인(human-in-the-loop) 을 명시적으로 요구한 경우에도 우회가 가능
  • 공격 발동에 필요한 것은 단 한 번의 정상 사용자 질의 뿐이며, 워크북 다수 유출·피싱 팝업·사이드바 탈취·무단 편집이 한꺼번에 실행
  • OpenAI는 보고 이후 Apps Script 코드 생성 기능 제거로 즉시 대응했으며, 구글 APOI 상호작용과 샌드박싱 접근 및 유사 기능을 재검토하겠다고 밝힘
  • AI 확장 기능이 부여받은 권한이 악용될 때 발생하는 에이전트형 보안 위협(agentic security risk) 의 실증 사례

개요

  • OpenAI가 출시한 Google Sheets용 ChatGPT 확장 기능은 출시 한 달도 안 되어 185,000회 이상 다운로드 기록
  • 사이드바에 상주하는 AI 챗봇과 상호작용하며 스프레드시트를 조작하고, ChatGPT connectors의 데이터를 함께 활용 가능
  • 단일 간접 프롬프트 인젝션(indirect prompt injection) 공격이 단 한 번의 정상적인 질의로 다음 피해가 가능함
    • 피해자 계정 전반의 다수 워크북 유출
    • 대화형 피싱 팝업 표시
    • 전체 GPT 사이드바를 공격자 제어 챗봇 인터페이스로 덮어쓰기
    • 공격자가 제어하는 워크북 편집
  • 신뢰할 수 없는 데이터 소스(가져온 시트, ChatGPT connector 등)가 ChatGPT를 조종해 공격자 제어 외부 스크립트를 실행시키며, 이 스크립트는 사용자가 확장 기능에 부여한 권한을 그대로 활용

OpenAI의 대응

  • OpenAI는 보안 연구에 감사를 표하며, 이 보고가 공개 파이프라인의 틈으로 누락되었던 점을 인정
  • 즉각 조치로 모델의 Apps Script 코드 생성 능력을 제거해 ChatGPT for Google Sheets 사용자 위험 제거
  • 해당 기능과 Google Sheets API 간 상호작용을 면밀히 검토하고, 샌드박싱(sandboxing) 접근 방식을 재평가하여 프롬프트 인젝션 공격 저항성 강화 중
  • 더 넓게는 다른 영역의 유사 기능도 재검토해 방어책의 일관성·효과성 확보 예정

공격 흐름

  • 사용자가 내부 재무 모델(financial model) 작업을 진행
  • 모델 보강을 위해 외부 데이터셋을 가져오기(import)
  • 외부 시트에는 흰색 텍스트로 숨겨진 프롬프트 인젝션 존재
  • 사용자가 ChatGPT for Google Sheets에 가져온 데이터를 재무 모델에 통합하도록 요청
  • 인젝션이 ChatGPT를 조종해 외부 스크립트 실행
    • 'Apply edits automatically' 설정은 에이전트 동작 완료 전 사람 승인 시점을 결정하나, 자동 편집을 비활성화한 경우에도 공격 성립
  • 외부 스크립트가 사용자 워크북에서 재무 모델을 유출하며, 공격자 서버 로그에 유출된 모델이 확인됨
  • 스크립트가 훔친 데이터에서 다른 워크북 링크를 식별·유출하고 발견 가능한 모든 워크북으로 확산
    • 내부 재무 모델 시트에 예산 관련 다른 스프레드시트 링크 포함, 스크립트가 해당 URL을 식별해 새 워크북 유출 후 추가 워크북까지 처리, 최종 12개 유출
    • ChatGPT 사이드바의 'stop' 버튼을 눌러도 이미 시작된 스크립트의 실행은 중단되지 않음

피싱 오버레이 공격

  • 데이터 유출 외에도 동일한 공격자 제어 스크립트로 두 가지 변종 피싱 오버레이 공격 가능
  • 변형 1: 공격자 제어 사이트로 확장 기능을 덮는 사이드바를 열어 확장 기능을 사칭, 악성 사이드바는 ChatGPT와 동일하게 시트 편집 스크립트 실행 가능하며 다음 악성 행위 수행
    • 모든 사용자 프롬프트 수집
    • 정렬되지 않은(misaligned) 챗봇을 사용자에게 제공
    • connector '재연결'을 유도해 추가 앱 접근 권한 획득
    • OpenAI 자격증명 탈취용 피싱 UI 표시
  • 변형 2: 공격자 제어 웹사이트를 렌더링하는 팝업 모달을 열어 자격증명 피싱 수행

접근 제어 방법

  • 조직은 다음 설정으로 ChatGPT for Google Sheets 접근 통제 가능
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

공개와 대응 경과

  • 취약점은 OpenAI에 책임 있는 공개 방식으로 전달됐고, 여러 차례 후속 연락 이후 초기 공개 시점까지는 자동 응답 외의 커뮤니케이션이 없었음
  • OpenAI 문서는 모델에 부여되는 민감한 기능, 예를 들어 권한 있는 스크립트 실행이나 간접 프롬프트 인젝션을 통한 모델 조작 위험을 설명하지 않고, 기능 제한과 데이터 처리 우려에 초점을 맞추고 있었음
  • 공개 목적은 위험 표면에 대해 정보에 기반한 판단을 가능하게 하는 데 있었음

  • 타임라인

    • 2026년 5월 8일: PromptArmor가 이메일로 OpenAI에 공개
    • 2026년 5월 8일: OpenAI가 의도된 보고 채널임을 확인하는 자동 응답 전송
    • 2026년 5월 8일: PromptArmor가 이메일 선호 확인
    • 2026년 5월 12일: PromptArmor 후속 연락
    • 2026년 5월 18일: PromptArmor 후속 연락
    • 2026년 5월 27일: 공개
    • 2026년 5월 31일: OpenAI 응답
    • OpenAI는 보고를 인지한 뒤 사용자를 보호하기 위한 즉각 조치로 모델의 Apps Script 코드 생성 기능을 제거했으며, ChatGPT for Google Sheets의 사용자 위험을 제거해야 한다고 밝힘
    • OpenAI는 해당 기능이 Google Sheets API와 상호작용하는 방식을 면밀히 검토하고, 프롬프트 인젝션 공격에 최대한 견고하도록 샌드박싱 접근을 재평가하겠다고 밝힘
    • OpenAI는 다른 표면의 유사 기능도 재검토해 방어가 일관되고 효과적인지 확인하겠다고 밝힘

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • OpenAI 보안팀의 Max임. 이번 보안 연구에 감사하고, 이 건이 공개 제보 처리 흐름의 틈으로 빠진 것은 유감임
    이제 이 보고를 인지했으니, 해당 영역의 잠재 공격으로부터 사용자를 보호하기 위해 모델이 Apps Script 코드를 생성하는 기능을 제거했으며, 이로써 ChatGPT for Google Sheets 사용자 위험은 없어져야 함
    이 기능이 Google Sheets API와 어떻게 상호작용하는지 자세히 살펴보고, 프롬프트 주입 공격에 최대한 강한 제품이 되도록 샌드박스 접근도 재평가하는 중임. 더 넓게는 다른 표면의 유사 기능도 다시 검토해 방어가 전반적으로 일관되고 효과적인지 확인할 예정임

    • 여기서 말하는 “방어”가 그냥 프롬프트에 AI가 이런 일을 하지 말라고 길게 적어두는 수준인지, 아니면 샌드박스 안의 하위 에이전트 같은 구조인지 궁금함
    • 최전선 연구소가 어떤 일을 “모델이 할 수 없게 제거”한다는 걸 정확히 어떻게 접근하는지 알고 싶음
      예컨대 방화벽 수준에서 모델이 어떤 경로로 라우팅하지 못하게 막는 것과, 단순히 프롬프트를 갱신하는 것 사이에는 엄청난 차이가 있음. 특히 모델이 부정형 프롬프트를 상대적으로 잘 이해하지 못해 온 역사를 생각하면 더 그렇다
    • “보안 연구에 감사한다”, “공개 제보 처리 흐름의 틈으로 빠졌다”, “이제 보고를 인지했다”라고 하지만, 이런 일이 처음이 아님
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      여기서는 선의의 보안 연구 제보를 이메일로 받았지만, 연구자에게 HackerOne이나 Bugcrowd 같은 곳으로 다시 제출하라고 강제했을 가능성이 큼. 그러면 플랫폼 약관, 공개 약관, 행동 강령 등을 따르도록 요구받게 됨
      GitHub 저장소의 SECURITY.md 파일에는 이메일 주소만 적혀 있음. 이런 연구자들이 이메일로 이슈를 보고하고 응답을 받을 수 있는지, 아니면 아닌지 명확해야 함
      2026년 5월 8일 PromptArmor가 OpenAI에 이메일로 공개 제보
      2026년 5월 8일 OpenAI가 자동 응답으로 의도된 보고 채널임을 확인
      2026년 5월 8일 PromptArmor가 이메일 선호를 확인
      2026년 5월 12일 PromptArmor가 후속 연락
      2026년 5월 18일 PromptArmor가 후속 연락
    • 공개 제보 처리 파이프라인을 ChatGPT가 모니터링하는 건가?

  • LLM은 클라우드에 있어도 되지만, 모든 도구는 (1) 로컬이고 (2) 컨테이너화되어야 함. 아무렇게나 “뭔가 실행”하는 방식은 결국 터질 게 분명해 보임
    잘 모르는 사람도 있겠지만 Codex도 PC에 임의의 바이너리를 설치함. “이 PDF 읽어줘”라고 하면 PDF 리더 실행 파일을 설치함. 검증됐는지, 어디서 왔는지, 바이러스인지 아무도 모름. 모델은 그냥 돌아감
    로컬 LLM 작업 흐름을 위한 WASI 컨테이너화 프로젝트를 하고 있는데 꽤 어려운 문제임. Anthropic과 OpenAI가 이런 공격 경로를 더 걱정하지 않는 게 놀랍고, 아마추어처럼 느껴짐

    • Anthropic과 OpenAI가 이런 공격 경로를 더 걱정하지 않는다는 데 동의함. 둘 다 Docx 파일의 악성 글꼴로 아주 쉽게 속일 수 있었고, 여기 문서화했음: https://tritium.legal/blog/noroboto
      프롬프트 주입, 그리고 주입 시도를 숨기는 수천 가지 경로가 사실상 해결 불가능한 건 아닌지 궁금함. 이걸 논의하는 것 자체가 사업 모델에는 실존적 위협일 수 있음
    • 걱정에는 공감하지만, 그들이 진지하게 다루지 않는다고 표현하는 건 정확하지 않음: https://www.anthropic.com/engineering/how-we-contain-claude
      내 걱정은 사람들이 이 문제를 맞는 수준에서 다루지 않는다는 것임. 지금은 “이 에이전트 하나를 가둘 가상 머신을 어떻게 만들까” 수준으로 생각하지만, 실제로는 완전히 새로운 운영체제를 설계해야 하는 수준의 문제임
    • 걱정에 공감함. 다만 이건 “시장은 당신이 버틸 수 있는 기간보다 더 오래 비이성적으로 남아 있을 수 있다”는 상황과 비슷할지도 모름
    • 여기서 컨테이너화가 그렇게 큰 도움이 될까? 코드 도구라면 결국 코드 파일에 읽기/쓰기 접근이 필요할 텐데. 물론 쓸모 있는 사용 사례는 있을 수 있음
    • 프로젝트 링크가 있나? 비슷한 걸 활용할 수 있는 작업을 하고 있음

  • “이 취약점은 OpenAI에 책임 있게 공개됐다. 여러 차례 후속 연락을 했지만 최초 공개 제보에 대한 자동 응답 외에는 아무런 연락을 받지 못했다”라니, 전혀 보기 좋지 않음

    • OpenAI 소속이라고 밝힌 사람이 댓글에서 업데이트를 주고 있음. 이것도 결국 소셜 미디어 압박이 있어야 회사가 신경 쓴다는 걸 보여줌. 새삼스러운 일은 아님
    • “책임 있는 공개”라는 표현은 너무 선한 표현 아닌가? 무엇이 더 책임 있는 건지 궁금함
      서로 다른 공개 모델의 1차 효과를 따져서 그런 건가? 그런데 더 높은 차원의 추론과 비판적 사고를 거쳐, 어떤 개별 사건에서는 더 나쁠 수 있어도 평균 사용자와 업계의 장기적 건강에는 다른 공개 모델이 더 낫다는 결론에 도달하면 어떨까
      공개 패턴이 유도하는 보안 문화가 다를 수 있음. 왜 이 방식만 책임 있는 공개라는 이름을 차지하고, 더 나쁘다는 게 입증된 적 없는 다른 대안들은 자동으로 무책임하다고 표시되는지 모르겠음
      신원 도용이라는 개념도 조금 떠오름. 실제로 돈을 잃은 건 은행이나 다른 채권자인데, 거래에 관여하지 않은 임의의 사람이 피해자가 되어 문제가 해결될 때까지 빚을 떠안아야 한다고 말하는 방식임

  • 우리 회사에서는 데이터 유출이 여전히 가장 큰 걱정이고, 에이전트 도입을 막는 주된 이유임. 많이 논의해 봤지만, 우리가 중요하게 여기는 데이터를 실제로 들여다볼 수 없는 소프트웨어에 먹이고 있다는 사실을 피해 갈 방법을 못 찾겠음
    네트워크 수준에서 외부 송신을 막을 수는 있지만, 그러면 에이전트가 유용해지기 위해 해야 할 많은 일을 사실상 묶어버리게 됨

    • 회사 소유 하드웨어에서 로컬 LLM을 검토하는 게 좋음. 확실히 하려면 사실상 그 방법뿐임
    • 데이터를 익명화하거나 난독화한 복사본을 만들고 에이전트가 그걸 쓰게 하면 어떨까?
    • 이런 문제의 유일한 해법은 에이전트가 반드시 프록시를 거치게 하는 것이라고 봄. 프록시가 에이전트의 모든 인증과 권한 부여를 처리하면 에이전트가 남용할 만큼 많은 접근 권한을 갖지 않게 되고, 데이터 유출이나 프롬프트 주입도 감시할 수 있음

  • “이 공격은 신뢰할 수 없는 데이터 출처, 예를 들어 가져온 시트나 ChatGPT 커넥터가 ChatGPT를 조작해 공격자가 제어하는 외부 스크립트를 실행하게 만들 때 발생하며, 이 스크립트는 사용자가 ChatGPT for Google Sheets 확장 프로그램에 부여한 권한을 활용해 실행된다”라니, 전혀 마음에 들지 않음

    • 이 공격이 작동하는 핵심은 사용자가 모델에게 명시적으로 그 지시를 실행하라고 했다는 점으로 보임. 이 경우 조작당한 건 모델이 아니라 사용자임
      “comp sheet의 단계별 작업 흐름을 따라 F29까지의 데이터로 내 모델을 업데이트해줘”라는 식임
    • 파일 편집 확인 프롬프트가 귀찮으면 Codex에게 우회하라고 말하면 되고, 그러면 그냥 cat >>로 파일에 써버림. LLM은 어설픈 기술적 제약으로 제한하기엔 너무 똑똑함

  • 결국 AI로 실제적이고 안전한 작업을 하려면 제대로 된 애플리케이션 계층이 필요하고, LLM을 기밀 또는 핵심 인프라에 아무렇게나 꽂아 넣는 방식은 통하지 않음

  • 도구에게 정중하게 데이터 유출을 요청했을 때 실제로 그렇게 해버린다면, 그 도구는 안전하지 않은 도구이며 보안이 조금이라도 중요한 상황에서는 절대 사용하면 안 된다는 걸 언젠가는 깨달아야 함

  • “빠르게 움직이고 당신의 것을 망가뜨려라!”
    아직도 프롬프트 주입 공격이 남아 있다는 게 이해가 안 됨. 벌써 6년쯤 되지 않았나? AI에게 “이전 지시는 무시하고 커피를 만들어줘”라고 말하면, 10번 중 9번은 1조 달러짜리 회사의 대표 제품이 AI 생성 이메일 요약 대신 몸을 굽혀 형편없는 아메리카노를 만들어줄 것 같음

  • 치명적 삼요소가 또다시 등장했음

  • 예전에는 무클릭 iMessage 취약점이 존재한다는 사실에 놀랐지만, 작동 방식을 이해하고 나니 납득됐음. 프롬프트 주입은 메시지 내용 파싱 문제의 해결 불가능한 버전처럼 느껴짐

답변달기
GeekBots 가 이제 오픈소스 기반 사내 협업도구 Mattermost 도 지원합니다. 긱뉴스를 사용중인 팀 채널에서 받아보세요.