Amplitude Calls It Event Data. Coinbase Calls It Contact Data. Neither Says How Many.

4:09 PM Central, September 28

At 4:09 PM Central on Monday, September 28, someone at Amplitude opened the company's public status page and typed a short notice for its customers. The headline read "We are actively investigating an incident in our data exports." The body was one reassurance: "Once the issue is resolved, data will continue to be exported. No data is lost."

Twenty-seven seconds later came a second line, that the investigation was continuing. Two and a half hours after that came the first substantive update. "Warehouse exports should now start exporting data to warehouses and storage buckets but explicit export APIs are still blocked." At 9:33 PM Central the notice was closed with five words: "This incident has been resolved."

Thirty days later, on Wednesday, October 28, Amplitude posted a different kind of notice, this time in its trust center rather than on its status page. It said that "On September 28, 2026, our security team detected, contained, and remediated unauthorized access to a localized portion of Amplitude's internal systems," and that the incident "impacted event data belonging to less than 0.3% of customer accounts."

Nobody outside Amplitude knows whether the export notice and the intrusion are the same event. Amplitude has not said, and Cloudskope is not claiming they are. What the public record does show is that on the day Amplitude says it detected an intruder, its customers were told about an export problem and that no data was lost, and that the next time any of them heard the words "security incident" from Amplitude in public was a month later, the day after one of those customers, Coinbase, announced it on X.

Coinbase's version went up late on Tuesday, October 27, U.S. time. "Coinbase has not had a data breach," its support account wrote. "Amplitude, an analytics vendor, experienced a security incident which impacted a small subset of Coinbase customer contact data, among other Amplitude customers." It said customer funds were not affected and that it was notifying customers and regulators.

The incident is not the story. Analytics vendors get breached; Mixpanel was breached eleven months ago and OpenAI walked away from it. The story is what three documents published within roughly a day of each other say when they are read side by side. Amplitude calls the data "event data." Coinbase calls it "contact data." Amplitude says no end-user information was exposed for any customer other than a small set it has contacted. Coinbase says other Amplitude customers were affected. Amplitude's annual report and its latest quarterly report say it does not believe it has experienced any significant security breach to date. Its board added a director to its Cybersecurity Committee seventeen days after the detection date, and the filing that announced it says nothing about an incident. None of the three documents gives a count, a mechanism or the names of the other customers.

For a bank, a brokerage, a card issuer or a wealth platform, the useful question is not whether Coinbase was breached. It is whether your own product analytics vendor holds the contact details of your customers, and whether you would learn about an incident there from the vendor, or from a stranger on X.

What we verified, and what the first reports got wrong

Cloudskope ran passive checks between 1:56 and 2:15 AM Central on Thursday, October 29. Nothing below involved a login, a credential, or any request beyond what a browser makes when it loads a public page. We did not contact Amplitude, Coinbase or anyone claiming to hold the data.

Amplitude's statement exists, and it is in the trust center, not the newsroom. The text sits at trust.amplitude.com/updates, a customer trust portal run on the Wolfia platform behind Amazon CloudFront. The update content is loaded by JavaScript, so a plain HTTP fetch at 2:00 AM Central returned a page without it. We rendered the page in a headless browser at 2:13 AM Central and captured the full text (SHA-256 2af827ab...dc3d2c). The entry is dated October 28, 2026, filed under "Security," and titled "Customer Update - Recent Security Incident." It carries no time of day. On October 28, Unchained reported that no statement had appeared on Amplitude's blog, and FinanceFeeds reported that its trust center showed no incident notice when checked. Both may have been true when written. Neither is true now.

The same feed carried four security notices in the six days before the incident notice, none mentioning it. On October 22 Amplitude posted that "no first-party Amplitude services are impacted" by the PHP2Shell vulnerabilities, a separate Node.js patching note and a certificate-authority note. On October 26 it posted that its investigation of the PHP flaws had found "no affected customer-facing Amplitude service or evidence of successful exploitation within our systems," and that "No customer action is required at this time." Each of those statements may be accurate about the vulnerability it addresses. They were written by a company that had detected unauthorized access to its internal systems 24 and 28 days earlier.

The status page shows a data-export incident on the detection date. Amplitude's public status page runs on Atlassian Statuspage, which publishes its history as JSON. We pulled it at 2:02 AM Central (SHA-256 02aecce2...7c9d96). Incident 82r0x5x8yjrp, filed against the "Data Export" component, opened at 14:09 Pacific on September 28 and closed at 19:33 Pacific, with four updates, three of them quoted above. Its wording describes availability, not confidentiality: "no data is lost" means exports will catch up, not that nothing left. None of the 50 most recent entries, which go back to April 12, 2026, describes a security incident. That is a fact about the page. Whether the export block was part of containment is a question only Amplitude can answer, and we label any connection as a hypothesis.

No 8-K, from either company. We searched SEC EDGAR full text for Item 1.05 filings from October 25 to 29 at 1:56 AM Central and found one, from a company outside this story. Amplitude's filings since its August 6 quarterly report are one 8-K on October 15 and a series of Forms 3, 4 and 144. Coinbase's two most recent 8-Ks, September 2 and October 2, are executive-change filings under Item 5.02. Neither company has filed anything that mentions this incident.

Who loads Amplitude code on their front door. At 2:02 AM Central we loaded the public homepages of 60 U.S. banks, card issuers, brokerages, fintechs and core-banking vendors in a headless browser and recorded every request to Amplitude's domains, and to the domains used by Statsig, the experimentation platform whose customer contracts and brand Amplitude acquired in May. Fifty-two pages loaded; eight timed out. Five made such requests. Empower's homepage loaded Amplitude's analytics, experiment and engagement scripts from cdn.amplitude.com and called api2.amplitude.com. Acorns loaded cdn.amplitude.com and called api2.amplitude.com. Dave fetched a session-replay configuration from sr-client-cfg.amplitude.com. Affirm called featureassets.org and prodregistryv2.org, which are Statsig endpoints. American Express served a self-hosted copy of the Statsig JavaScript client, in a build that bundles session replay and web analytics, and called Statsig's initialize endpoint. Coinbase's homepage made no Amplitude request. That proves nothing about its app, which is where its customers log in. A homepage test is a floor, not a census: it says nothing about logged-in sessions or mobile apps, and we did not test those because doing so would need accounts. We are not saying any of these five companies was affected. We are saying that Amplitude and the Statsig brand it now operates are in the front-door code of U.S. consumer finance, which is the population that should be asking questions this week.

The 70,000 figure is unverified, and it rhymes with an old number. About three hours before Coinbase posted, an X account called DelCrxpto claimed, citing no source, that contact details for more than 70,000 Coinbase users had been obtained, according to Unchained. An account called 23pds, which describes itself as a partner and chief information security officer at the security firm SlowMist, repeated it about two hours later. Unchained found no SlowMist report. Coinbase has not confirmed any number. The last time Coinbase gave a regulator a count, in its May 2025 insider incident, the Maine attorney general's filing said 69,461 people. We do not know where the new figure came from, and an unsourced number that sits that close to an old public one deserves less weight, not more.

Two errors in the first wave. One write-up, published at 02:57 UTC on October 29, listed "limited transaction data" among the reported exposures. Coinbase's post says no such thing. The phrase matches Coinbase's 2025 disclosure about bribed support contractors, which said limited transaction histories were taken. Separately, one financial news site paraphrased Amplitude as saying the breach affected "less than 0.3% of customer event data." Amplitude's sentence is narrower and different: event data "belonging to less than 0.3% of customer accounts." The first version describes a slice of all data. The second describes a set of whole customers, and for each of those customers, says nothing about how much of their data was involved.

What we could not verify. The time Amplitude posted its notice. The exact time of Coinbase's post. How many Coinbase customers were affected and which fields. When Amplitude told Coinbase. Which other customers were affected. Whether the incident touched Statsig-branded services. Whether the September 28 export block was related. Who did it. Each of these has a person who can answer it, and the questions are listed at the end of this piece.

Amplitude's statement, one sentence at a time

The notice has six substantive sentences, followed by two lines of boilerplate. Each of the six is worth reading for what it contains and what it leaves out.

"We want to provide clarity about a recent security incident at Amplitude." The incident was, by Amplitude's own dating, thirty days old. The notice is dated the day after Coinbase told the public. Its posting time is not shown, so the order on October 28 is unknown, but the timing invites the question whether the clarity was a plan or a response. Amplitude may have told affected customers privately much earlier; the notice says it has "contacted each of these customers directly," without saying when.

"On September 28, 2026, our security team detected, contained, and remediated unauthorized access to a localized portion of Amplitude's internal systems." Three verbs on a single date. Detection, containment and remediation on the same day is possible for a narrow intrusion caught quickly. The sentence does not say when the access began, how long the intruder was inside before September 28, how the access was obtained, or what "localized portion" means: a single server, a support tool, an export service, an employee account. Mixpanel's disclosure last year at least named the method, an SMS phishing campaign. Amplitude names none.

"This is unrelated to recent vulnerabilities identified in PHP (PHP2Shell CVE-2026-109618 and CVE-2026-109619) and Node.js (CVE-2026-111497)." This is the most specific sentence in the notice, and it is a negative. Amplitude tells customers what the cause was not. Amplitude first addressed those flaws in its trust center on October 22, more than three weeks after the detection date, so a sentence ruling them out answers a question customers were asking in late October, not a question about September.

"The incident impacted event data belonging to less than 0.3% of customer accounts." "Event data" is Amplitude's core product: the stream of actions a customer's users take in an app or on a website, each record carrying a user identifier and whatever "user properties" the customer chose to attach. If a customer attaches an email address or phone number as a user property, that becomes part of event data. Coinbase's word for what it lost is "contact data," which is consistent with that reading. The percentage is of "customer accounts," not of customers or records. Amplitude's October 15 press release says it has over 5,200 customers. If accounts and customers were the same unit, 0.3% would be about 15 companies or fewer. They may not be the same unit; one company can hold several accounts, and free accounts may count. Amplitude can say which.

"We have contacted each of these customers directly, and we continue to work with them to assess any impact." The assessment is ongoing a month later. That is normal for an investigation and it is also the reason the customers' own notification clocks matter, which we come to below.

"Our investigation, supported by an independent forensics firm, has confirmed that no end-user information was exposed for any other Amplitude customers." The firm is not named. The sentence is carefully built: it rules out exposure of end-user information for "other" customers, meaning those outside the set already contacted. It does not say whether those other customers' accounts, configurations, API keys or non-end-user data were accessed. Coinbase's post says the incident affected Coinbase "among other Amplitude customers." Those two sentences can both be true only if the "other Amplitude customers" Coinbase refers to are inside Amplitude's 0.3%. That is probably what both companies mean. Neither has said so.

What is absent from all six: a start date, a mechanism, a count of customers, a count of people, the categories of data, whether data was copied out rather than only viewed, the forensics firm, whether law enforcement was told, and whether Statsig-branded services were in scope.

Coinbase's statement, and what "has not had a data breach" means

Coinbase's post opens with a denial: "Coinbase has not had a data breach." It is a sentence about systems, and on that narrow reading it may well be correct. Coinbase says it "found no evidence of unauthorized access to Coinbase systems."

For Coinbase's customers, and for the regulators Coinbase says it is notifying, the distinction is thinner than the sentence suggests. The data belongs to Coinbase's customers. Coinbase chose to send it to Amplitude. In the last sentence of the same post, Coinbase says it is "notifying impacted customers and regulatory agencies in accordance with our legal obligations." Those obligations exist because, legally, the exposure of a financial institution's customer data at its service provider is the institution's incident. The opening line is a communications choice. The closing line is the legal reality.

The post does not say how many customers are affected, which contact fields (email, phone, name, postal address), whether any account identifiers or activity data travelled with them, when Amplitude told Coinbase, or which regulators are being notified. Coinbase reports third-quarter results after the market closes today, October 29, and its quarterly report on Form 10-Q is the next filing where it will describe its risk environment in its own words.

Coinbase has particular reason to be careful with contact data. Its May 2025 8-K, about overseas support contractors bribed to pass customer records to criminals, estimated remediation and reimbursement costs at $180 million to $400 million. The harm in that case flowed from social engineering: criminals who knew who the customers were and how to reach them, posing as Coinbase. A list of verified Coinbase customers with working phone numbers and email addresses is the raw material for that same fraud, whether it leaks from a contractor's screen or from an analytics vendor.

The analytics vendor sits outside every perimeter you test

Product analytics is the least glamorous software in a financial company's stack and one of the most widely connected. A small script or mobile SDK records what a customer does: opened the app, viewed a balance, started a transfer, abandoned an application at step three. Each event is sent to the vendor, tagged with an identifier for that customer, and often with "user properties" the company attaches so that its product team can segment and contact people later. Email address and phone number are among the most common properties, because they make it easy to join analytics data to marketing tools.

That arrangement creates a copy of the customer list, enriched with behavior, at a company whose controls the financial institution does not run and usually cannot see. The bank's penetration test does not touch it. Its data-loss tooling does not watch it. Its SOC 2 report, if it has one, does not cover it. The vendor's own SOC 2 report and ISO certificate do, and Amplitude has both: its trust center says it maintains SOC 2 Type II and ISO 27001, and on September 23, five days before the detection date, it posted that its ISO/IEC 27001 certificate for 2026 to 2027 was available to reviewers. Certification describes a management system. It is not a promise that nobody gets in.

The lesson for a board is that every analytics, session-replay and experimentation vendor in the stack is a place where customer contact data accumulates by default, and few institutions inventory what they send there. Session replay in particular, which records what a customer saw and typed on a page, is now bundled into the same scripts: two U.S. fintech homepages we checked loaded Amplitude's session-replay configuration endpoint, and the Statsig client file served on American Express's homepage carries session replay in its file name.

Mixpanel, eleven months ago, almost exactly

On November 8, 2025, Mixpanel, Amplitude's closest competitor, detected an SMS phishing (smishing) campaign. On November 25 it gave OpenAI the affected dataset. OpenAI disclosed the next day that names, email addresses, approximate locations, operating system and browser details, referring sites and organization or user IDs of its API users were in a dataset the attacker exported, said it had "removed Mixpanel from our production services," and announced "additional and expanded security reviews across our vendor ecosystem." CoinDCX, the Indian crypto exchange, told its users on November 28 that Mixpanel had informed it on November 25; it said the attack "didn't target CoinDCX specifically" and opened a review of Mixpanel's security practices, data minimization and vendor risk processes.

Mixpanel's chief executive, Jen Taylor, wrote a blog post. As TechCrunch's Zack Whittaker reported on December 2, it did not say how many of Mixpanel's roughly 8,000 corporate customers were affected or explicitly confirm that customer data was taken, and Taylor did not answer more than a dozen emailed questions, including whether employee accounts used multi-factor authentication. In mid-December, the pornography site Pornhub blamed Mixpanel for a theft of premium users' data claimed by ShinyHunters. Mixpanel told The Register that it could find "no indication that this data was stolen from Mixpanel during our November 2025 security incident or otherwise," and that the data "was last accessed by a legitimate employee account at Pornhub's parent company in 2023."

Set the two incidents next to each other and the pattern is clear. A product analytics vendor detects unauthorized access. Its customers learn of it on the vendor's schedule. A crypto exchange is among the first to say so publicly. The vendor's own account is brief and names no count. Customers and the vendor then dispute, in public, where a particular dataset came from. Mixpanel took 17 days from detection to handing OpenAI the data. Amplitude's timeline to Coinbase is not public; from detection to public notice it took 30.

Every security and procurement team at a financial institution that used Mixpanel or Amplitude read the Mixpanel story last December. The question it raised was the same one this incident raises: what do we send our analytics vendor, and do we need to? A firm that answered it then has a short week now.

This has been a known risk since at least 2018

In February 2018 Mixpanel disclosed that its "Autotrack" feature had been collecting the values of password fields from its customers' websites. A customer had told it on January 5, 2018. The bug traced to a change in its JavaScript library in March 2017, and a second issue, involving sensitive data that browser plugins placed in form attributes, went back to August 2016. Mixpanel's own description was that "by design, Autotrack should not send the values of hidden and password form fields." Richard Chirgwin reported it in The Register on February 7, 2018.

The 2018 case was a collection failure rather than a breach, and it is a different company. It is relevant for a simpler reason. For eight years it has been public, documented and widely discussed that analytics scripts collect more than their owners intend, and that the data sitting at an analytics vendor is only as limited as the instrumentation that sent it. The remedy has been just as public: do not send direct identifiers to analytics, use an internal pseudonymous ID or a keyed hash, keep the join table at home, and review what each SDK actually transmits rather than what the integration spec says it should.

In 2024 the Snowflake campaign made the same point at a different layer. Attackers using credentials stolen by infostealer malware logged into customer accounts at the data-warehouse vendor, Mandiant counted about 165 potentially exposed organizations, and AT&T later confirmed that call and text records of nearly all its cellular customers were taken from a workspace on a third-party cloud data platform, not from its network. The lesson there was about customer-side credentials and multi-factor authentication. The lesson that carries over is that analytics copies are now a primary target, because they are where joined, cleaned, labelled customer data lives.

What Amplitude told its shareholders in between

Amplitude is a public company, listed on Nasdaq, with a market value of roughly $2.2 billion according to FinanceFeeds. Its public filings set out how it governs cybersecurity and how it describes its own history. Read against the incident timeline, they are a clean example of the attestation gap.

The annual report on Form 10-K, filed February 19, 2026, says in Item 1C that Amplitude's board "established a dedicated Cybersecurity Committee of the Board in July 2024," that the committee "meets at least twice annually with management," and that management updates the committee and board, "where it deems appropriate, regarding any cybersecurity incidents it considers to be significant or potentially significant." It names the chief information security officer, Jack Levy, whose prior roles include chief security officer at Instabase, head of cybersecurity engineering at Bridgewater Associates, and engineering and security leadership roles at Goldman Sachs.

The quarterly report for the period ended June 30, filed August 6, carries a risk factor that says: "We and certain of our vendors are from time to time subject to cyberattacks and security incidents. While we do not believe that we have experienced any significant system failure, accident, or security breach to date, if such an event were to occur..." The same sentence appears in the 10-K. It was accurate, as far as anyone outside the company knows, when filed.

On October 15, seventeen days after the detection date, Amplitude filed an 8-K announcing that its board had appointed Vijaye Raji, the founder of Statsig and now chief technology officer of applications at OpenAI, as a director, and had placed him on the Cybersecurity Committee, at a fee of $4,000 a year for that seat. The accompanying press release is about the Statsig combination. Neither the filing nor the release mentions an incident. There is nothing improper in that: the appointment is plainly connected to the Statsig transaction, and a company is not required to describe in an 8-K an incident it has judged immaterial. It does mean that the one governance filing Amplitude made inside the thirty days concerned the committee that oversees incidents, and was silent about the incident.

Amplitude reports third-quarter results after the close on November 4. Its 10-Q for that quarter will have to decide whether the sentence "we do not believe that we have experienced any significant ... security breach to date" survives unchanged. If it does, that is a judgment that this incident was not significant. Shareholders, and customers reading the filing as a vendor-risk document, will be entitled to read it that way.

Immaterial to the vendor, material to the client

Amplitude has not filed an Item 1.05 8-K, and from its own description that is defensible. It says it detected and contained the access the same day, that fewer than 0.3% of customer accounts were involved, and that a forensics firm found no end-user exposure elsewhere. On those facts the incident is unlikely to move Amplitude's revenue or its share price much; the stock was reported down over 3% in extended trading after the notice.

Now look at it from the other side. For each of the customers inside the 0.3%, the incident is the exposure of its own customers' data, held under its own regulatory obligations, which it must notify on its own clock. Coinbase says it is notifying regulators. A bank, broker-dealer or wealth platform in the same position would be doing the same, on deadlines measured in hours and days, on the strength of whatever Amplitude has told it. The vendor's materiality judgment covers the vendor. It does nothing for the client, and the client cannot outsource the judgment back.

This is the asymmetry Cloudskope has written about in the ConnectWise, Mercadien and PwC incidents this month: an event that is small on the vendor's income statement and large in the client's regulatory file. The analytics layer makes it sharper, because the vendor's customers chose what to send it, and so the client's exposure is partly a record of the client's own data-minimization decisions.

A note on the trading plan

Amplitude's Form 4 filings show sales of company stock reported by its chief executive, Spenser Skates, on behalf of his spouse, on September 30, October 1, October 2, October 23, October 26 and October 28, at weighted average prices that rose from about $14.45 to about $17.53. The filings state that the sales were made under a Rule 10b5-1 trading plan adopted on June 11, 2026, which is 109 days before the incident's detection date. Pre-arranged plans of that kind exist so that sales can continue on a fixed schedule regardless of what insiders later learn. We note the filings because sponsors and boards ask about insider transactions around any undisclosed incident, and the answer here is in the public record: the plan predates the incident. We draw no inference from the sales.

Whose clock is running

When the data sits at a vendor, the notification deadlines that matter belong to the vendor's customers, and most of them start when the customer knows, or is deemed to know. For financial institutions, several of those clocks are short.

New York. Coinbase operates under licenses supervised by the New York State Department of Financial Services. The department's cybersecurity regulation requires a covered entity to notify the superintendent "as promptly as possible but in no event later than 72 hours after determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider." A cybersecurity event at a service provider becomes a reportable incident if, among other things, it "impacts the covered entity and requires the covered entity to notify any government body, self-regulatory agency or any other supervisory body." An exposure that requires customer and regulator notice elsewhere meets that test. The 72 hours run from the institution's determination, which is why the date Amplitude told each customer matters more than the date it told the public.

The FTC's Safeguards Rule. For non-bank financial institutions under the Federal Trade Commission's jurisdiction, the rule defines a notification event as the "acquisition of unencrypted customer information without the authorization of the individual," presumes that unauthorized access to unencrypted customer information is acquisition unless the institution has reliable evidence otherwise, and requires notice to the Commission as soon as possible, and no later than 30 days after discovery, if 500 or more consumers are involved. Discovery is the first day the event is known to the institution, and the institution is deemed to know when it is "known to any person, other than the person committing the breach, who is your employee, officer, or other agent." Whether a vendor that detected the intrusion counts as the institution's agent for that purpose is a question lawyers will argue. A compliance officer should not want to be the test case, and should want the vendor's detection date in writing.

Broker-dealers and advisers. The SEC's amended Regulation S-P, which larger firms have had to comply with since December 2025 and smaller firms since June 2026, requires covered institutions to oversee service providers and to have them give notice within 72 hours of becoming aware of a breach that results in unauthorized access to a customer information system the provider maintains. Customer notice follows as soon as practicable, and no later than 30 days after the institution becomes aware that sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization, unless it determines the information has not been and is not reasonably likely to be used in a way that causes substantial harm or inconvenience.

Banks and credit unions. The 2005 interagency guidance on response programs expects service-provider contracts to require notice to the institution "as soon as possible" after a breach. The 36-hour computer-security incident rule for banks is about operational disruption, not data exposure, and is unlikely to be triggered by an analytics vendor incident. For most banks, the binding clock here is the one in their own contracts and their state's notice law.

Is contact data even covered? State breach laws mostly key on Social Security numbers, account numbers with access codes, and similar elements; an email address and phone number alone usually do not trigger them. The federal financial privacy rules are broader. Under Regulation P, the fact that someone is or has been a customer of a financial institution is itself personally identifiable financial information (12 CFR 1016.3(q)(2)(i)(C)), and so is information collected through an internet cookie (paragraph (q)(2)(i)(F)), which is why a customer contact list from a financial company is nonpublic personal information even when it contains no balances. A list of Coinbase customers is a list of people known to hold crypto, which is exactly the targeting data that drove the fraud in Coinbase's 2025 incident.

The data is ordinary. What it enables is not.

There is no indication that passwords, keys, balances or government ID images were exposed, and Coinbase says funds were not affected. The realistic harm is impersonation. A message that names the right person, reaches the right phone number and refers to a real Coinbase account is how "Coinbase support" scams move customers' crypto to wallets they do not control. Coinbase's guidance, as relayed by Cyber Security News, says its staff will never ask for passwords or verification codes, request remote access, or ask a customer to send funds to an outside address. That guidance is the right message for customers this week, and it is also the reason the contact list has value to the people who wanted it.

For a bank or wealth manager in the same position, the equivalent risk is a vishing call or text that knows the customer's name, phone and institution and asks for a one-time code, an app install or a wire. The fix is the same as it was after Mixpanel: tell customers before the scammers do, and harden the help desk and callback paths that social engineers use.

What Amplitude should have done by now

1. Publish a start date and a mechanism. "Detected, contained, and remediated" on one day says nothing about how long access lasted. Customers need the window to scope their own logs and notices.
2. Say whether data was copied out. "Impacted" is not "exfiltrated." Customers' notification obligations depend on the difference.
3. Give customers the date they were told, in writing. Each affected customer's regulatory clock depends on it.
4. Explain the September 28 status-page notice. If the blocked export APIs were part of containment, say so; if they were unrelated, say that.
5. State whether Statsig-branded services were in scope. The trust center lists separate hosting for them on Google Cloud and Microsoft Azure. Customers of those services include U.S. financial companies.
6. Name the forensics firm and offer the summary report under NDA. A one-sentence "independent firm confirmed" carries little weight without a name.
7. Reconcile with Coinbase in public. Coinbase says other Amplitude customers were affected. Amplitude says no end-user information was exposed for any customer outside the 0.3%. A joint sentence would end the ambiguity.
8. Revisit the risk factor before November 4. If the sentence that Amplitude does not believe it has experienced any significant security breach stays in the next 10-Q, explain why this incident does not qualify.

What boards should be asking this week

1. Which product analytics, session-replay and experimentation vendors do we use, on web and in our mobile apps, including Amplitude, Statsig, Mixpanel and their competitors?
2. What do we send them? Specifically, do we send email addresses, phone numbers, names, account numbers or any field that identifies a customer, or only a pseudonymous ID?
3. Has Amplitude contacted us about this incident, and if not, have we asked in writing whether we are in the affected 0.3% and whether any Statsig-branded service we use was in scope?
4. Do our contracts with these vendors require breach notice within a fixed number of hours, and does that number fit our 72-hour regulatory clocks?
5. If a vendor tells us tomorrow that our customers' contact data was exposed, who decides within 72 hours whether we notify a regulator, and have they rehearsed it?
6. Are our customer-facing fraud warnings and help-desk verification controls ready for an impersonation wave that uses accurate contact data?

For sponsors and acquirers

In diligence, analytics and session-replay vendors rarely appear on the critical-vendor list, because they do not process payments or hold balances. They do hold the customer list and a record of customer behavior. For a fintech, wealth platform or consumer lender target, ask for the SDK and tag inventory for web and mobile, and for a sample of the events and user properties actually transmitted. A target that sends email and phone to three analytics tools has three copies of its customer file outside its control, and three vendors whose incidents become its notification events.

On the vendor side, the representations to check are the ones in Amplitude's own filings: how the board's cybersecurity committee is informed of incidents, how "significant" is defined, and whether a vendor's statement that it has not experienced a significant breach has been tested against its incident register. For a portfolio company that sells software into financial services, this incident is a template for the customer questions it will get, and a reason to have the answers written before they are asked.

What we are not saying

We are not saying the September 28 data-export notice on Amplitude's status page was caused by, or was part of the response to, the intrusion. The two share a date. Amplitude can say whether they share anything else.

We are not saying Empower, Acorns, Dave, Affirm or American Express was affected. We found Amplitude or Statsig code on their public homepages, which shows only that the vendor is part of U.S. consumer finance. None of them has reported an incident, and Amplitude says the affected set is under 0.3% of customer accounts.

We are not saying 70,000 Coinbase customers were affected. That figure is an unsourced claim. Coinbase has not given a count.

We are not saying Coinbase's own systems were breached. Coinbase says they were not, and we have no evidence otherwise.

We are not saying the sales of Amplitude stock described above were improper. They were made under a plan adopted months before the incident.

We are not saying Amplitude was required to file an 8-K. On its own description of the incident, it may reasonably have judged it immaterial.

We are not saying this incident is connected to Mixpanel's 2025 incident or to any threat group. Nobody has attributed it.

If Amplitude or Coinbase would like to correct any of this, this page will be updated the same day.

Our record of these incidents

• Amplitude security incident and Coinbase customer contact data, the verified timeline and running list of unknowns
• PwC Won't Name the Vendor. Everest's Screenshot Does. It Says Staging.
• ConnectWise and the shared credential behind a Microsoft 365 supply-chain attack
• 402,760 People. Nine Banks and Credit Unions. When the auditor is the side door
• Three Breaches, Three Years. EY Still Won't Name the Platform That Failed.
• Elsevier Was the Name on the Page. RELX Was the Pattern.
• What Is Third-Party Risk Management (TPRM)?

Sources

• Amplitude, Trust Center Updates: Customer Update - Recent Security Incident, October 28, 2026 (captured October 29, 2026, 2:13 AM CT); also PHP and Node.js updates, October 22 and 26, 2026
• Amplitude, Status page: "We are actively investigating an incident in our data exports", September 28, 2026
• Amplitude, Inc., Form 8-K and Exhibit 99.1, October 15, 2026
• Amplitude, Inc., Form 10-Q for the quarter ended June 30, 2026, August 6, 2026
• Amplitude, Inc., Form 10-K for fiscal 2025, February 19, 2026
• Amplitude, Inc., Form 4 (Spenser Skates), October 28, 2026, and earlier Forms 4 and 144
• Amplitude, Amplitude to Host Third Quarter 2026 Earnings Webcast on November 4, 2026
• Unchained via Yahoo News, Coinbase Ties Customer Contact Data Exposure to Vendor Amplitude, Says It Was Not Breached, October 28, 2026
• Zoltan Vardai, Cointelegraph, Coinbase Denies Breach, Says Vendor Exposed Customer Data, October 28, 2026
• Decrypt, Coinbase Customer Data Hit in Analytics Vendor Breach, Funds 'Not Impacted', October 28, 2026
• Guru Baran, Cyber Security News, Coinbase Customer Data Exposed Via Analytics Vendor Amplitude Security Incident, October 28, 2026
• Tobi Opeyemi Amure, FinanceFeeds, Coinbase Denies a Data Breach and Puts the Exposure at Analytics Vendor Amplitude, October 28, 2026
• Bitcoin.com News, Coinbase Denies Platform Intrusion as Vendor Data Leak Emerges, October 28, 2026
• GuruFocus, Amplitude (AMPL) Addresses Security Breach Impacting Customer Data, October 28, 2026
• Occasional Digest, Amplitude shares move following security update; Coinbase clarifies no data breach, October 29, 2026
• shattered.io, Coinbase Amplitude Breach [2026], October 29, 2026
• OpenAI, Mixpanel incident, November 26, 2025
• Zack Whittaker, TechCrunch, A data breach at analytics giant Mixpanel leaves a lot of open questions, December 2, 2025
• Jessica Lyons, The Register, Analytics provider: We didn't expose smut site data to crims, December 16, 2025
• Business Standard, CoinDCX says some of its user data exposed due to security breach, November 28, 2025
• Pierluigi Paganini, Security Affairs, OpenAI data may have been exposed after a cyberattack on analytics firm Mixpanel, November 27, 2025
• Richard Chirgwin, The Register, Web analytics outfit Mixpanel slurped surfers' passwords, February 7, 2018
• Mandiant (Google Cloud), UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion, June 10, 2024
• New York State Department of Financial Services, 23 NYCRR Part 500, sections 500.1(g) and 500.17(a)
• Federal Trade Commission, Standards for Safeguarding Customer Information, 16 CFR Part 314, sections 314.2(m) and 314.4(j)
• SEC, SEC Adopts Amendments to Regulation S-P to Enhance Protection of Customer Information, press release 2024-58, May 16, 2024
• Consumer Financial Protection Bureau, Regulation P, 12 CFR 1016.3
• Coinbase Global, Inc., Form 8-K, May 15, 2025
• TechTarget, AT&T breach affects 'nearly all' customers' call, text records, July 2024
• Coinbase, Coinbase Announces Date of Third Quarter 2026 Financial Results