A recently disclosed set of vulnerabilities in Salesforce Marketing Cloud, widely known as SFMC, has drawn attention to the security risks tied to centralized marketing infrastructure.
The flaws, which affected components tied to AMPScript, CloudPages, and email-rendering workflows, could have enabled attackers to access subscriber information, enumerate marketing emails, and potentially affect organizations across multiple tenants.
Security researchers found that weaknesses in SFMC’s templating engine and cryptographic implementation introduced opportunities for unauthorized data access across customer environments.
AMPScript and SFMC Template Injection Risks
Modern enterprises rely heavily on Salesforce Marketing Cloud to manage large-scale marketing campaigns, personalized customer journeys, and trackable email communications. The platform, formerly known as ExactTarget, supports dynamic content generation through technologies such as AMPScript, Server-Side JavaScript (SSJS), and internal data views connected to large subscriber databases.
While these features provide flexibility for marketers, researchers noted that they also increase the impact of any underlying vulnerability. One of the major concerns centered on SFMC’s server-side templating framework.
AMPScript and SSJS allow organizations to dynamically insert subscriber attributes such as names, email addresses, and engagement metrics directly into marketing content. However, functions like TreatAsContent introduced a dangerous behavior because they effectively evaluate user-controlled input as executable template code.
Researchers explained that if attacker-controlled data was passed into these functions, it could trigger template injection inside Salesforce Marketing Cloud environments.
The issue became more severe because SFMC historically supported AMPScript execution within email subject lines. According to the findings, legacy behavior caused subject templates to be evaluated twice by default.
That design opened the door for payload execution during the second rendering stage. Researchers demonstrated the risk using the following payload inside a name field:
%%=RowCount(LookupRows(“_Subscribers”,”SubscriberKey”,_subscriberkey))=%%
If processed during the second evaluation phase, the payload could execute successfully and create a reliable injection point inside the marketing workflow.
Once template execution was achieved, attackers could potentially use built-in SFMC functions such as LookupRows to query internal Data Views, including:
- _Subscribers
- _Sent
- _Job
- _SMSMessageTracking
- _Click
Access to these views could expose subscriber lists, email delivery records, engagement metrics, and message history associated with affected Salesforce Marketing Cloud tenants.
CloudPages and “View Email in Browser” Vulnerability
Researchers identified an even more serious vulnerability tied to SFMC’s “view email in browser” functionality and CloudPages infrastructure.
Many Salesforce customers configure branded domains such as view.example.com or pages.example.com that route back to shared SFMC infrastructure. These links typically rely on an encrypted qs parameter containing tenant and message-specific information.
According to researchers from Searchlight Cyber, the older “classic” qs implementation used unauthenticated CBC encryption. The researchers found that the implementation behaved as a padding oracle, which made it possible to decrypt and re-encrypt query string parameters under certain conditions.
Initially, the researchers abused the weakness using the Padre tool before later improving the process through the AMPScript MicrositeURL function.
This allowed them to forge valid QS values and access workflows such as “Forward to a Friend,” which could resolve subscriber identifiers into actual email addresses.
One of the most concerning aspects of the vulnerability was SFMC’s use of a single static encryption key shared across tenants. Researchers stated that once the cryptographic structure became understood, attackers could theoretically enumerate subscribers and access email content across multiple organizations using the same mechanism.
Legacy Encryption Weaknesses Expanded the Attack Surface
The researchers also uncovered an older URL format that relied on per-parameter “encryption.” However, the mechanism reportedly consisted of a repeating static XOR key combined with a checksum.
Although the scheme was considered legacy functionality, researchers found that it still worked on modern SFMC tenants.
Because the implementation lacked strong cryptographic protections, attackers could decrypt and enumerate parameters such as JobID and ListSubscriber at high speed without relying on the slower padding-oracle technique.
The findings highlighted how legacy systems inside large cloud platforms can continue to create security exposure long after newer protections are introduced.
Impact of the Salesforce Marketing Cloud Vulnerability
Researchers concluded that the combined vulnerabilities could have enabled attackers to:
- Enumerate and exfiltrate subscriber records
- Access sent marketing emails and engagement data
- Forge cross-tenant QS tokens
- Access emails belonging to other organizations
- Exploit hard-coded cryptographic material
- Abuse argument-injection flaws tied to the MicrositeURL function
- Manipulate CloudPages and other SFMC web workflows
To address the issues, Salesforce assigned multiple CVEs covering several root causes, including insecure cryptographic implementations, hard-coded keys, and argument injection vulnerabilities affecting MicrositeURL and CloudPages components.
According to Salesforce, the vulnerabilities were reported on 16 January 2026. Mitigations were deployed between 21 January and 24 January 2026. The company stated that it had identified no confirmed malicious exploitation at the time of disclosure.
As part of the remediation process, Salesforce migrated Marketing Cloud Engagement encryption to AES-GCM, rotated encryption keys, and disabled the double evaluation behavior tied to AMPScript subject-line rendering.
The company also invalidated all legacy tracking and CloudPages links created before 21 January 2026 at 23:00 UTC. Those links expired globally on 23 January 2026 at 21:00 UTC.
