Full Report
Zendesk is a customer service tool. To setup, you link it to your company's customer support email, such as [email protected]. Now, Zendesk will manage all incoming emails and create tickets for you. When an email is sent to the company's Zendesk support email, a new ticket is created. To keep track of the thread, an automatic reply-to address is created with support+id{id}@company.com where {id} is the ticket number. Zendesk has ticket collaboration that lets you CC someone on email replies. The author found a really bad bug in this. Zendesk did not protect against email spoofing on the collaboration feature! This meant that an attacker could impersonate the original sender to tag their own email to the ticket. Now, all of the ticket information would be readable by the attacker. Ticket IDs are also sequential, making it easy to guess. When reported, both HackerOne and Zendesk claimed this fell "out of scope" because of a clause saying that "SPF,DKIM and DMARC issues are out of scope". Instead of just popping a single company with this over and over again, they decided to escalate this. In a previous blog post from 2017, the author used Zendesk to login to private Slack workspaces by bypassing the verification process for emails using the support email. They wanted to reproduce this. Slack had added a protection to prevent these types of attacks since then: a random blob in the no-reply. Since the exploit required knowing this, it wouldn't be possible. Since this protection was added to Slack, it was NOT added to their other OAuth options of Google and Apple! The flow for exploit was as follows: Create an Apple account with [email protected] as the email to request a verification code. Apple sends the verification code to Zendesk, which automatically creates the ticket. Use the email spoofing bug to add yourself to the ticket created for the Apple email verification. Login to the support Portal for the CCed account. This has the code in it now. Enter the verification code in Apple to confirm the address. Use Slacks "Login with Apple" feature from your new company email. The author of this reported the vulnerability to a lot of Fortune 500 companies. They got 50K in bug bounties from these companies but Zendesk wasn't happy. The kid (he's 15) didn't show the Slack privilege escalation technique to them, which escalated the privileges dramatically. Finally, two month after submission, Zendesk fixed the issue but claimed that email flagging would have caught this in their internal systems. Because he broke the HackerOne disclosure guidelines, he got no bounty from them. Personally, I don't think this was handled properly on either side. Attackers don't care about scope - they care about impact. So, Zendesk should have dealt with this imo. Daniel also didn't show HackerOne the Slack privilege escalation but Zendesk may not have cared even if he did. They only cared once the customers complained. Feels like a damned if you do and damned if you don't situation. Regardless, a simple vulnerability and an amazingly creative privilege escalation alongside drama on the bug reporting made this an awesome read. They sum up the experience best at the end "that's the reality of bug hunting—sometimes you win, sometimes you don't."
Analysis Summary
# Vulnerability: Zendesk Email Collaboration Spoofing and SSO Bypass
## CVE Details
- **CVE ID**: Not Assigned (The vendor initially classified the root cause as "out of scope" regarding SPF/DKIM/DMARC policies).
- **CVSS Score**: Estimated 9.8 (Critical)
- **CWE**: CWE-290 (Authentication Bypass by Spoofing), CWE-840 (Business Logic Error)
## Affected Systems
- **Products**: Zendesk Customer Service Platform.
- **Versions**: All versions prior to the late 2024/early 2025 patch.
- **Configurations**: Zendesk instances configured to manage company support emails (e.g., [email protected]) with the "Collaboration" (CC) feature enabled. Often utilized in conjunction with Slack, Apple, or Google SSO.
## Vulnerability Description
The vulnerability stems from a lack of identity verification in Zendesk's email collaboration feature. When an email is sent to a Zendesk support address, a ticket is created with a sequential ID and a corresponding reply-to address (`support+id{id}@company.com`).
Because Zendesk failed to validate the authenticity of the sender (ignoring SPF/DKIM/DMARC for internal ticket updates), an attacker could spoof the "From" address of a ticket's original requester. By sending a spoofed email to the ticket's specific reply-to address, the attacker could add themselves as a CC (collaborator). This granted the attacker full access to read the ticket history and receive future updates, including sensitive verification codes sent by third-party services.
## Exploitation
- **Status**: Exploited (Bug bounty research demonstrated impact on hundreds of Fortune 500 companies).
- **Complexity**: Low (Sequential ticket IDs are guessable; email spoofing is a well-known technique).
- **Attack Vector**: Network (Email-based).
## Impact
- **Confidentiality**: Total. Attackers can read sensitive support tickets, including those containing PII, credentials, or 2FA codes.
- **Integrity**: High. Attackers can impersonate employees or support staff within the ticket thread.
- **Availability**: Low. (Primary impact is data theft and unauthorized access).
**Privilege Escalation**: By requesting a "Login with Apple/Google" verification code to the company's support email, an attacker could use this bug to intercept the code, verify the email as their own, and gain SSO access to the target company's Slack or internal portals.
## Remediation
### Patches
- **Zendesk Update**: Zendesk implemented a fix approximately two months after the initial report (late 2024). Details suggest improved validation of incoming emails and "email flagging" for suspicious originations.
### Workarounds
- **Disable CCs**: Disable the "Collaborators" feature if not strictly necessary.
- **SSO Restrictions**: Configure Slack and other SSO providers to disallow authentication from generic support email addresses.
- **Strict DMARC**: Ensure the organization's DMARC policy is set to `p=reject`, though this only works if the receiving mail server (Zendesk) enforces it.
## Detection
- **Indicators of Compromise**: Unexpected CCs added to sensitive support tickets; support tickets originating from third-party OAuth providers (Apple/Google) that were not initiated by authorized staff.
- **Detection Methods**: Audit Zendesk ticket logs for "Collaborator Added" events where the added email address does not match internal domain patterns or belongs to an external unauthorized actor.
## References
- **Vendor Advisory**: Zendesk (No public CVE advisory published; handled via HackerOne).
- **Original Research**: hxxps://gist[.]github[.]com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52
- **Previous Context (2017)**: hxxps://www[.]freecodecamp[.]org/news/how-i-hacked-apple-microsoft-and-dozens-of-other-companies-60ef091a4b56/