Past Exploit And Global Aftermath

Zendesk is a customer support company with global reach and a lot of important client companies (Airbnb, Booking, Shopify, Hubspot, Github..). Instead of building their in-house customer support platforms, these client companies decided to subcontract their merchant assistance need, guest‑support workflows etc. to a third party company like Zendesk.

All the companies could integrate a Zendesk customer ticketing portal into their own environments. It would be a convenient solution as long as the provider demonstrates cybersecurity expertise comparable to that of its biggest clients. Unfortunately, Zendesk has been affected by multiple security vulnerabilities (CVEs) for years.

Situation In 2024

One of the biggest security issues was linked to email spoofing which operated as follows:

When a customer sent an email to a company Zendesk support portal, Zendesk will automatically open a support ticket. Each new ticket is linked to a unique Reply‑To email address and that specific address embeds the ticket’s identifier (e.g., [email protected]).

The flaw resides in the ticket ID that can be discovered or deducted by a hacker (id12345 in above example). If it was guessed, the attacker could forge a fake email that looks like coming from the legitimate customer. The hacker could also inserted their own email address in copy of the message (CC’ing). Then the attacker sends the message to the same unique Reply‑To email address.

Zendesk email system will receive the incoming message and treats it automatically as a legitimate response to the original ticket. As the attacker email address is now also listed in the CC field, Zendesk adds it as a participant in the ticket. In return, the malicious actor will gain a direct view to the ticket history, be able to look at any attached files and have the ability to post further replies.

The lesson learned was that ID‑based Reply‑To email addresses that are predictable are an attack path to penetrate into a system. An attacker who can infer a ticket ID can potentially gain unauthorized access to sensitive customer communications (customer data, internal processes, confidential attachments..).

What began as an already serious incident for Zendesk worsened significantly because the vulnerability went beyond data breach and foothold. There were other implications. For example, an attacker could now also exploit the chain of trust in verified domains and OAuth workflows (delegated authorization mechanisms) by claiming a domain-based email address.

Because many organizations use the same Single Sign‑On (SSO) providers for both Zendesk and Slack and that many services (like Apple, Google, Azure AD etc.) use a simple email verification code to prove that a user owns an address, a hacker could create a fake identity (e.g., an Apple ID) using a company support email address (e.g., [email protected]), wait for a verification code and then obtain a Slack login via OAuth. The interconnected nature of modern SaaS (Software-as-a-Service) applications like Zendesk and Slack was at risk due to an apparently small weakness (Zendesk weak verification of who actually owned a given email‑address or domain).

To address these concerns, Zendesk foster their security stance (email filtering, removing the collaboration option,..) and had to re-assess the scope of their peculiar Bug Bounty program. But as these changes occurred under customer pressure and global backlash, Zendesk reputation was immensely degraded. More on this topic here.

Situation In 2025

Even if the vulnerability was divulgated last year and dealt with by affected customers and Zendesk, the fallout may well continued for companies relying on this customer support tool or other similar third-party solutions.

One of the core issues is that a customer support portal must expect emails from any kind of worldwide customers and various email domains. With SSO authentication used in a client company, it is finally up to Zendesk and not the tenant own identity provider (IdP such as Entra ID, Okta or Google Workspace) to check the authenticity of an email sender which is inherently a major design flaw.

This occurs because when an email comes in from a new external customer (e.g., [email protected]), Zendesk does not validate it with the tenant IdP. Actually Zendesk cannot do the check because example.com is not part of the tenant’s domain.

The third‑party ticketing system will perform its own checks that may not reflect the organisation specific security posture. Because of that two-tier authentication scheme, legitimate customers may be blocked and malicious senders may be slipping through as well.

An IdP knows which domains, users and authentication policies belong to the company. Any organisation relying on an IdP should then delegate their email security to an appropriate identity vendor and not outsourcing email verification to the support provider platform.

Otherwise the overall security chain becomes fragmented. Even in an organisation with risk-based conditional access and MFA‑protected mail flow at their IdP level, if their third party customer support portal applies a separate and possibly weaker set of rules, it generates an attack surface that a hacker can exploit. This is why it is necessary that the third‑party service align their email handling with the organisation defined policies (e.g., as a contract baseline requirement).

Unifying policy enforcement from the start and following the tenant IdP authentication and conditional‑access policies will eliminate future security and compliance issues as well as positively facilitate future auditing.

From a security standpoint, it is critical to avoid security silos by centralizing email‑security decisions. Since IdPs frequently integrate with SIEM and SOAR systems, keeping email verification and other security checks within the IdP ecosystem and extending these checks to the support portal will improve detection accuracy.

Eventually security must stay a seamless part of the customer care experience and not a barrier to it. The balance can be achieved by setting up the mentioned secure processes that are easy for agents to follow and transparent for customers to understand.

Spoofing still relevant in 2025?

Even if the Zendesk major security flaw was largely resolved, this does not stop hackers to try other venues to break into an organisation system. Back-door bugs are still prevalent and attackers can blend AI deep‑fake, caller‑ID spoofing, SMS phishing or domain typo squatting to bypass any single control.

Spoofing will become more sophisticated and harder to detect mainly because legacy protocols (e.g., SMTP, DNS, SIP..) lack built‑in authentication. Another reason is that organisations are accelerating the integration of third party services, APIs, webhooks.. and this trend exposes more endpoints to hijacking or masquerading.

To avoid the cost of building and controlling their own end-to-end workflows, companies are delegating part of their core functions to other companies that in turn also rely on other companies to ease the burden and minimize cost.

The work function becomes intertwined by a high level of mixed vendors like matryoshka dolls except that these dolls are cooperating in a nuclear web. Each vendor is playing his part in the space opera and passing the performance (and diffused) accountability to the other low cost third party.

This permanent drive at minimizing cost (lowering operational expense) is in turn maximizing systemic risks (e.g., the 2017 Equifax Breach) and the client company often has zero visibility or control over these nested dependencies.

Given all of these vulnerabilities, spoofing vectors can more easily exploit technical and human weaknesses.

Albeit DMARC adoption has risen, many domains still publish permissive policies to avoid disrupting business operations (e.g., p=none; monitoring and report policy instead of p=quarantine or p=reject). This is a cautious and often necessary business decision during a domain rollout phase but if a company leaves this temporary measure in place, it creates a window of opportunity that attackers exploit with look‑alike domains.

Instead of spoofing yourcompany.com which has a stricter policy, attackers register your-company.com which almost certainly have no DMARC record or, at best, a p=none record. So emails from look‑alike domains face no real enforcement and land in the company inbox.

An example is an attacker who creates a Zendesk trial account (or even an account on another support platform) and configures it to use the fake look-alike domain (e.g., legitimate-company-support.com or legitimate-company.zendesk.com). One year ago, CloudSek pointed out that a free‑trial Zendesk sub‑domain feature “theoretically makes the SaaS provider vulnerable”.

Then the attacker sends emails to the customers of a target company from the fake email address ([email protected]) and makes use of a fake agent name (e.g., Legitimate Company Support Team). The combination of no DMARC enforcement and human trust means the targeted customers will glance at their inboxes, see an email from “Support” with the company name in the address, read the email about an issue they might actually have, likely miss the subtle domain misspelling and reply to the email or click an email link.

This threat extends beyond just email because the rise of endpoint integrations have become a new attack surface risk. An attacker can deceive a company into configuring a webhook or an API integration with their fraudulent Zendesk domain.

From the hijacked integration, the hacker could receive real customer data from the company. In a more serious case, if the integration has high permissions, it can be used to infiltrate the company network and access internal systems.

The Bottom Line

Spoofing is not a relic at all. It will continue to evolve to new technologies and adapt to human habits. Today AI-generated look-alike domains can rapidly be registered to outpace traditional defence detection. AI-crafted email content can also easily mimic usual business language. This can increase the likelihood of false negatives from both human reviewers and automated filters. And even if individual success rates remain constant, the increased volume of cheaply produced attacks will overwhelm defences through their scale and sophistication.

A robust defence against domain spoofing requires a multi-layered strategy consisting of technical controls (with strong authentication and strict email policies), continuous customer education, and proactive monitoring for emerging spoofing tactics. Below is a non exhaustive summary of the essential practices to stay ahead of these evolving threats.

The implementation of a strict DMARC policy (p=reject) for all owned domains is non-negotiable and must be reached as fast as possible. This will prevent direct spoofing of legitimate addresses and force attackers to use look-alike domains.

Then it is also important to registering common misspellings and the variants of a company primary domain. Once owned, applying a strict DMARC policy to these registrations will definitely cut the grass to the hacker.

Another important consideration is to use a custom domain and a fully hashed branding for customer-facing platforms like Zendesk. This reinforces legitimate communications and makes it easier for customers to identify fake sites.

Obviously technical controls must be supported with continuous customer education. The legitimate support company has to explicitly state the official domains from which communications will be sent and train users to watch out for sender addresses.

With growing regulatory pressure mandating stricter email authentication protocols and caller-ID verification becoming a compliance requirement (e.g., in Europe the EU’s e‑Privacy update, NIS2 or GDPR frameworks and also national cybersecurity agency mandates), a company has to adopt a zero-trust mindset and regularly audit email authentication configurations. Due diligence is then essential. It means verifying the vendor’s security certifications, past incident history and their commitment to continuous monitoring.

The Zendesk email spoofing story confirms that cost‑driven choices can be a risky shortcut for an organisation. Relying on insecure or low‑quality vendors to handle crucial tasks (e.g., to save money, enjoying short term convenience or for any other gain) can result in serious failures. Similarly, a vendor or involved third party must always demonstrate solid finances, strong security measures and a leadership committed to adequately fund their cybersecurity efforts.