ClickUp Hardcoded API Key Exposed Enterprise and Government Emails for Over a Year With No Fix
A hardcoded third-party API key embedded in ClickUp's publicly accessible website JavaScript exposed hundreds of corporate and government email addresses — along with thousands of internal product development flags — for more than a year with no authentication required to access the data. ClickUp has not issued a public statement.
SAN FRANCISCO, CA — A security researcher identified a hardcoded API key in a JavaScript file that loads on ClickUp's public website before any authentication, allowing anyone to query a backend endpoint via a single GET request and retrieve sensitive organizational data. The flaw was first reported in January 2025 and remained active as of April 28, 2026 — a 15-month exposure window with no confirmed remediation and no public response from ClickUp.
The incident is not a breach in the traditional sense — no server was intrusion and no attacker is confirmed. But the combination of trivial exploit complexity, a high-value data category, a prolonged remediation failure, and the absence of any vendor communication makes this a significant and instructive security failure.
What Happened
Security researcher Impulsive published findings on X describing the discovery in straightforward terms: "I went to clickup.com, opened the page source, and found a hardcoded API key in the javascript. I sent one GET request and got back 959 email addresses and 3,165 internal feature flags."
The API key was embedded in a JavaScript file that loads on ClickUp's public website prior to any authentication step — meaning it was fully visible to any visitor who viewed the page source, which requires nothing more than a right-click or Ctrl+U in any browser. The key was associated with a third-party backend endpoint that had no access controls, allowing it to be queried directly by anyone who extracted the key.
Why This Matters More Than the Scale Suggests
At 959 emails, the raw count is small compared to large-scale data breaches measured in millions of records. But several factors make the risk profile more serious than the number implies. The email addresses belong to employees at large enterprises and government entities — a demographic that is high-value for targeted spearphishing, credential stuffing, and business email compromise campaigns. These are not generic consumer email addresses; they are organizational access points.
The 3,165 internal feature flags represent a separate and underappreciated risk category. Feature flags are internal configuration switches that control which product features are enabled, for which users, in which environments. They reveal what ClickUp is building, testing, and rolling out — including unreleased capabilities, beta features, and A/B test configurations that have not yet been hardened for production security. For a competitor or a sophisticated threat actor scoping ClickUp's infrastructure, this is valuable intelligence that extends well beyond the PII exposure.
Scope and Impact
The 15-month exposure window is the most significant factor in this incident. The flaw was first reported in January 2025. It remained active as of April 28, 2026. During that entire period, anyone who independently discovered the hardcoded key — through routine security research, automated scanning, or accidental discovery — had unmonitored access to the exposed data with no indication that their requests were being logged or reviewed.
Organizations whose domains appear in ClickUp's customer list should treat their email addresses as potentially exposed and review any unusual phishing or account activity from January 2025 onward. The absence of any ClickUp public statement or notification means affected organizations have received no official disclosure.
Response and Attribution
This is a data leak stemming from a misconfiguration, not a server intrusion by an external attacker. The root cause — a hardcoded API key in publicly accessible client-side code — is a well-understood and entirely preventable class of vulnerability. Secrets scanning tools from GitHub, GitGuardian, TruffleHog, and others exist specifically to detect API keys before they reach production. The fact that this key survived in public JavaScript for 15 months suggests either that no automated scanning was in place, that alerts were not acted on, or that the issue was deprioritized after initial disclosure.
The CyberSignal Analysis
Signal 01 — Client-Side Code Is Public by Definition
This is not a subtle architectural mistake — it is a foundational violation of secrets management principles. Any value embedded in JavaScript that loads in a browser is visible to the entire internet. There is no ambiguity here. API keys, tokens, and credentials must never appear in client-side code. The tools to prevent this — pre-commit hooks, CI/CD secret scanning, automated rotation alerts — are freely available and widely used. A hardcoded secret in public JavaScript that survives for 15 months is not a technical failure; it is a process failure.
Signal 02 — Feature Flag Exposure Is an Underappreciated Risk Category
The security community tends to focus on PII when evaluating data exposures, and appropriately so. But the 3,165 internal feature flags exposed here represent a class of risk that rarely gets adequate attention. Internal product configuration data reveals development priorities, upcoming capabilities, experimental rollouts, and testing environments — information that can be used to identify attack surfaces before they are hardened and disclosed, to plan targeted platform abuse, or to gain competitive intelligence. Organizations should treat internal configuration data with the same sensitivity classification as user data.
Signal 03 — 15 Months Is a Governance Failure, Not a Technical One
Rotating an API key and removing a hardcoded secret from client-side code is not a complex remediation. It can be completed in hours by a single engineer. The 15-month duration between initial disclosure and this publication — with no confirmed fix and no public statement — is not explained by technical complexity. It is explained by a breakdown somewhere in the vulnerability management process: triage, prioritization, tracking, or accountability. For organizations evaluating SaaS vendors, this incident is a useful benchmark for what inadequate security program governance looks like in practice.
