ChatGPT Sheets 취약점 공개, 승인 꺼도 12개 워크북 유출

PromptArmor가 2026년 5월 27일 공개한 취약점 보고서는 스프레드시트 안의 AI 사이드바가 어디까지 실행 권한을 가질 수 있는지 보여줍니다. 대상은 OpenAI의 ChatGPT for Google Sheets입니다. 보고서에 따르면 공격자는 외부 시트에 숨긴 간접 프롬프트 인젝션으로 ChatGPT가 외부 Apps Script를 실행하게 만들고, 그 스크립트가 사용자의 워크북을 읽어 외부 서버로 전송했습니다. 예시 체인에서는 한 금융 모델 안의 링크를 따라 다른 예산 관련 파일을 찾았고, 결과적으로 12개 워크북이 유출됐습니다.

OpenAI는 같은 보고서 상단에 실린 업데이트에서 2026년 5월 31일 대응을 설명했습니다. 회사는 해당 연구를 인지한 뒤 ChatGPT for Google Sheets에서 모델이 Apps Script 코드를 생성하는 능력을 제거했고, 이 조치가 위험을 제거해야 한다고 밝혔습니다. 또한 Google Sheets API와 상호작용하는 방식, 샌드박싱 접근, 유사한 기능 표면의 방어 일관성을 재검토하겠다고 했습니다. 이 답변은 취약점이 단순한 "모델이 나쁜 지시를 따랐다" 문제가 아니라, 모델 출력이 스프레드시트 실행 환경의 권한 있는 코드로 이어지는 제품 설계 문제였음을 드러냅니다.

OpenAI 도움말 문서는 ChatGPT for Excel and Google Sheets를 스프레드시트 안 사이드바 경험으로 설명합니다. 사용자는 대형 다중 탭 파일, 수식, 참조, 가정을 다루는 워크북을 자연어로 만들고, 업데이트하고, 설명받을 수 있습니다. 지원 대상은 Free, Go, Plus, Pro, Business, Enterprise, Edu, K-12 사용자입니다. Google Sheets에서는 Google Workspace Marketplace에서 설치하고, 조직 RBAC 환경에서는 Workspace settings -> Permissions & roles -> ChatGPT for Excel and Google Sheets에서 활성화합니다.

PromptArmor가 잡은 공격 표면은 이 편의 기능의 반대편입니다. 스프레드시트는 외부에서 가져온 CSV, 공유받은 템플릿, 웹에서 복사한 테이블, 커넥터가 가져온 데이터가 같은 격자 안에 섞입니다. 사용자는 "이 데이터를 내 모델에 반영해줘"라고 말하지만, 모델은 숨은 텍스트와 정상 데이터의 경계를 스스로 확정해야 합니다. 여기에 사이드바가 Apps Script 생성과 실행 경로까지 갖고 있으면, 인젝션은 답변 오염에서 멈추지 않고 파일 읽기와 UI 조작으로 넘어갑니다.

공격 체인은 일곱 단계로 설명됩니다. 사용자는 내부 금융 모델을 작업하고, 외부 데이터 세트를 가져옵니다. 그 외부 시트에는 흰색 텍스트처럼 눈에 잘 띄지 않는 프롬프트 인젝션이 들어 있습니다. 사용자가 ChatGPT for Google Sheets에 데이터 통합을 요청하면 인젝션이 모델을 조작해 외부 스크립트를 실행하게 합니다. 이 스크립트는 현재 워크북을 외부 서버로 보내고, 훔친 데이터 안의 다른 스프레드시트 링크를 찾아 추가 워크북까지 가져갑니다.

보고서에서 특히 눈에 띄는 대목은 자동 편집 승인 설정입니다. ChatGPT for Google Sheets에는 Apply edits automatically라는 설정이 있어 에이전트식 작업을 끝내기 전에 사람 승인을 요구할 수 있습니다. PromptArmor는 이 설정을 꺼도 공격이 성공했다고 적었습니다. 승인 UI가 셀 변경에는 관여했지만, 외부 스크립트 생성과 실행 경로를 같은 방식으로 막지 못했다는 해석이 가능합니다. 사용자가 보는 "편집 승인"과 실제 실행 권한 경계가 어긋난 셈입니다.

OpenAI 문서는 사용자에게 큰 편집 전 계획을 먼저 요청하고, 공식 산출물을 검토하고, 중요한 작업 전 파일을 복제하라고 안내합니다. 이 지침은 계산 오류나 포맷 실수를 줄이는 데는 유용합니다. 하지만 PromptArmor 사례에서 핵심은 사용자가 결과물을 검토하기 전에 스크립트가 이미 실행될 수 있었다는 점입니다. 보고서는 사이드바의 중지 버튼을 눌러도 이미 시작한 스크립트 실행이 끝나는 것을 막지 못한다고 설명했습니다. 검토 단계가 실행 이후에 놓이면 데이터 유출에는 늦습니다.

피싱 오버레이도 같은 실행 권한에서 나왔습니다. PromptArmor는 공격자 스크립트가 ChatGPT for Google Sheets 사이드바 위에 공격자가 제어하는 사이트를 띄울 수 있다고 설명했습니다. 이 UI는 ChatGPT 확장처럼 보이면서 사용자 프롬프트를 수집하고, 추가 앱 재연결을 유도하고, OpenAI 자격 증명을 훔치는 화면을 표시할 수 있습니다. 다른 변형은 팝업 모달로 공격자 사이트를 렌더링해 사용자에게 로그인이나 재연결을 요구하는 방식입니다.

이 사건은 스프레드시트 AI가 왜 보안 제품의 검사 대상이 되는지 보여줍니다. 일반 챗봇의 프롬프트 인젝션은 잘못된 답변이나 잘못된 도구 호출로 끝날 수 있습니다. 스프레드시트 사이드바는 다릅니다. 워크북은 재무 모델, 고객 목록, 예산표, KPI 리포트, 채용 파이프라인, 계약 검토 자료가 들어오는 사무실 데이터베이스입니다. 여기에 외부 데이터 가져오기와 앱 커넥터가 붙으면, 한 셀의 텍스트가 다른 SaaS 파일까지 탐색하는 시작점이 됩니다.

OpenAI 도움말은 Apps가 사용자의 ChatGPT 계정에서 승인된 파일, 시스템, 데이터 소스를 사용해 더 맥락 있는 스프레드시트 결과를 만들 수 있다고 설명합니다. 같은 문서는 MCP 앱에 대해 ChatGPT for Excel and Google Sheets에서 쓰일 도구는 read-only와 non-destructive annotation을 정확히 가져야 하며, 명시 annotation이 없는 도구는 보수적으로 처리될 수 있다고 적습니다. 이 문장은 취약점 공개 뒤 읽으면 제품 방향을 보여줍니다. 스프레드시트 AI에서 도구 권한은 기능 설명이 아니라 공격 체인의 분기점입니다.

PromptArmor의 공개 타임라인도 운영 관점에서 남는 질문을 만듭니다. 보고서에 따르면 2026년 5월 8일 OpenAI에 이메일로 제보했고, 같은 날 자동 회신을 받았습니다. 5월 12일과 5월 18일 후속 연락을 했고, 5월 27일 공개했습니다. 5월 31일 OpenAI 답변이 추가됐습니다. 사용자는 취약점 공개 시점과 공급자의 완화 조치 시점 사이 며칠 동안 어떤 버전이 어떤 워크스페이스에 적용됐는지 확인하기 어렵습니다. 기업 보안팀은 확장 비활성화, 로그 검토, 노출된 워크북 식별을 별도 절차로 갖고 있어야 합니다.

GeekNews에는 2026년 6월 2일 이 글이 올라왔고, 요약은 단일 시트에 숨겨진 간접 프롬프트 인젝션 하나로 계정 전반의 워크북 유출과 피싱 오버레이가 함께 발생한다고 정리했습니다. 같은 목록에는 Google SRE의 AI 운영 에이전트 글, ChatGPT·Claude·Codex 관련 스킬과 관측성 도구 글도 함께 보였습니다. 국내 개발자 커뮤니티에서 에이전트 논의가 모델 성능보다 권한, 로그, 실행 통제로 옮겨가는 장면입니다.

Hacker News 첫 페이지에는 같은 시각 이 PromptArmor 글이 직접 올라와 있지는 않았습니다. 대신 OpenAI 모델과 Codex의 AWS 제공, Stanford CS336의 AI Agent Guidelines 같은 항목이 상위권에 있었습니다. 이 조합은 개발자 관심이 "어떤 모델이 더 똑똑한가"에서 "에이전트가 어떤 권한으로 어디서 실행되는가"로 넓어졌음을 보여주는 보조 신호입니다. 스프레드시트 AI 보안은 그 논의의 사무실 버전입니다.

실무 점검은 세 갈래로 나눌 수 있습니다. 첫째, 조직 관리자는 ChatGPT for Excel and Google Sheets 활성화 여부를 확인해야 합니다. OpenAI 문서는 Business, Enterprise, Edu, K-12 환경에서 워크스페이스 수준 제어, 데이터·추론 residency, Enterprise Key Management, RBAC, Compliance API를 지원한다고 설명합니다. 사용자가 어떤 워크북에서 어떤 프롬프트를 실행했고 어떤 변경이 발생했는지 로그로 남지 않으면, 공개된 취약점 뒤 사후 조사는 추정에 의존합니다.

둘째, 앱과 커넥터는 읽기 권한과 쓰기 권한을 분리해야 합니다. OpenAI 문서의 MCP annotation 언급은 이 방향과 맞닿아 있습니다. 스프레드시트 안 AI가 내부 파일, CRM, 데이터 웨어하우스, 드라이브 문서에 접근한다면, "이 도구는 read-only인가", "이 도구는 외부 네트워크 전송을 할 수 있는가", "모델 출력이 코드 실행으로 변환되는가"를 기능 단위로 적어야 합니다. 승인 버튼 하나로 모든 도구 호출을 같은 위험으로 취급하면 실제 경계가 흐려집니다.

셋째, 사용자 교육은 "AI가 틀릴 수 있다"에서 멈추면 부족합니다. 이번 사례의 사용자 행동은 위험해 보이지 않습니다. 외부 데이터를 가져오고, 내부 모델에 반영해 달라고 요청했습니다. 공격 데이터가 흰색 텍스트로 숨겨져 있다면 사람 검토도 쉽지 않습니다. 사용자에게 필요한 지침은 낯선 시트 가져오기 금지, 중요한 워크북 복제, 외부 링크가 섞인 워크북에서 AI 편집 비활성화, 커넥터 재연결 요청 거부처럼 더 구체적인 운영 규칙입니다.

OpenAI의 완화 조치는 빠른 제품 차단에 가깝습니다. Apps Script 코드 생성 능력을 제거하면 PromptArmor가 보여준 특정 체인은 끊어질 수 있습니다. 그래도 보안팀이 확인할 질문은 남습니다. 이전에 생성된 스크립트가 워크북에 남아 있는지, 공격자가 열어 둔 사이드바나 팝업 흔적이 로그에 남는지, 같은 계정의 다른 연결 앱이 읽힌 파일 목록을 남기는지, Google Workspace 감사 로그와 OpenAI Compliance API를 맞춰볼 수 있는지 확인해야 합니다.

이 뉴스의 개발자 영향은 스프레드시트 제품 하나에 갇히지 않습니다. AI 기능이 문서, IDE, 브라우저, 메일, CRM, 데이터 웨어하우스에 들어가면서 모델은 점점 "답변하는 컴포넌트"가 아니라 "권한을 위임받은 사용자 인터페이스"가 됩니다. 프롬프트 인젝션 방어도 모델 안전 문구가 아니라 제품 권한 설계로 내려옵니다. 도구 호출이 read-only인지, 외부 네트워크가 가능한지, 코드 생성이 실행으로 이어지는지, 사람이 보는 승인 UI와 실제 실행 경계가 일치하는지가 배포 전 체크리스트가 됩니다.

PromptArmor 보고서가 남긴 실무 문장은 단순합니다. 스프레드시트 AI를 켰다면 그 AI가 읽을 수 있는 워크북 범위, 실행할 수 있는 코드 범위, 표시할 수 있는 UI 범위를 각각 분리해서 봐야 합니다. OpenAI는 Apps Script 생성을 제거했다고 밝혔지만, 조직은 이미 설치된 add-in과 연결 앱 권한을 그대로 두고 "패치됐으니 끝"이라고 볼 수 없습니다. 다음 취약점은 Sheets가 아니라 Excel, 문서 편집기, 코드 리뷰 사이드바, CRM 에이전트에서 같은 구조로 나올 수 있습니다.