Zendesk Mega Backdoor

Zendesk’s email-to-ticket system let attackers use email spoofing to “join” other companies’ support conversations—then pivot that access into Slack account takeovers for hundreds of Fortune 500 organizations. The core failure was how Zendesk handled CC’d collaborators: when an attacker impersonated a legitimate sender and CC’d their own address, Zendesk automatically added them to the ticket and granted access to the full ticket history.

The mechanism hinged on predictable support addresses and incremental ticket IDs. Zendesk creates a unique reply address in the form of support+<ticketID>@<company-domain>.com, so future replies route back to the same ticket thread. If an attacker could guess the support email address and the ticket ID (often incremental and therefore brute-forceable), they could send a crafted spoofed email that impersonated the original requester and CC’d the attacker. Zendesk treated the email as legitimate, added the attacker as a collaborator, and exposed sensitive customer support details through the Zendesk portal.

That wasn’t the end of the problem. Many enterprises use Zendesk alongside Slack single sign-on on the same domain. A separate researcher had previously shown how Zendesk could be used to infiltrate private Slack workspaces by completing email verification flows through Zendesk’s support portal. In this account, the 15-year-old bug hunter replicated and scaled the approach by combining the Zendesk spoofing weakness with the way Slack verification emails work.

The attack path differed by identity provider. Google’s verification emails were blocked from becoming Zendesk tickets (notably from no-reply@ addresses), which disrupted the exploit. Apple’s verification emails, however, came from an address format that Zendesk did not block, allowing the attacker to receive verification codes via Zendesk ticket creation and then log into Slack using “Login with Apple.” With the right setup, the researcher reported reproducing the workflow across roughly a hundred vulnerable Zendesk + Slack instances, effectively enabling unauthorized access to internal Slack workspaces.

The reporting process became its own controversy. Zendesk initially marked the email-spoofing issue as out of scope for its HackerOne bug bounty, citing SPF/DKIM/DMARC-related exclusions. After additional pressure and follow-up—especially once companies contacted Zendesk and demanded actionable details—Zendesk confirmed fixes. By July 2, 2024, Zendesk described changes including switching to spam analysis when ticket threading triggers, and adding filters to suspend certain classes of emails such as Apple user verification messages based on reply-to and message-id headers, plus non-transactional Google Workspace emails.

The dispute also included the bounty award itself. Zendesk later said it forfeited the researcher’s award after alleged violations of disclosure terms, including contacting third parties before remediation. The account ends with lingering concern: even after remediation efforts, the broader lesson remained that small trust decisions in email handling—especially around spoofing and collaborator auto-add—can cascade into account compromise across connected enterprise tools.