A CDP both leaks and pollutes: Segment key abuse explained
Leaked Segment keys let an attacker read unified customer identity profiles and inject fake events that fan out to every destination. It is a confidentiality and an integrity event.
Segment is the Customer Data Platform that unifies identity across your systems and fans events out to every connected destination. A leaked key can both leak unified profiles and pollute every downstream system.
How the attack works
A source write key and an access key leak. The access key is used from an unfamiliar source to query the profiles API and read unified customer profiles in bulk, pulling cross-system identifiers and traits far beyond any normal application read. The write key then publishes fabricated track and identify events that Segment fans out to connected destinations such as ad audiences, CRM, and the warehouse, polluting downstream records. The attack runs in two directions at once: a read that leaks and writes that poison. In ATT&CK terms this is T1552, Unsecured Credentials, and T1078, Valid Accounts, with T1213, Data from Information Repositories, for the read and T1565, Data Manipulation, for the injection.
Why it works
The write key was embedded in a client app and the access key was broadly scoped, and a CDP is high-leverage because one source fans out to many destinations.
How to fix it
The non-obvious move is to contain at the source, not at one destination: pausing one destination leaves the fan-out to every other destination intact and the reads continuing. Rotate both the source write key and the access key so injection and profile reads stop at the source, then review every connected destination for tampering. For the class fix, move sensitive writes server-side, scope and store keys in a secret store with rotation, restrict the access key’s profile scope, and add anomaly detection on event patterns and profile-read volume. Scope both halves: the profiles API logs for reads, and the source and destination delivery logs for injections.
Practice it
We built this as a GraphLattice Range scenario so teams can rehearse the dual read-and-poison attack, the rotate-both-keys-at-the-source containment, and the combined confidentiality and integrity obligations.