ClickUp said its April 27, 2026 disclosure involved 893 customer email addresses in feature-flag targeting rules and one customer API token in a rate-limiting flag configuration. The company reported that it invalidated the token at 12:05 UTC on April 27 and removed customer email addresses from flag configurations by April 28 at 03:25 UTC.
Those figures, times and investigation conclusions come from ClickUp’s incident disclosure, not an independent forensic audit. ClickUp said it found no evidence of access to workspace content, passwords, billing data or account credentials, while treating the API token as a separate potential access concern. That is a report of its investigation, not proof that access was technically impossible.
This article separates ClickUp’s reported facts from independently documented product concepts, then turns the incident into a proposed control workflow. It does not claim that ClickUp, Split or Harness has publicly documented or implemented the workflow below.
What ClickUp says happened
ClickUp said customer email addresses had been placed directly in feature-flag targeting rules. It also reported that an on-call engineer placed one customer’s API token in a flag used to rate-limit that customer. ClickUp said the token was added on October 7, 2025 and invalidated at 12:05 UTC on April 27, 2026.
ClickUp reported that it audited 4,809 feature flags. It said customer email addresses were removed by April 28 at 03:25 UTC, while some third-party email addresses intentionally remained in two flags for fraudulent-use investigations. The disclosure therefore does not support saying that every email address was removed from every flag configuration.
ClickUp said its log review found no malicious access beyond the researcher’s investigation and no access to other customer tokens or workspace data. The underlying logs and permissions analysis are not public, so these remain ClickUp’s findings.
How client-side flag configuration became observable
A client-side SDK key is intended for a non-trusted environment such as a browser. It is not the same as a server-side administrative key. That distinction does not make every value delivered through the client safe: a browser user can inspect application assets, client state and network responses available to that browser.
ClickUp said its deployed Split setup made flag definitions and targeting rules accessible through an SDK-related endpoint, and that engineers had put email addresses in those rules. Older Split documentation describes a similar request for fetching flag definitions, but labels the call unpublished and warns that it may change. That legacy guidance is not a stable API contract or an independent reproduction of ClickUp’s 2026 deployment.
Current Harness documentation on client and server SDKs supports the present-day distinction between browser and trusted-server contexts. It should not be projected backward as proof of ClickUp’s exact historical behavior.
A client key may be public by design, but the configuration associated with it may still reveal sensitive information. Apply a client-visible means observable rule: review what the browser receives, not only the key’s administrative permissions.
Consider two targeting designs. A rule containing [email protected] places an identifiable value in configuration that may reach the client. A rule using an opaque identifier such as acct_8f31 avoids directly exposing an email address, although the identifier and surrounding data still require review. For a sensitive individualized decision, evaluate eligibility on a protected backend and return only the treatment result the client needs.
The API-token exception and the limits of an investigation finding
An API token is different from an email address because it may authorize actions according to its permissions. ClickUp said an on-call engineer put a customer token in a rate-limiting flag during an abuse response. It reported that the token was invalidated and that its log review found no malicious access beyond the researcher’s investigation. The disclosure does not publish the token’s permissions or the evidence behind that log review.
For a token found in client-visible configuration, response should not wait for a complete impact assessment:
- Revoke or rotate first. Record the old token’s fingerprint and revocation time in the incident system, never the raw value.
- Verify rejection. Use an approved, non-destructive check to confirm that the old value no longer works. Record this separately from the revocation request.
- Review reach and use. Check permissions, associated resources and available access logs. If the token was broad, expand the resource review even when no suspicious use is found.
- Remove copies and notify. Search flag revisions, build artifacts, tickets and logs for the credential fingerprint. Route customer communication through the approved incident process.
Use distinct statuses such as revocation requested, old value rejected, permissions reviewed and no evidence found in reviewed logs. A completed rotation is not verified until the old value is rejected.
Timeline and reporting-process breakdowns
ClickUp’s account distinguishes an earlier report about the SDK key from a later report about customer data and a token. On January 17, 2025, a researcher reported the key; ClickUp said that report concerned the key alone and was treated as informational. On April 8, 2026, a new HackerOne report described email addresses, the live token and other operational data. ClickUp said the April 10 duplicate closure missed that broader impact.
ClickUp said the researcher challenged the closure on April 21, attempted further escalation on April 25, and publicly disclosed the issue around 10:42 UTC on April 27. ClickUp reported that it became aware at 11:06 UTC, declared an incident and began response. It also said two other similar reports had been incorrectly closed, and that escalation emails were caught by spam filters while X direct messages were automatically filtered and unread. These process details are ClickUp’s account; the underlying HackerOne case and delivery records were not independently verified.
HackerOne’s duplicate-report documentation explains how duplicate reports can be handled, including whether a later reporter is added to the original report. It does not validate the specific ClickUp triage decision.
The operational lesson is to compare impact, not just report titles or shared product terms. A later report that adds customer PII, credentials, a different exploit path or materially broader reach deserves human review. Record both report IDs, the comparison and the reviewer’s rationale before deciding how to relate the reports.
A practical control workflow for flag changes
The workflow below is a proposed implementation pattern. The reviewed sources do not establish a public scanner API, ready-made connector or verified ClickUp, Split or Harness integration for this control. First confirm that the deployed product and SDK version provide a supported way to receive a specific flag revision, such as an approved export, API or change record.
Define the scan unit as provider project, environment, flag ID and immutable revision. Inspect nested targeting rules, target values, segments, variations, descriptions and relevant metadata. Keep the revision and finding paths as evidence, but do not copy raw secrets into tickets or scan logs.
For clear cases, deterministic rules should handle email syntax, known token prefixes, private-key delimiters, forbidden credential fields and high-entropy strings. AI can classify an ambiguous value or draft remediation language, but it should not be the sole gate for token blocking, production publication or duplicate-report decisions.
A structured finding should represent one finding in one flag revision, not an aggregate scan summary:
{
"flag_revision_id": "example-project/production/flag-123/rev-007",
"rule_path": "targeting_rules[0].values[0]",
"finding_type": "email_address",
"fingerprint": "sha256:illustrative-fingerprint",
"status": "blocked",
"review_owner": "security-team"
}This record is illustrative, not a vendor-published schema. Store the flag-revision record separately from individual findings. A finding key can use revision ID, normalized rule path, finding type and fingerprint. Enforce uniqueness with a database index and transactional upsert because lookup-then-create can race when workers run concurrently. If a provider sends duplicate change events, deduplicate by stable event ID where available while retaining original event provenance.
Four implementation decisions to make explicit
| Trigger | AI role | Validation | Action and fallback |
|---|---|---|---|
| New browser flag revision | Explain an ambiguous match | Schema check plus deterministic PII and secret rules | Block confirmed findings; hold scan failures |
| Customer-specific rollout | Not required for routine targeting | Opaque identifier and browser payload review | Use protected backend evaluation for sensitive decisions |
| Token found in configuration | Draft a checklist from approved facts | Old token rejected, permissions and logs reviewed | Revoke first, then expand resource review if scope is broad |
| Similar vulnerability report | Summarize impact differences | Compare asset, root cause, exploit path and affected data | Require human review when PII or credentials are added |
The proposed records also need the correct grain. One flag revision is not one finding, one incident event or one vulnerability report. Use separate records for each, with database-enforced uniqueness such as (provider_project, environment, flag_id, revision_id) for revisions and (flag_revision_id, normalized_rule_path, finding_type, finding_fingerprint) for findings. These are implementation recommendations, not vendor-published fields.
For teams reviewing their ClickUp workspace configuration and operating practices, a ClickUp audit may be relevant. For help designing ClickUp-based operational workflows, see ClickUp setup and automation. Neither link is presented as evidence of a feature-flag scanner.
Remediation status: completed actions versus planned controls
ClickUp reported completing four immediate actions: invalidating the customer token, removing customer email addresses from flag configurations, issuing an engineering-wide directive against PII and credentials in flags, and auditing all 4,809 flags. It qualified the email cleanup by saying third-party addresses remained in two flags for fraudulent-use investigations.
ClickUp described improved email filtering and spam review, a review of triage workflows with HackerOne, and reviewer training as short-term work. Its long-term plans included automated scanning with blocking enforcement, triage-review tooling and technical separation between frontend and backend flags. The reviewed sources do not establish whether those plans were later implemented or tested as of November 5, 2026.
Track each control in a remediation register with an action, named owner, due date, status, evidence link and verification result. Keep planned, implemented and tested as separate states. A policy announcement is not evidence that a technical gate blocks publication.
A reusable review checklist
- Can any value reach browser code, browser storage, client SDK state, network responses or telemetry?
- Have nested rules, segments, variations, descriptions and metadata been checked for email addresses, tokens, API keys and other prohibited data?
- Are targeting identifiers opaque, with identity lookup kept in a protected system?
- Is there a named feature owner and reviewer, with security approval and an expiration for every exception?
- Has the actual browser-visible payload been tested, and does a failed or skipped scan hold publication?
Use this as a change gate, then verify behavior against the exact SDK version and deployment. A rule that is safe in a server-side evaluation path may not be safe if the same data is delivered to a browser client.
Sources and evidence boundaries
- ClickUp’s April 27, 2026 disclosure is the primary source for the incident scope, timeline, investigation findings and remediation status. It is ClickUp’s account, not an independent forensic report.
- The older Split help article provides historical context for an SDK request to fetch definitions. It calls the request unpublished and warns that behavior may change.
- Harness’s current feature-flag FAQ documents current client-side and server-side SDK concepts. It does not reconstruct ClickUp’s historical Split deployment.
- HackerOne’s duplicate-report documentation explains report-handling mechanics, not the specific ClickUp triage decision.
- ClickUp’s vulnerability disclosure policy states its reporting channel and commitments. It is not evidence of incident-specific process performance.
The practical standard is straightforward: keep credentials and unnecessary personal data out of client-visible configuration, inspect the actual delivery path, and retain revision-level evidence showing who reviewed a finding and why it passed or was blocked.
