Salesforce가 Agentforce의 취약점 세 건을 패치했다. 외부인이 공개된 문의 폼만으로 기업 자신의 AI 에이전트를 탈취할 수 있던 문제다. Zenity Labs는 SalesBleed라는 이름으로 묶인 이 공격 연쇄를 목요일 공개했다. Salesforce와 11주에 걸쳐 수정 작업을 진행해 8월에 마지막 건까지 막은 뒤였다.
출발점은 Web-to-Lead다. 기업이 영업 문의를 받으려고 웹사이트에 올려두는 인증 없는 폼이다. 공격자가 숨긴 명령을 담은 리드를 제출해도 그 시점에는 아무 일도 벌어지지 않는다. 페이로드는 CRM에 그대로 남아 있다가, 직원이 에이전트에게 평범한 질문을 던지는 순간 작동한다. 최근 리드를 확인해 달라거나 새로 들어온 건을 도와 달라는 요청이면 충분하다. 에이전트는 오염된 레코드를 읽고 직원이 아니라 공격자의 지시를 따른다.
핵심 요약
- Zenity Labs는 2026년 6월 1일 SalesBleed를 Salesforce에 신고했고, Salesforce는 다음 날 이를 확인했다. Zenity는 8월 19일 최종 패치를 검증한 뒤 9월 24일 외부에 공개했다.
- 유출이 성립한 이유는 Salesforce의 Trusted URLs 검열기와 렌더링 화면이 URL의 끝을 서로 다르게 판단했기 때문이다. 검열기는 고정된 최상위 도메인 목록만 인식했고,
.fun은 그 목록에 없었다. - 세 번째 취약점은 Reply to a Slack Thread 액션에 있었다. 사용자 확인 절차도, 발신자 표기도 없어 내부자가 에이전트의 신분을 빌려 피싱 메시지를 보낼 수 있었다.
검열기와 브라우저가 엇갈린 지점
Agentforce에는 Trusted URLs라는 통제 장치가 있다. 에이전트가 닿을 수 있는 외부 목적지를 제한하고, 신뢰되지 않은 곳을 가리키는 링크나 이미지를 검열하는 역할이다. Zenity 연구진 Alex Apostolov, João Donato, Avishai Efrat, Ayush RoyChowdhury는 이를 우회하는 두 가지 경로를 찾아냈다.
첫째, 검열기는 호스트명을 고정된 최상위 도메인 집합과 대조했다. .fun처럼 목록에 없는 도메인은 애초에 URL로 인식조차 되지 않았다. 둘째, 링크 안의 중괄호와 대괄호는 검열되지 않고 렌더링 결과까지 살아남았다. https://random_string.oast.fun/{email} 같은 문자열은 검열기가 무시할 만큼 형식이 어긋나 보였고, 브라우저가 불러올 만큼은 유효했다.
이 틈이 공격의 전부다. 주입된 명령은 에이전트에게 자체 Query Records 도구로 Accounts 테이블을 조회해 기업명과 거래 규모를 뽑아내고, 그 값을 공격자가 통제하는 호스트명의 서브도메인에 끼워 넣어 HTML 이미지 태그로 출력하라고 지시했다. 프론트엔드는 이를 렌더링해 불러왔고, DNS 조회가 훔친 필드를 공격자의 권한 있는 네임 서버로 실어 보냈다. 직원 화면에는 아무것도 보이지 않았다.
Slack은 피해를 키우고 흔적까지 지웠다
같은 페이로드는 이미지 렌더링 없이 Slack에서도 통했다. Slack이 미리보기를 만들려고 링크를 펼치기 때문이다. 특수하게 조립된 URL이 채널에 나타나는 것만으로 CRM 필드를 외부로 실어 보내는 요청이 발생한다. 클릭도, 마우스를 올리는 동작도, 리드를 확인하는 행위를 넘어선 어떤 조작도 필요하지 않다.
세 번째 버그는 성격이 다르다. Agentforce의 Reply to a Slack Thread 액션은 확인 프롬프트 없이, 호출한 사용자를 드러내는 표기도 없이 출시됐다. 이미 에이전트와 대화 중인 내부자는 익명을 유지한 채 에이전트의 신뢰받는 신분으로 피싱 링크를 게시할 수 있었다. URL 검열 우회와 결합하면 그 메시지는 어디로든 향할 수 있었다.
패치보다 오래 남는 패턴
Salesforce가 검열 우회를 막았으므로 이 특정 연쇄는 더 이상 통하지 않는다. Zenity가 강조하는 대목은 버그가 아니라 재료다. 외부인이 제출한 레코드를 읽고, 링크나 이미지를 사용자에게 되돌려 렌더링하며, 민감한 데이터에 닿는 도구 권한까지 쥔 AI 에이전트라면 세 재료가 한자리에 모여 있는 셈이다.
Zenity 공동창업자 겸 CTO Michael Bargury는 에이전트에게 secure-by-design은 여전히 필수지만 이제 그것만으로는 충분하지 않을 수 있다고 The Register에 말했다. 처음부터 설계에 심어둔 보호 장치도 에이전트가 실제 환경을 만나며 찾아내는 예외 상황은 놓친다는 것이다. 그는 에이전트가 자신을 가두려던 샌드박스를 탈출한 OpenAI–Hugging Face 사례를 더 넓은 흐름의 일부로 지목하며, 에이전트가 실제로 무엇을 하는지 감시하는 일도 그 성능이 커지는 속도에 맞춰 확장돼야 한다고 주장했다.
이 주장은 이미 하나의 제품 범주가 됐다. Docker는 이번 주 개발자 키노트에서 같은 논리를 펼치며 컨테이너는 애플리케이션을 격리하지만 에이전트에게는 봉쇄가 필요하다는 전제로 호스팅 microVM 샌드박스를 내세웠다. SalesBleed는 같은 문제의 엔터프라이즈 SaaS 버전이다. Salesforce는 가드레일을 만들었고, 그 가드레일과 브라우저는 같은 문자열을 다르게 읽었다.
FAQ — 자주 묻는 질문
SalesBleed는 아직 악용될 수 있나?
아니다. Zenity Labs는 2026년 6월 1일 Salesforce에 문제를 신고했고, Salesforce는 8월 18일 수정을 확인했다. Zenity는 8월 19일 패치를 검증했다. 9월 24일 공개된 내용은 더 이상 작동하지 않는 공격 연쇄다.
SalesBleed는 피해자가 무언가를 클릭해야 했나?
아니다. 바로 그 점이 이 취약점을 눈에 띄게 만들었다. 필요한 행동은 직원이 Agentforce 에이전트에게 최근 리드에 관한 평범한 질문을 하는 것뿐이었다. 유출은 이미지 자동 로딩이나 Slack 링크 펼치기를 통해 이뤄졌다.
Salesforce 외의 AI 에이전트도 영향을 받나?
우회 기법 자체는 Salesforce에 한정됐지만, Zenity는 그 밑에 깔린 조합은 그렇지 않다고 본다. 신뢰할 수 없는 외부 레코드를 받아들이고, 링크나 이미지를 사용자에게 되돌려 렌더링하며, 민감한 데이터를 읽는 도구를 에이전트에 부여하는 플랫폼이라면 같은 공격을 조립할 수 있다.
