Critical Security Failures in ClickUp: Hardcoded Tokens and SSRF Vulnerabilities Expose Enterprise Data

A series of profound security lapses within the widely used productivity ecosystem, ClickUp, has come to light, resulting in the exposure of sensitive organizational data. The breach includes 959 high-value email addresses belonging to Fortune 500 companies and various government agencies across three different nations.

At the heart of this exposure is a textbook breakdown in secret management: a Split.io SDK token was found hardcoded directly within ClickUp’s production JavaScript bundle. Because this script is served via the platform’s Content Delivery Network (CDN), it loads automatically for any visitor. The implications are severe; an attacker does not require authenticated access or an active user session to exploit this. By simply inspecting the client-side source code, an unauthorized actor can extract the SDK key and interact with the backend.

The vulnerability was brought to light by security researcher @weezerOSINT, whose investigation revealed that these critical architectural flaws may have persisted for over a year without remediation.

The technical impact of the leaked token is substantial. A single, unauthenticated request to the Split.io API using the compromised credential returned a 4.5MB payload of backend telemetry and configuration data. This “data dump” provided a direct window into the identities of enterprise clients and government personnel.

From Data Leak to Cloud Compromise: The SSRF Threat

While the leaked API key represents a major data privacy failure, the researcher also identified an even more catastrophic vulnerability: a Server-Side Request Forgery (SSRF) flaw within ClickUp’s webhook API. In a secure environment, webhooks should be strictly validated to ensure they cannot be used to probe internal networks. However, ClickUp’s implementation lacked these fundamental protections, allowing external inputs to force the server to initiate requests to internal resources.

Visual proof of a live ClickUp API token embedded in a flag capture
A captured flag containing a live ClickUp API token during the researcher’s exploit demonstration (Source: Twitter)

To demonstrate the exploitability of this flaw, the researcher utilized a standard free-tier ClickUp account to configure a webhook targeting the AWS Instance Metadata Service (IMDS). By performing a routine action—creating a simple task—the researcher triggered the webhook, forcing ClickUp’s server to query the AWS metadata endpoint. The response successfully returned internal AWS Identity and Access Management (IAM) credentials.

This transition from an application-level bug to a potential cloud infrastructure takeover highlights the gravity of SSRF. It provides a bridge for attackers to pivot from the public internet directly into the heart of a company’s private cloud environment.

The Compliance Paradox: Ignored Reports and Audit Gaps

The most troubling aspect of this incident is not just the technical vulnerability, but the apparent breakdown in the vulnerability disclosure process. When the researcher reported the hardcoded Split.io token, ClickUp closed the security ticket after only two days, labeling it a “duplicate” of a report originally filed in January 2025.

If accurate, this suggests that ClickUp has been aware of this specific exposure for approximately 15 months without implementing the necessary architectural changes to rotate the token or remove it from the client-side bundle. This represents a significant lapse in incident response and risk management.

Furthermore, this incident raises questions regarding the efficacy of ClickUp’s compliance frameworks. The company heavily markets a robust security posture, citing several industry-standard certifications, including:

  • SOC 2 Type 2: Controls regarding security, availability, and confidentiality.
  • ISO/IEC Certifications: Including 27001 (ISMS), 27017 (Cloud Security), 27018 (PII in Cloud), and 42001 (AI Management).
  • PCI DSS: Standards for protecting cardholder data.

The fact that a hardcoded API key and an unprotected SSRF endpoint remained active for over a year suggests a disconnect between theoretical compliance and practical, continuous security monitoring. This follows a pattern observed in recent weeks, where similar unauthenticated exposures—such as the one seen in Fireflies.ai—have highlighted the recurring challenge of securing large-scale SaaS platforms against sophisticated reconnaissance.

Related Articles

Back to top button