Salesforce Marketing Cloud (SFMC) recently patched a cluster of high‑impact vulnerabilities that could have allowed attackers to read and enumerate marketing emails and subscriber data across tenants, including Fortune 500 organizations.
Modern enterprises rely on centralised marketing clouds to deliver branded, trackable campaigns at massive scale.
SFMC (formerly ExactTarget) is one of the dominant platforms, powering dynamic emails through AMPScript, SSJS, and data views backed by large subscriber databases.
This combination of templating, scripting, and shared infrastructure dramatically amplifies the blast radius when something goes wrong.
The first risk factor lay in SFMC’s server‑side templating stack. AMPScript and SSJS allow marketers to personalize content by pulling attributes such as names and email addresses directly from subscriber records.
However, functions like TreatAsContent act as an “eval string as template” primitive, meaning any user‑controlled value passed into them can become active template code, enabling template injection.
Salesforce also supported AMPScript in email subjects, and legacy behaviour evaluated subject templates twice by default.
If an attacker signed up with a payload like %%=RowCount(LookupRows(“_Subscribers”,”SubscriberKey”,_subscriberkey))=%% in a name field, that code could execute on the second evaluation, creating a reliable injection point.
Once template execution is achieved, built‑in functions such as LookupRows against internal Data Views (_Subscribers, _Sent, _Job, _SMSMessageTracking, _Click) allow queries of contact lists, sent messages, and engagement data, effectively exposing the tenant’s entire marketing dataset.
Salesforce Marketing Cloud Vulnerability
The more serious exposure came from how SFMC implemented its “view email in browser” and related CloudPages features.
Customers typically configure branded subdomains like view.example.com or pages.example.com that all map back to shared SFMC infrastructure, with tenant and message context encoded in an encrypted qs parameter.
Researchers at Searchlight Cyber found that the older, “classic” qs format used unauthenticated CBC encryption and behaved as a padding oracle, enabling decryption and controlled re‑encryption of almost all parameters in the query string.
By abusing this oracle initially with the padre tool, then more efficiently via the AMPScript MicrositeURL function the team could forge valid qs values and pivot into features such as “Forward to a Friend”, which resolve subscriber identifiers (ls) into email addresses.
Because SFMC reused a single static key across tenants, once the cryptographic scheme was understood, attackers could potentially enumerate subscribers and view email content across any affected customer using the same mechanism.
An even older URL variant used per‑parameter “encryption” that turned out to be a simple XOR with a repeating static key plus a checksum.
This legacy scheme still functioned on modern tenants, allowing high‑speed decryption and enumeration of parameters like JobID and ListSubscriber without the performance overhead of the padding‑oracle attack.
Impact and CVEs
Combined, these issues meant an attacker who could inject template payloads or obtain any valid “view email” URL could:
- Enumerate and exfiltrate subscriber records, sent emails, and engagement data from targeted tenants.
- Forge cross‑tenant qs tokens to access emails sent by other organisations due to shared keys and infrastructure.
- Abuse hard‑coded cryptographic material and argument‑injection flaws in the MicrositeURL and CloudPages ecosystem to manipulate SFMC web workflows.
Salesforce assigned multiple CVEs to cover the different root causes, including broken or risky cryptography in email‑view and CloudPages modules, hard‑coded cryptographic keys, and argument injection in the MicrositeURL functionality.
Salesforce says the issues were reported on 16 January 2026, with mitigations deployed by 21–24 January 2026 and no confirmed malicious exploitation identified so far.
The vendor migrated Marketing Cloud Engagement to AES‑GCM for link encryption, rotated keys, disabled subject‑line double evaluation, and forcibly expired all legacy tracking and CloudPages links created before 21 January 2026 at 23:00 UTC (links were invalidated globally on 23 January 2026 at 21:00 UTC).
For customers, the incident highlights three key takeaways: shared SaaS infrastructure can turn “just marketing data” into a high‑value target; template engines must be treated like code execution environments, not harmless formatting helpers; and cryptographic designs especially static, cross‑tenant keys and home‑grown schemes inevitably become the weakest link under real‑world attack pressure.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
