Zendesk instances are being exploited as spam relays through a configuration vulnerability centred on trigger notifications. The primary attack vector involves spammers leveraging placeholder variables—such as {{ticket.title}}—within triggers that fire on ticket creation, allowing malicious actors to inject content into outbound notification emails. This transforms what should be internal workflow automation into an external mail distribution channel, effectively weaponising the platform's own communication infrastructure. The vulnerability has been documented across multiple organisations over several years, suggesting this is neither a new nor isolated incident but rather a persistent misconfiguration pattern that continues to affect Zendesk administrators.
The implications for CX teams are twofold: operational and reputational. From an operational standpoint, compromised Zendesk instances degrade deliverability for legitimate support communications—your actual customer notifications risk landing in spam folders or being blocked entirely by recipient mail servers that flag your domain as a spam source. Reputationally, your organisation's email infrastructure becomes complicit in spam distribution, damaging customer trust and potentially triggering regulatory scrutiny. This sits within a broader security landscape where CX resilience increasingly depends on foundational security practices, yet many teams treat platform configuration as a set-and-forget exercise rather than an ongoing security concern.
The vulnerability exposes a critical gap between platform capability and operational discipline. Zendesk's trigger system is designed for legitimate automation, but without proper governance—specifically, restrictions on which fields can be used in external notifications and audit trails on trigger modifications—the platform becomes a liability. For support leaders managing lean teams, the question becomes whether your current configuration review processes can catch these misconfigurations before they're exploited, or whether you're relying on incident response rather than prevention. Immediate action should include auditing all triggers that send external notifications, restricting placeholder usage to safe fields, and implementing approval workflows for trigger changes.
We've seen widespread issues with spammers using Zendesk instances as a relay. This is something I've fixed at various businesses over the last few years. The primary problem is using placeholders such as {{ticket.title}} in a trigger notification which sends on ticket creation. Many Zendesk instanc