On October 28, 2026, Coinbase disclosed that a security incident at Amplitude, its third-party product analytics provider, had exposed contact information for a small subset of its customers. Coinbase says it found no unauthorized access to its own systems and that customer funds were not affected. A spokesperson later told the crypto publication Unchained that the data included contact details and limited transaction data, but not home addresses or anything an attacker could use to reach an account or its funds.
At first glance this looks like a narrow data exposure. Nobody has announced a compromise of Coinbase’s wallets, and neither company has said attackers obtained the credentials needed to get into customer accounts. Still, the incident raises a question I think security engineers should take seriously: how much customer information should a company let accumulate on systems it does not control?
Product analytics platforms sit in an odd spot in modern application architectures. They don’t handle authentication, transaction authorization or custody of digital assets, yet they can receive detailed records of how customers use those systems. Depending on the implementation, that can include account identifiers, contact details, event timestamps, application metadata and the way a person interacts with financial products.
That creates a second attack surface. Breaching an analytics provider doesn’t mean the exchange itself was breached, but the data can still help an attacker identify, profile and impersonate customers.
Nothing disclosed so far shows that Coinbase’s trading infrastructure or wallet security failed. Equally, the absence of reported stolen funds doesn’t mean customers face no risk. A failure at one organization can create downstream risk for the users of another.
Coinbase Amplitude breach timeline: what is confirmed
Amplitude’s security team detected unauthorized access to a localized portion of its internal systems on September 28, 2026. In its October 28 security update, the company said it had contained and remediated the incident and brought in an independent digital forensics firm. Amplitude said event data tied to fewer than 0.3% of its customer accounts was affected, that it contacted those customers directly, and that its investigation found no end-user information exposed for customers outside the affected group.
Coinbase published its own disclosure the same day. It attributed the exposure to Amplitude and said contact data for a small subset of its customers was affected, along with information belonging to other Amplitude customers. Coinbase said its investigation found no unauthorized access to Coinbase systems and no impact on customer funds, and that it was notifying affected customers and the relevant regulators.
The two statements measure different things. Amplitude described its own customer accounts and internal systems, while Coinbase described what happened to its customers. You can’t use Amplitude’s percentage to estimate how many Coinbase users were affected, because the denominator is Amplitude’s customer-account population, not Coinbase’s user base.
How many Coinbase customers were affected?
The claim that more than 70,000 Coinbase customers were affected is not a confirmed figure. Unchained reported that a Coinbase spokesperson rejected that number and suggested it came from confusion with the company’s separate May 2025 incident. In the disclosures I reviewed, Coinbase has not published a verified count of affected users.
The month between detection and public disclosure
Amplitude detected the incident on September 28, a month before its public update. The statements don’t explain when Coinbase learned of it, when the company established that Coinbase-related information was involved, or how the exposure was discovered. That interval is a fair question for incident-response analysis. By itself it is not evidence of slow detection, concealment or an inadequate response, and reaching those conclusions would take a fuller timeline and evidence about the investigation.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →Amplitude’s status page and the security incident
Amplitude’s public status page did not list a security incident on October 28. It did record operational incidents earlier in October, including ingestion delays and other service disruptions. Those events are separate from the breach: an outage and unauthorized access are different kinds of event, and the published status history doesn’t show a causal link between them.
What remains unconfirmed
Three things are established. Unauthorized access occurred within a portion of Amplitude’s internal environment. Data associated with a small subset of Coinbase customers was affected. Coinbase reports no unauthorized access to its own systems and no impact on customer funds.
The public disclosures I reviewed do not establish the attack vector, the complete set of exposed fields, the number of affected Coinbase users, or the identity of the other affected Amplitude customers.
Why Coinbase uses a product analytics provider
A cryptocurrency exchange is more than an order-matching engine and a set of wallet services. Its application covers account registration, identity verification, asset discovery, deposits, withdrawals, trading interfaces, support workflows and security settings. Product and engineering teams need to know how customers move through those features, where workflows fail, which changes improve usability and whether a new release adds friction.
An analytics platform such as Amplitude answers those questions by collecting events generated during app use. An event might be the opening of a trading screen, a failed form submission, a completed onboarding step or a visit to a security settings page. The platform processes these records so teams can analyze user journeys, compare cohorts and measure the effect of product changes.
A simplified event might look like this:
json
{ "event_type": "security_settings_viewed", "user_id": "usr_8f21c9", "device_id": "dev_a72b1d", "time": 1793217600000, "event_properties": { "platform": "web", "application_version": "4.12.0" }}
This is an illustrative example. It is not a recovered Coinbase event or a representation of the payloads involved in the incident.
The event type describes an action, the timestamp orders events, and the application properties add context. The user and device identifiers let the platform correlate activity across sessions.
That information is useful for product analysis without revealing who the customer is. Trouble starts when the implementation also sends email addresses, phone numbers or identifiers that map readily back to an account holder.
A team can have a legitimate reason to link product usage to known customer records. It might want to know whether customers who complete identity verification hit fewer errors during onboarding, for example. That goal doesn’t justify sending directly identifying information to every system involved in measuring the workflow.
Does an analytics service need to know who the customer is?
The central architectural question is whether the analytics service needs to know who a person is, or only needs a stable identifier that groups events from the same pseudonymous user. Those are different requirements. Treating them as interchangeable can turn a routine observability integration into a repository of sensitive customer information.
How product analytics architecture moves customer data to vendors
A typical product analytics integration has several stages. The application generates an event when a user performs an action. A software development kit (SDK) collects the event and attaches metadata, then sends the payload to the provider’s ingestion endpoint, where the service validates and processes it. Events may then be stored, transformed, exported or queried by authorized users and downstream systems.
A simplified data flow looks like this:
text
Customer | vCoinbase Web or Mobile Application | vAnalytics SDK | | Event payload | User/device identifier | Application metadata vAmplitude Ingestion Endpoint | vAnalytics Processing and Storage | +----> Product Analytics | +----> Cohort Analysis | +----> Authorized Exports and Integrations
The diagram shows a general analytics architecture. It does not establish the exact Coinbase implementation, the location of the exposed data or the path the attacker used.
The boundary that matters sits between event generation inside the client application and the storage and processing environment the analytics vendor operates. Once an application sends data to a third party, that data falls under the vendor’s access controls, identity systems, storage permissions, administrative interfaces, integrations and incident-response procedures.
A secure deployment has to look beyond encryption in transit. It needs to cover what information is sent, how the provider authorizes access, which users and services can query the data, how exports are controlled, and whether the data can be linked to a real customer.
Why encryption alone doesn’t prevent a vendor data breach
HTTPS protects events against many forms of interception in transit. It does not stop an attacker who has valid access to the destination environment from reading whatever that access allows. Encrypting stored records doesn’t necessarily help either if the attacker compromises an application account that holds legitimate decryption privileges.
That is why the full access path matters more than the location of the breach. The useful questions are whether the attacker could reach the relevant records, through which permissions or vulnerabilities, and whether those records held anything the analytics service needed to do its job. Whether Amplitude had encryption enabled answers only a small part of that.
What caused the Amplitude breach?
Amplitude has described unauthorized access to a localized portion of its internal systems, and the disclosures I reviewed don’t establish the mechanism. Pinning the incident on a stolen credential, an exploited vulnerability, excessive permissions, a compromised employee account or an insecure export integration would be premature. Each is a plausible risk category in a cloud service, but none can be presented as the confirmed cause without forensic evidence.
That uncertainty limits what we can say about any single control. Rotating credentials makes sense if a credential was exposed. Tighter role-based access matters if excessive permissions enabled the access. A software patch matters if an exploited vulnerability turns up. Without root-cause findings, naming one of these as the definitive fix is speculation.
The defensible engineering response is to examine the entire data flow, reduce unnecessary exposure, and make sure the investigation identifies the actual access path before anyone chooses controls.
