Coinbase and Amplitude: the breach was at the vendor, the risk reaches customers

Amplitude detected unauthorized access on 28 September 2026; public statements appeared on 28 October. Analysis written on 4 November. Amplitude says it contained unauthorized access to a localized portion of its systems on 28 September. Event data belonging to fewer than 0.3% of Amplitude’s business customer accounts was affected. Coinbase said a small subset of its customers’ contact data was among the affected information. It reported no evidence of unauthorized access to Coinbase systems and no impact on customer funds. A company spokesperson later described contact and limited transaction data to Unchained and said home addresses were not included.

The percentages are easy to misuse. Amplitude’s 0.3% denominator is its business customers, not Coinbase’s account holders. Coinbase has not published an affected-person count. Its spokesperson disputed a social-media claim of 70,000 affected Coinbase users. Neither statement supports converting a vendor percentage into a Coinbase user count.

The trust boundary created by analytics

An analytics integration sends events from an application to a supplier. The customer chooses the event names and properties; depending on the implementation, those properties may contain persistent identifiers, contact details or transaction context. The provider stores and processes a second copy of that information under its own access controls. The question after a vendor incident is therefore not limited to whether the financial application’s production database was breached. It includes which data crossed into the analytics service and who could read it there.

Neither company has published the exact Coinbase event schema, the identity used to access Amplitude or the intrusion method. Amplitude explicitly says this incident was unrelated to the recent PHP2Shell and Node.js vulnerabilities. A narrative claiming one of those CVEs as the entry point would be speculation. The model above explains the exposure path through an analytics vendor, not the still-undisclosed forensic route into Amplitude.

Exploitation risk without stolen credentials

Contact details paired with limited transaction context can make a fraudulent call or message appear relevant. An attacker could refer to an activity, impersonate support and ask the recipient to reveal an authentication code or approve a transfer. That is a plausible secondary fraud path, not an observed theft attributed to this incident. Coinbase says customer funds were unaffected and has not reported passwords or private keys being exposed in these statements. Its phrase “Coinbase has not had a data breach” refers to its own systems; customer data held by a supplier can still be exposed.

An organization using analytics can investigate by capturing the events its SDK sends in a test environment, comparing fields against an approved allowlist, and reviewing vendor retention, export permissions and account logs. The vendor’s global incident percentage does not replace an affected-person list. Endpoint and account owners should verify notices through a known channel rather than a link in an unsolicited message. Coinbase says it is notifying affected customers and regulators.

The practical lesson is to follow personal data all the way to external processors. Strong controls around a transaction system do not protect a copy sent to another platform.

The attack reported by Arkéa helps distinguish a vendor compromise, the operations it enables and the data it holds. If analytics events later feed a knowledge base or assistant, enterprise RAG access controls apply to that additional copy. This is a design consideration, not a description of Coinbase’s architecture.

Sources: Amplitude customer update, Coinbase statement, Coinbase spokesperson’s details reported by Unchained.