Klaviyo Signup Form Leaked Passwords to Ad Trackers

A signup form rendered on a screen — illustrating the page whose fields were read by third-party marketing trackers. Photo by Mohamed_hassan on Pixabay

CYBERSECURITY · 11 Aug 2026 —

BOSTON, 11 AUG 2026 — For something close to two years, the passwords people typed into a Klaviyo signup form were sent to Facebook, Google, Microsoft, LinkedIn, HubSpot and X.

Not the hashes. What was typed. The marketing trackers embedded on the page were reading the form fields, and they were doing it because that is what trackers do.

What happened

Feb 2024 – Nov 2025The window the misconfiguration is known to have been active. Possibly longer.

What went outEmail addresses and passwords, company names, website addresses, phone numbers.

Who received itTrackers belonging to Facebook, Google, HubSpot, Microsoft, LinkedIn and X.

"Fewer than 200"Klaviyo's estimate — based on its "readily available active logs", over a 21-month window.

Klaviyo is a marketing automation platform, so its own signup page carried the analytics pixels a marketing company would carry. Those pixels are JavaScript running in the page with access to the document, and a misconfiguration meant the values entered into the signup form were included in what they collected and transmitted.

The security researcher Sam Jadali, co-founder of Melurna, found it, and shared the findings ahead of a talk at DEF CON. Klaviyo has described it as an application configuration issue, says it has notified the individuals it knows to be affected, and fixed it. It did not disclose the incident publicly and declined to provide copies of the notifications.

Worth being precise about what this is not. No attacker breached Klaviyo's database. This is browser-side leakage: data flowing out of a page to parties who were invited onto it, which is a different failure with a different fix and, for the people affected, an identical consequence.

The estimate is the part to read twice

"Fewer than 200 people, based on our readily available active logs" is a carefully bounded sentence, and the boundary is doing the work.

The misconfiguration is known to have been live from February 2024 to November 2025, and possibly longer. For the figure to describe that period, the logs would need to cover it. Klaviyo would not say how long it retains them.

Read that carefully: fewer than 200 affected people appear in the logs Klaviyo still holds. That is not the same as saying fewer than 200 people were affected, unless the company's log retention exceeds 21 months. Most companies retain web logs for 30 to 90 days.

The number is not necessarily wrong, just unsubstantiated. The claim is framed in a way that cannot be verified.

The structural problem is not a bug

While the immediate cause was a configuration error, the underlying problem is architectural — and common to almost every commercial website.

A third-party tracker is JavaScript from another company, loaded into your page, running with the same access to the document as your own code. It can read the DOM. It can, if configured to, read what is typed into inputs. The entire category exists to observe user behaviour, and form interaction is user behaviour.

The line between observing that a user filled in a form and collecting what they typed is just a configuration setting, not a technical boundary enforced by the browser. It is not a boundary enforced by the browser, and on most sites nobody has audited which side of it each tracker sits on.

If you run a site with a signup form, the question is not whether you have made Klaviyo's specific mistake. It is whether you know what your own trackers are collecting. For most organizations, the answer is no one has looked.

Why passwords make it worse than it sounds

Marketing data leaking to marketing companies is an ordinary privacy failure. Passwords are a different order of problem, because of what people do with them.

A password typed into a signup form is very often that person's password elsewhere. The password has left the user's control entirely. It now sits in the logs and data pipelines of six large companies that never asked for it and are not expecting it. They have no process for handling it; nothing in their systems flags an incoming analytics field as a credential.

The risk is not that these companies will deliberately misuse the password. It is that a credential now exists in half a dozen new places, none of which protects it as one. Neither the user nor the platform can get it back.

Not disclosing it publicly is a choice

Klaviyo notified the people it identified and did not announce the incident. On a strict reading of most breach-notification regimes, notifying known affected individuals may well be sufficient, particularly with a count under 200.

The difficulty is that the count is the thing in question. A disclosure regime that lets a company define the incident from undescribed logs — an incident the public only knows about thanks to a researcher — is measuring the wrong thing.

The people best placed to check if they were affected are the users, but they cannot act on information they do not have. Anyone who created a Klaviyo account between early 2024 and late 2025 has a specific, actionable reason to change that password anywhere they reused it, and most of them will never hear about it.

What to do about it

If you created a Klaviyo account in that window, change the password there and anywhere you used the same one. That advice does not depend on whether you are in the fewer-than-200.

If you run a site with a signup or login form, look at what your tag manager is configured to capture, specifically on pages with credential fields. The common defaults on several analytics products include form-field capture, and the safe configuration is to exclude those pages entirely rather than to trust a field-level exclusion list.

What to watch

Whether any regulator asks about the log-retention question. It determines whether "fewer than 200" is a meaningful number.

Whether the recipients say anything. Six large companies have credentials in their analytics pipelines that they did not solicit, and none has an obvious mechanism to find and purge them.

And whether this turns out to be one company's error. The architecture that allowed this is common. The only thing unusual here is that a researcher happened to look.

Priya Nair's Verdict AI Governance & Trust

The sentence I cannot get past is the estimate. Fewer than 200 people, based on readily available active logs, describing a window of at least 21 months, from a company that would not say how long it keeps logs. Every one of those qualifiers is load-bearing, and together they produce a number that sounds like a finding and is actually a description of what the company can still see. That is not necessarily bad faith; it may be the only honest thing they can say. It is exactly why a disclosure threshold expressed as a count is a weak instrument. What deserves more attention than Klaviyo is the shape of the failure. Third-party marketing scripts run inside your page with full access to the document, and whether they capture form fields is a configuration setting rather than a boundary anything enforces. Most organisations have never audited it, and the ones that have usually found something. If you take one action from this story, do not change your Klaviyo password and stop; go and look at what your own tag manager collects on the page where your users type theirs.

Sources & cross-checks

Primary: TechCrunch, 10 August 2026, by Zack Whittaker — for the misconfiguration of Klaviyo's signup web form causing customer data to be shared with third-party trackers embedded on the site; the data involved, including email addresses and passwords, company names, website addresses and phone numbers; the recipients including Facebook, Google, HubSpot, Microsoft, LinkedIn and X; the window from February 2024 through November 2025 and the possibility that it ran longer; the discovery by security researcher Sam Jadali, co-founder of Melurna; Klaviyo describing it as an application configuration issue and stating that fewer than 200 people were affected based on its readily available active logs; its refusal to disclose log retention periods; its statement that it notified the known individuals affected; and its decision not to disclose the incident publicly or to provide copies of the notifications.
Corroborated: TechRepublic, August 2026, independently for the misconfigured sign-up form exposing passwords to advertising trackers, the window from February 2024 to November 2025, and Klaviyo's fewer-than-200 estimate bounded by its available logs. Both accounts note the researcher shared the findings ahead of a DEF CON talk, and that this was browser-side exposure rather than an intrusion into Klaviyo's systems.
What could not be established: ⚠️ The number of people affected is not established and this report does not treat it as such. Klaviyo's figure is bounded by logs whose retention period it declined to state, over a window of at least 21 months. ⚠️ We could not establish whether the passwords were transmitted in clear text, exactly which fields each tracker captured, whether any recipient stored or processed them, whether any has been asked to delete them, when the misconfiguration was fixed, when it actually began, or whether any regulator has been notified. ⚠️ We did not see the researcher's technical write-up in full and sought no comment from Klaviyo or from any of the named recipients.
Method and limits: Compiled 11 August 2026 from a single detailed secondary account of the researcher's findings and the company's responses. The parsing of the "fewer than 200" estimate against the length of the exposure window and the undisclosed retention period, the argument that third-party script access to form fields is a configuration rather than an enforced boundary, the point that a leaked credential is dangerous because of reuse rather than because of any recipient's intent, and the criticism of count-based disclosure thresholds are RECATOOLS analysis rather than claims made by any source. The remediation advice is general security practice.

Tags: #Cybersecurity #Data-Breach #Advertising #Privacy

Cyber Team

Cybersecurity Desk

Cyber Team is RECATOOLS’ cybersecurity desk, covering vulnerabilities, breaches, threat intelligence, and practical security guidance.

View author profile → · Editorial policy

About this byline Cyber Team is a specialist RECATOOLS editorial desk focused on cybersecurity coverage. Articles are produced and reviewed under RECATOOLS editorial supervision.

Corrections policy