On April 27, 2026, a security researcher publicly disclosed that ClickUp’s client-side feature flag configuration exposed personally identifiable information. Specifically, 893 customer email addresses were embedded in feature flag targeting rules, along with one flag that improperly referenced a customer’s API token, used during an incident response to rate-limit traffic from that workspace.

We should have caught this sooner. We didn’t, and we owe you a clear explanation of what happened, why, and what we’ve done about it now and how we’re improving moving forward.

Are you affected?

The exposure was limited to 893 customer email addresses used in feature flag targeting rules to control which users see specific features during rollouts.

If you receive a direct communication from before or on April 29 (ongoing), your email address was among those included in a feature flag configuration. If you did not hear from us, your email was not in the list of email addresses.

No workspace content (tasks, docs, files, or project data) was exposed for any customer — with one potential exception described below.
No passwords, billing data, or account credentials were exposed.
No authentication systems were compromised.

The technical issue

ClickUp uses Split.io (now part of Harness) for feature flag management. Like most browser-side feature flag SDKs, Split.io requires a client-side SDK key embedded in the application’s JavaScript bundle. This key is intentionally public and it’s how the SDK evaluates flags for the current user in the browser. This is standard, documented behavior across Split.io, LaunchDarkly, and similar platforms, and it is not a vulnerability.

The key is not the issue. What our engineers put inside the flag configurations is.

Here’s what happened architecturally: feature flag platforms allow engineers to target specific users for feature rollouts. ClickUp engineering teams had used email addresses directly in flag targeting rules. An example is to enable a feature for a specific set of beta testers. The Split.io SDK’s publicly queryable splitChanges endpoint returns the full set of flag definitions, including these targeting rules. This means anyone with the client-side key (which, again, is intentionally in our frontend code) could retrieve those flag definitions and extract the email addresses embedded in them.

Engineers treated flag configurations as internal tooling, when the SDK architecture makes them publicly queryable by design. That allowed the email addresses to accumulate in a place they never should have been. Feature flag updates require a +1 peer review, similar to code. This review step did not catch this.

The one exception – A flag configured for rate limiting a single customer

An on-call engineer responding to API abuse referenced a customer’s API token in a rate-limiting flag configuration to throttle traffic, making it potentially readable via the SDK endpoint. This should never have happened: credentials do not belong in flag configs. We disabled the token immediately, and as of now, our log investigation shows no signs of malicious access beyond the researcher’s own investigation. No other customer tokens or workspace data were accessible, and we’re working directly with this customer.

What was exposed and what wasn’t

Claim	Our finding
SDK key hardcoded in bundle	Correct and by design. This is how browser-side feature flag SDKs work. Not a vulnerability alone.
893 customer email addresses in flag targeting rules	Correct at time of report. All third-party email addresses removed by April 28, 03:25 UTC.
Live customer API token in flag config	Confirmed. Added October 7, 2025. Invalidated April 27, 2026 12:05 UTC.
Write access to Split.io	Correct and by design. The browser SDK’s telemetry endpoints (events/bulk, testImpressions) accept writes as part of standard SDK behavior. This is not a ClickUp misconfiguration.
“No remediation for 15 months”	Mischaracterized; dates are correct. The original January 17, 2025 bug bounty report about the SDK key did not result in an engineering task as the key alone is not the vulnerability. The email addresses and flag configurations were the actual issue and not included in this original report. The flag configurations were not disclosed until April 8, 2026 to HackerOne and not known to ClickUp until April 27, 2026.

Timeline

We are committed to being fully transparent about where our processes failed, including failures by our third-party bug bounty provider and our own internal communication tools.

Date	Event
2025-01-17	A researcher reports the Split.io SDK key disclosure to our bug bounty program on BugCrowd. This was, given the report’s contents, correctly marked as informational by BugCrowd and ClickUp.
2025-06-03	ClickUp moves the bug bounty program to HackerOne. All past reports are successfully migrated, including the issue above.
2026-04-08	Researcher under the handle `impulsive` files a new, detailed report on HackerOne documenting expanded impact: 893 customer email addresses in flag targeting rules, the live customer API token, and other operational data.
2026-04-10	HackerOne triage analyst incorrectly closes the report as a duplicate of the January 2025 report, missing that the new report documents materially different and expanded impact. On further review we identified two other instances of similar reports being incorrectly closed – one on September 6, 2025 and one on January 1, 2026
2026-04-21	The researcher pushes back on the closure with additional detail to HackerOne.
2026-04-25	The researcher escalates: inside HackerOne emailing ClickUp’s CEO and security@clickup.com DM’ing ClickUp on X sets a May 2 public disclosure deadline. These emails to ClickUp CEO and security@ are caught by spam filters and do not reach the intended recipients. The X DMs to ClickUp were automatically filtered and not read.
2026-04-27 ~10:42 UTC	The researcher publicly discloses on X.
2026-04-27 11:06 UTC	ClickUp becomes aware. Incident declared. Incident Response process kicks off and process to rotate the customer API token was initiated.
2026-04-27 12:53-14:12 UTC	Initial split flag cleanups across engineering squads.
2026-04-27 ~17:00 UTC	Full automated audit of all 4,809 feature flags completed.
2026-04-27 23:13 UTC	ClickUp and Harness (Split) engineers review technical details.
2026-04-28 03:25 UTC	All customer email addresses confirmed removed from flag configurations. Note: some third party email addresses intentionally remain in two flags; related to fraudulent use.

Where our process failed

Three things went wrong here, and we want to name each one clearly. We will discuss changes in the following section.

1. No second-order follow-through on the original report. The January 2025 bug bounty report could have resulted in an engineering task and a review of what data was living inside flag configs. It didn’t. We are updating our triage process to prevent this from happening again in the future.

2. HackerOne mishandled the duplicate closure. The April 2026 report documented substantially new impact compared to the January 2025 report. It should not have been closed as a duplicate by HackerOne. On further review, we identified two other instances of similar reports being closed – one on September 6, 2025, and one on January 1, 2026. We are working with HackerOne to address gaps in their triage processes. We will be including a secondary review of all HackerOne reports to ensure we aren’t reliant on third-party processes moving forward.

3. Our email service flagged the researcher’s escalation in spam. On Saturday, April 25, 2026 the researcher emailed both our CEO and security@clickup.com, and DM’d ClickUp’s X account.

We did not see these emails until after the public X post. They were found following an internal investigation into spam folders and X DM filtering.

We are updating our email filtering and spam review processes to ensure security-related inbound communications are not silently dropped.

None of these excuse the core issue: customer data should never have been in our feature flag configurations in the first place.

What we’ve done

Immediate (completed)

Invalidated the exposed customer API token.
Removed all customer email addresses from feature flag configurations.
Issued an engineering-wide directive prohibiting PII or credentials in flag configurations.
Completed a full audit of all feature flags for PII, credentials, and sensitive data.

Short-term (in progress)

Updated email filtering rules to ensure security@clickup.com surfaces all inbound security communications, adding a process step to (safely) examine spam messages.
Review of bug bounty triage workflows with HackerOne to prevent valid reports from being incorrectly closed.
Training of feature flag reviewers on what are approved contents.

Long-term

Automated scanning of all feature flag configurations for PII patterns (email addresses, tokens, API keys) on every flag change, with blocking enforcement.
An automated process and tooling to review all HackerOne triage decisions.
Implement a proxy or technical measure to separate front-end flags and back-end flags.

A note on the researcher

Once ClickUp was in contact with the researcher who disclosed this, operating under the handle impulsive / @weezerOSINT, they acted responsibly and provided all information requested.

The researcher, operating under the handle impulsive / @weezerOSINT, reported through proper channels (HackerOne, then direct email to security@clickup.com and our CEO) and engaged constructively when we made contact. Our internal processes failed to surface their report and escalations in time.

After working with the researcher, ClickUp received the following message on April 28, 2026 at 1:47 UTC: “Thanks [ClickUp], really appreciate how fast you’ve moved on this. Not something I see often and it makes a difference.”

ClickUp is rewarding the researcher with a bug bounty for their findings. Other researchers are encouraged to join our Bug Bounty program, report responsibly through our Vulnerability Disclosure Program, or directly via email at security@clickup.com.

Summary

The data exposed in this incident was limited in scope to 893 email addresses – no workspace content, passwords, or billing data was affected for any customer, with the exception of a single customer referenced above – we are working with them directly to verify the key wasn’t improperly accessed.

To our customers, we greatly apologize that this happened, and we’ll do everything in our power to ensure something like this cannot happen again.

We’ll update this post if new information is uncovered. If you have questions, contact security@clickup.com.

April 27th – What happened with our feature flag configuration