SalesBleed: Zero-Click Prompt Injection in Salesforce Agentforce — Detection and Hardening Guide

Security researchers have disclosed a set of weaknesses — dubbed SalesBleed — in Salesforce's Agentforce autonomous AI agents that allow attackers to exfiltrate sensitive CRM data with zero user interaction. The attack chains indirect prompt injection (malicious instructions planted in data the agent ingests) with DNS-based data exfiltration, turning a customer-facing AI agent into a covert data theft channel. No CVE has been assigned to this class of weakness, which is itself a signal: AI agent attack surfaces are maturing faster than the vulnerability management frameworks most of us rely on.

If your organization has deployed Agentforce agents that ingest untrusted input — web-to-lead forms, case submissions, emails, chat transcripts — you are in scope. This post breaks down how the attack works, what you can actually detect, and how to harden your deployment today.

Introduction

Agentforce agents are designed to autonomously answer questions, qualify leads, update records, and take actions inside your Salesforce org. To do that, they are given broad read access to CRM objects (Leads, Contacts, Opportunities, Cases) and are instructed to process attacker-controllable content as part of normal operation.

SalesBleed demonstrates that this architecture is exploitable end-to-end:

1. An attacker submits a crafted payload through an untrusted input channel — e.g., a Web-to-Lead form description field.
2. When the Agentforce agent processes that record, the malicious instructions are interpreted as part of the agent's context (indirect prompt injection).
3. The agent is manipulated into querying CRM data it has legitimate access to and encoding that data into outbound requests — specifically, DNS lookups to an attacker-controlled authoritative nameserver.
4. The attacker reads the exfiltrated data from their DNS query logs. No malware, no phishing click, no credential theft — the "exfiltration tool" is your own trusted AI agent and a protocol (DNS) that almost no egress filtering blocks.

This is a zero-click, supply-of-trust attack: the agent does exactly what it was permitted to do, in service of an adversary's goal.

Technical Analysis

Affected Products and Platforms

• Salesforce Agentforce autonomous agent deployments (Agentforce Service Agent, Sales Development Rep agent, and custom agents built on the Agent Builder / Einstein Copilot framework)
• Any agent configuration that:
  • Ingests untrusted external content (Web-to-Lead submissions, inbound email-to-case, community/chat input), and
  • Has read access to CRM objects containing sensitive data, and
  • Can trigger outbound network fetches — e.g., generating/clicking URLs, loading external images, or invoking external actions — where an attacker-controlled domain can be introduced.
• Salesforce has deployed platform-side mitigations (including trusted-domain enforcement that restricts where agent-generated content can point), but custom agent instructions and permissive configurations remain exploitable patterns — this is a class of weakness, not a single patched bug.

CVE / Scoring

No CVE identifier has been assigned to the SalesBleed findings. Treat this as an architectural/design weakness class (CWE-77 command injection analogue; LLM prompt injection maps to OWASP LLM01:2025 — Prompt Injection, with data exfiltration aligning to LLM06 — Excessive Agency / LLM02 — Sensitive Information Disclosure).

Attack Chain (Defender's View)

Attacker → Web-to-Lead / inbound channel (payload in free-text field)
        → Agentforce agent processes record (indirect prompt injection)
        → Agent instructed to read CRM objects (Leads, Contacts, Opps)
        → Agent generates DNS lookups: <encoded-data>.<attacker-domain>
        → Salesforce egress resolves via authoritative NS
        → Attacker harvests data from NS query logs

Key exploitation characteristics:

• No authentication required to plant the payload — the input channel is intentionally public-facing.
• Exfiltration over DNS (port 53) bypasses most web proxies, DLP engines, and TLS inspection. DNS queries from Salesforce's own infrastructure to arbitrary authoritative nameservers are not something most SOCs baseline or alert on.
• Low observability on the SaaS side: defenders cannot run EDR on the agent. Detection must happen at the DNS layer, in Salesforce event/audit logs, and at the data-access layer.

Exploitation Status

The SalesBleed findings were disclosed by security researchers with a working proof-of-concept demonstrating zero-click exfiltration. There is no confirmed widespread in-the-wild campaign as of publication, and the issue is not listed in CISA's Known Exploited Vulnerabilities catalog. However, the technique is fully documented publicly, requires no novel tooling, and targets internet-facing input channels — assume motivated actors are already experimenting. The dwell time between "public research" and "criminal adoption" for prompt-injection techniques has been measured in weeks, not months.

Detection & Response

The honest constraint: you cannot instrument the agent itself. Your detection surface is (1) DNS telemetry, (2) Salesforce Event Monitoring / Shield audit logs, and (3) the content of ingested records. The detections below focus on the DNS exfiltration channel and agent-side behavioral anomalies — the two highest-signal, lowest-noise points in the chain.

SIGMA Rules

---
title: DNS Exfiltration Pattern - Excessive Subdomain Length and Entropy
id: 3f8c2a91-7d4e-4b1a-9c6f-2e8d5a1b4c7d
status: experimental
description: Detects DNS queries with abnormally long subdomain labels consistent with encoded data exfiltration, as used in the SalesBleed Agentforce attack where CRM data was Base64/hex-encoded into subdomains of an attacker-controlled zone.
references:
  - https://www.infosecurity-magazine.com/news/vulnerabilities-salesforce-ai/
  - https://attack.mitre.org/techniques/T1071/004/
  - https://attack.mitre.org/techniques/T1048/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.exfiltration
  - attack.t1071.004
  - attack.t1048
logsource:
  category: dns_query
  product: windows
detection:
  selection:
    QueryName|re: '^([a-zA-Z0-9\-]{40,}\.){2,}[a-zA-Z0-9\-]+\.[a-zA-Z]{2,}$'
  filter_known_cdn:
    QueryName|endswith:
      - '.amazonaws.com'
      - '.cloudfront.net'
      - '.akamaiedge.net'
      - '.akamai.net'
      - '.googleusercontent.com'
      - '.office.com'
      - '.microsoft.com'
      - '.salesforce.com'
      - '.force.com'
  condition: selection and not filter_known_cdn
falsepositives:
  - DKIM/SPF validation and other TXT-adjacent lookups with long labels
  - Security tooling performing encoded beaconing tests
  - Some CDN and anti-abuse infrastructure
level: high
---
title: DNS TXT Record Query from Non-Standard Process
id: 6b1d9e47-2c8a-4f3b-a5d1-9e7c3f2a8b6d
status: experimental
description: Detects processes other than legitimate DNS/mail/security tooling issuing TXT record queries, a common channel for smuggling data out via DNS when A-record exfiltration is filtered.
references:
  - https://attack.mitre.org/techniques/T1071/004/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.exfiltration
  - attack.t1071.004
logsource:
  category: dns_query
  product: windows
detection:
  selection:
    QueryType: 'TXT'
  filter_legit:
    Image|endswith:
      - '\svchost.exe'
      - '\dns.exe'
      - '\msedge.exe'
      - '\chrome.exe'
      - '\firefox.exe'
  condition: selection and not filter_legit
falsepositives:
  - Mail servers performing SPF/DMARC lookups
  - EDR and DLP agents performing domain reputation checks
level: medium
---
title: Salesforce Lookalike Domain DNS Resolution
id: 9c4e7b12-5a3d-4e8f-b2c6-1d9a4f7e3b8c
status: experimental
description: Detects resolution of domains impersonating Salesforce branding (e.g., 'salesforce' or 'force' keywords in unregistered lookalike domains), which researchers used to host the authoritative nameserver receiving exfiltrated CRM data.
references:
  - https://www.infosecurity-magazine.com/news/vulnerabilities-salesforce-ai/
  - https://attack.mitre.org/techniques/T1071/004/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.exfiltration
  - attack.t1071.004
logsource:
  category: dns_query
  product: windows
detection:
  selection:
    QueryName|contains:
      - 'salesforce'
      - 'salesforc'
      - 'sfdc'
  filter_official:
    QueryName|endswith:
      - '.salesforce.com'
      - '.force.com'
      - '.salesforce-sites.com'
      - '.site.com'
      - '.liveagentforcetech.com'
      - '.exacttarget.com'
  condition: selection and not filter_official
falsepositives:
  - Legitimate Salesforce partner or consultancy domains
  - Internal documentation/test domains containing the keyword
level: medium

KQL Hunt (Microsoft Sentinel / Defender)

This query hunts your DNS telemetry (ingested via the DNS connector, Syslog/CEF from Infoblox/BIND, or Defender's DnsEvents) for the exfiltration signature: rare domains with long, high-entropy subdomains, and Salesforce-brand lookalikes. Run it over 14 days and pivot on any new registrable domains.

// SalesBleed-style DNS exfiltration hunt: long/encoded subdomains + Salesforce lookalikes
let lookback = 14d;
let min_label_len = 32;
let official_sf = dynamic(["salesforce.com", "force.com", "salesforce-sites.com", "site.com", "exacttarget.com"]);
DnsEvents
| where TimeGenerated >= ago(lookback)
| extend RegistrableDomain = tostring(split(Name, ".")[-2]) + "." + tostring(split(Name, ".")[-1])
| extend Labels = split(Name, ".")
| extend MaxLabelLen = array_length(Labels) > 0
    | extend LongestLabel = todynamic("x") // placeholder removed below
| extend FirstLabelLen = strlen(tostring(Labels[0]))
| where FirstLabelLen >= min_label_len
   or (Name has_any ("salesforce", "salesforc", "sfdc") and not (Name has_any (official_sf)))
| summarize QueryCount = count(), DistinctClients = dcount(ClientIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Name, RegistrableDomain, ClientIP
| where QueryCount >= 3 or Name has_any ("salesforce", "sfdc")
| order by FirstSeen asc;
// Companion: rare newly-seen domains queried by very few hosts (classic exfil/implant tell)
CommonSecurityLog
| where TimeGenerated >= ago(lookback)
| where isnotempty(RequestURL) or isnotempty(DestinationHostName)
| extend Host = coalesce(DestinationHostName, RequestURL)
| summarize HostCount = dcount(SourceIP), Total = count() by Host
| where HostCount <= 2 and Total <= 10
| order by Total asc;

Velociraptor VQL

Velociraptor cannot see inside Salesforce, but if a companion technique ever lands on an endpoint (e.g., a malicious integration user script validating the exfil channel from inside your network, or a phishing follow-on), the DNS client cache is a fast triage source for the same lookalike-domain and encoded-subdomain indicators.

-- Hunt endpoint DNS caches for Salesforce lookalikes and long encoded subdomains (exfil tell)
LET dns = SELECT Name, Data, Type, TimeToLive
FROM Artifact.Windows.Network.DNSCache()

SELECT Name, Data, Type, TimeToLive,
       length(string=split(string=Name, sep=".")[0]) AS FirstLabelLen
FROM dns
WHERE (Name =~ "(?i)salesforc|sfdc"
       AND NOT Name =~ "(?i)(salesforce\.com|force\.com|salesforce-sites\.com|site\.com)$")
   OR length(string=split(string=Name, sep=".")[0]) > 32
ORDER BY FirstLabelLen DESC

Verification & Hardening Script

Since Agentforce is SaaS, the "patch" is configuration. The script below (1) audits your local DNS resolver/forwarder logs for the exfil pattern, and (2) generates a sinkhole blocklist you can push to your protective DNS / firewall for any confirmed-bad lookalike domains you identify during the hunt.

# SalesBleed triage: audit Windows DNS Client cache + optional sinkhole blocklist
# Run elevated. Adjust $LogPath to your DNS server debug log or analytical log export.

$LookalikePatterns = 'salesforc|sfdc|agentforce'
$OfficialSuffixes  = @('salesforce.com','force.com','salesforce-sites.com','site.com','exacttarget.com')

# 1) Hunt local DNS caches on a jump box / fleet export for lookalikes and long encoded labels
$Suspect = Get-DnsClientCache | Where-Object {
    $name = $_.Entry
    $isLookalike = ($name -match $LookalikePatterns) -and
                   -not ($OfficialSuffixes | Where-Object { $name -like "*.$_" })
    $firstLabel = ($name -split '\.')[0]
    $isLongLabel = $firstLabel.Length -gt 32
    $isLookalike -or $isLongLabel
} | Select-Object Entry, RecordType, TimeToLive

$Suspect | Format-Table -AutoSize
$Suspect | Export-Csv -Path "$env:TEMP\salesbleed_dns_triage.csv" -NoTypeInformation

# 2) Confirm no outbound DNS except to approved resolvers (defense-in-depth for egress DNS)
#    Blocks UDP/TCP 53 egress except to your sanctioned resolvers on workstations.
$ApprovedResolvers = @('10.0.0.10','10.0.0.11')   # <-- replace with your internal resolvers
foreach ($r in $ApprovedResolvers) {
    New-NetFirewallRule -DisplayName "Allow DNS to approved resolver $r (UDP)" `
        -Direction Outbound -Protocol UDP -RemotePort 53 -RemoteAddress $r -Action Allow | Out-Null
    New-NetFirewallRule -DisplayName "Allow DNS to approved resolver $r (TCP)" `
        -Direction Outbound -Protocol TCP -RemotePort 53 -RemoteAddress $r -Action Allow | Out-Null
}
New-NetFirewallRule -DisplayName "Block all other egress DNS (UDP)" `
    -Direction Outbound -Protocol UDP -RemotePort 53 -Action Block | Out-Null
New-NetFirewallRule -DisplayName "Block all other egress DNS (TCP)" `
    -Direction Outbound -Protocol TCP -RemotePort 53 -Action Block | Out-Null

Write-Host "[+] DNS triage complete. Review salesbleed_dns_triage.csv and feed confirmed-bad domains to your protective DNS sinkhole." -ForegroundColor Green

Inside Salesforce itself, run this audit immediately (via Setup, or pull with the REST/Tooling API and the Salesforce CLI):

# Pull recent agent/lead activity for review (requires sf CLI authenticated to your org)
# 1) Identify recently created Leads with suspicious free-text content (injection payloads)
sf data query --query "SELECT Id, Name, Email, Description, CreatedDate FROM Lead WHERE CreatedDate = LAST_N_DAYS:14 AND (Description LIKE '%http%' OR Description LIKE '%ignore%' OR Description LIKE '%instruction%')" --result-format csv > lead_audit.csv

# 2) Export login + API event logs (requires Event Monitoring / Shield)
sf data query --query "SELECT Id, EventType, LogDate, LogFile FROM EventLogFile WHERE EventType IN ('API','URI','LightningUsage','ReportExport') AND LogDate = LAST_N_DAYS:7" --result-format csv > elf_inventory.csv

Remediation

There is no patch to apply on your side — Salesforce has shipped platform-level mitigations, but the underlying risk (agents processing untrusted input with broad data access) is a configuration and architecture problem you own. Prioritize:

1. Enforce trusted-domain restrictions. Salesforce introduced a "Trusted URLs" / allowlist capability for Agentforce responses following this research. Verify it is enabled: Setup → Einstein → Agentforce → Trusted URLs (and for Agent Builder: ensure agents cannot render or fetch arbitrary external URLs). Audit existing agent topics/actions for any that construct URLs from record data — that is precisely the SalesBleed primitive.
2. Reduce agent data scope (least privilege). Restrict the agent's running context to only the objects and fields it needs. If a lead-qualification agent can read Opportunities and Contacts, that is excessive agency. Use a dedicated integration user with a minimum-permission profile/permission set.
3. Sanitize untrusted intake. Add validation on Web-to-Lead / Email-to-Case ingestion: strip or quarantine submissions containing URLs, instruction-like phrasing ("ignore previous", "system:", "you are"), or anomalous field lengths before an agent ever sees them. Route flagged submissions to human review instead of agent processing.
4. Enable and centralize Salesforce logging. Subscribe to Event Monitoring (Shield) if you have it; at minimum, review Setup Audit Trail, API usage, and agent conversation logs. Forward to your SIEM and alert on bulk reads by the agent integration user and on agent sessions touching records outside their topic scope.
5. Egress DNS control. Enforce that all internal resolvers forward only through your protective DNS service (Cisco Umbrella, Infoblox, DNSFilter, etc.) with new-domain and DNS-tunneling detections enabled. Deploy the egress-53 firewall policy from the script above. You cannot sinkhole Salesforce's own resolvers, which is why detection on your telemetry plus Salesforce-side prevention (step 1) must both exist.
6. Register/monitor lookalikes. Add Salesforce-brand lookalike domains to your threat intel watchlist and external attack surface monitoring; the exfil infrastructure for this technique is trivially cheap to spin up and easy to catch if you're watching for it.
7. Red-team your agents. Add prompt-injection and data-exfil scenarios to your next application pen test scope. If your testers aren't attempting indirect injection via your lead forms, your AI deployment has never actually been tested.

Review Salesforce's official Trust advisories at trust.salesforce.com and the original reporting at Infosecurity Magazine for vendor-side updates. There is currently no CISA KEV entry or mandated remediation deadline — but waiting for one on an internet-facing, zero-click data theft path is not a strategy.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub