A security researcher’s public disclosure on April 27 forced ClickUp to confront a misconfiguration its own engineering review process had missed for months. 893 customer email addresses embedded directly inside feature flag targeting rules, queryable by anyone with the platform’s intentionally public client-side SDK key.
ClickUp published its incident disclosure the following day. The company did not minimize what happened. “We should have caught this sooner. We didn’t,” the company said.
What Did ClickUp Expose
The exposure involved two distinct issues within the same feature flag configuration system. The first was the email addresses themselves — 893 customer addresses that ClickUp engineers had embedded in flag targeting rules to control which users received specific features during staged rollouts.
The Split.io SDK’s publicly queryable splitChanges endpoint returns the full set of flag definitions, including those targeting rules, to anyone holding the client-side SDK key. Because that key is intentionally embedded in ClickUp’s frontend JavaScript bundle — standard, documented behavior across Split.io, LaunchDarkly, and similar platforms — the email addresses were accessible without authentication to anyone who knew where to look.
Also read: AI-Coded Moltbook Platform Exposes 1.5 Mn API Keys Through Database Misconfiguration
No workspace content, passwords, billing data, or account credentials were exposed for any of the 893 affected customers, with one exception, the company said.
The second and more serious issue was a single live customer API token embedded in a rate-limiting flag configuration. An on-call engineer responding to API abuse had placed the token directly inside the flag config to throttle traffic from that workspace — a decision that made the token recoverable through the same SDK endpoint.
The token was added on October 7, 2025, and remained in the flag configuration until ClickUp invalidated it, this Monday. Log investigation showed no signs of malicious access beyond the researcher’s own investigation. ClickUp said it is working directly with the affected customer.
All 893 third-party email addresses were removed from flag configurations by Tuesday.
The Technical Root Cause
The misconfiguration is architectural in nature and required no exploitation in the conventional sense. ClickUp uses Split.io for feature flag management. Client-side feature flag SDKs by design require a public-facing key embedded in the application bundle — this is how they evaluate flags for users in the browser, and it is standard behavior across the industry. The key being public is not a vulnerability.
What made this an exposure is what ClickUp’s engineers placed inside the flag configurations themselves. Flag targeting rules allow engineers to specify exactly which users receive a given feature — by email address, user ID, or other identifiers. ClickUp’s teams had used customer email addresses directly in those rules for beta rollouts. Because the splitChanges endpoint returns the full flag definition set including targeting rules, and because the client-side key needed to query it was always accessible in the frontend JavaScript, those email addresses were queryable by design of the SDK — just not by design of ClickUp’s intent.
Engineers treated flag configurations as internal tooling, the company acknowledged, when the SDK architecture makes them publicly queryable by design. Flag updates at ClickUp required peer review — a process analogous to code review — but that review step did not catch the accumulation of PII in targeting rules.
The Disclosure Timeline
ClickUp’s blog includes a precise timeline that addresses a specific claim circulating in public reporting: that this vulnerability went unremediated for 15 months after an initial disclosure in January 2025. ClickUp disputes that characterization and the timeline explains why.
On January 17, 2025, a researcher reported the Split.io SDK key disclosure to ClickUp’s bug bounty program, which was then hosted on BugCrowd. ClickUp and BugCrowd classified that report as informational — because the client-side SDK key alone is not a vulnerability. It is public by design. That classification was correct given the report’s contents, ClickUp says, because the email addresses embedded in the flag configurations were not included in that original report.
ClickUp migrated its bug bounty program from BugCrowd to HackerOne on June 3, 2025, with all past reports carried over.
On April 8, 2026, the researcher filed a new, detailed report on HackerOne — a different report from the January 2025 submission — documenting the expanded impact of 893 customer email addresses in flag targeting rules and the embedded API token. ClickUp says it was not aware of the email address exposure until April 27, the day the researcher went public. The company says the flag configurations themselves were not included in the original 2025 report, and the “15 months” framing conflates two separate reports about two different findings.
What ClickUp Has Changed
ClickUp described four remediation steps taken in the immediate aftermath. All customer email addresses were purged from flag targeting rules and replaced with internal user identifiers that carry no PII. The company has implemented automated tooling to detect email addresses and credential patterns in flag configurations before they can be saved. A secrets scanning step has been added to the flag configuration deployment pipeline. And the engineering team has updated its internal guidance on what data is permissible inside flag targeting rules.
The peer review process that existed prior to the incident — a required +1 approval on all flag changes — remains in place but clearly did not catch this class of misconfiguration. The new automated tooling is designed to fill that gap at the system level rather than relying on reviewers to catch it manually.
Customers whose email addresses were among the 893 affected were notified directly by ClickUp on or before April 29, 2026. Customers who did not receive a direct communication were not in the exposed list.
