Klaviyo stuurde wachtwoorden van nieuwe klanten naar 31 externe trackers

Klaviyo’s aanmeldformulier stuurde het wachtwoord, e-mailadres, telefoonnummer, bedrijfsnaam en website van nieuwe klanten door naar 31 externe hostnamen, blijkt uit onderzoek van beveiligingsbedrijf Melurna dat vandaag verscheen.

Heb je een Klaviyo-account, dan zitten daar twee verschillende problemen in. Werd dat account aangemaakt tussen 26 februari 2024 en 10 november 2025, dan is dat precies het venster waarin het lekkende formulier aantoonbaar online stond, en kan het wachtwoord van je marketingaccount in de querystrings en serverlogs van advertentienetwerken zijn beland. Het tweede probleem raakt niet je eigen account maar je klantenbestand: het openen van een contactprofiel in Klaviyo stuurde de naam en het e-mailadres van jouw klant door naar Sift, Gainsight PX en Google Analytics. Voor die gegevens ben jij onder de AVG de verwerkingsverantwoordelijke en is Klaviyo de verwerker.

Eén ontbrekend attribuut in de HTML

Het formulier op klaviyo.com/sign-up stond in de opgenomen sessie in de pagina als <form action="#" id="form--signup">. Er ontbrak een method-attribuut. Een formulier zonder method valt in HTML terug op GET, en een GET-verzending zet elk benoemd veld in de URL. Hier waren dat velden met de namen email, password1, company, company_website en phone.

Normaal vangt JavaScript de verzending af en stuurt het de gegevens netjes in de body van een POST. Het probleem is de terugval. Gebeurt dat afvangen net niet, bij een trage verbinding, een browserextensie of een testtool, dan navigeert de browser naar de eigen pagina met het wachtwoord in de adresbalk. Elke tracker op die pagina leest die URL vervolgens mee, want dat is precies waarvoor pixels zijn gebouwd.

Melurna nam de sessie op 18 september 2025 op met Burp Suite en vond het testwachtwoord terug in verkeer naar 31 externe hostnamen, waaronder diensten van Meta, Google, Microsoft, LinkedIn, HubSpot, X, Spotify, 6sense en Heap Analytics. Vier van die hostnamen gaven de wachtwoordwaarde terug in hun eigen response, wat bevestigt dat ze hem hebben ontvangen en verwerkt.

Dit is geen exotisch geval. In de top 100.000 websites telde het bureau 7.874 formulieren met inlog- of persoonsgegevens zonder expliciet method-attribuut, waarvan 3.077 met een wachtwoordveld. Dat is een meting van riskante opmaak, niet van bewezen lekken: draait het JavaScript zoals bedoeld, dan gaat het goed.

Klaviyo houdt het klein en meldde niets publiek

Klaviyo bevestigde tegenover TechCrunch dat de fout is verholpen. Woordvoerder Danielle Zanatta noemt het een application configuration issue en houdt het op minder dan 200 bekende getroffenen, gebaseerd op de direct beschikbare actieve logs. Hoe lang het bedrijf logs bewaart en hoe lang de fout precies live stond, wilde het niet zeggen. Klaviyo zegt de bekende betrokkenen te hebben geïnformeerd, maar wilde die berichten niet laten zien. Een publieke melding kwam er niet.

Daar staat de meting van de onderzoekers tegenover. Het kwetsbare formulier was in Common Crawl terug te zien van 26 februari 2024 tot 10 november 2025, en dat noemen ze zelf een ondergrens. Ergens tussen 10 november en 16 december 2025 verving Klaviyo het door een formulier in meerdere stappen, waarmee het gedrag verdween. Melurna meldde de bevinding op 19 juni 2026, Klaviyo bevestigde op 1 juli dat die klopte en op 7 augustus dat alles was verholpen.

Je klantenbestand ging dezelfde kant op

De tweede bevinding is de vervelendste voor een webshop, omdat er geen haperend JavaScript aan te pas komt. Op een volledig werkende pagina schreef de Klaviyo-interface de gegevens van een contactpersoon naar twee plekken die vrijwel elke analytics- en monitoringtool standaard uitleest: de titel van het browsertabblad en de URL. Op het profieloverzicht werd de tabtitel het e-mailadres van de contactpersoon, gevolgd door " | Klaviyo". Op de subtabbladen werden dat de voor- en achternaam. De URL droeg het profiel-ID.

Het gevolg: bij het aanmaken van een profiel en bij elke navigatie erbinnen gingen naam, e-mailadres of profiel-ID mee naar Sift (via hexagon-analytics.com), Gainsight PX, Google Analytics, Sentry en Statsig. Gainsight PX kreeg daarbovenop complete DOM-snapshots van de gerenderde pagina, inclusief lijstweergaven met meerdere contacten. Google Analytics kreeg het e-mailadres in de standaard GA4-parameters voor documenttitel en locatie, terwijl Googles eigen voorwaarden het doorsturen van persoonsgegevens verbieden.

Dat maakt het een AVG-vraagstuk van de winkelier, niet van het platform. Sift, Gainsight en Google Analytics ontbreken op Klaviyo’s eigen subverwerkerslijst, die op 10 april 2026 is bijgewerkt en 27 partijen noemt; Sentry en Statsig staan er wel op. Drie van die ontvangers kregen bovendien de bedrijfsnaam van het testaccount mee en twee ook het inlogadres van de gebruiker, zodat een leverancier een contactpersoon kan koppelen aan het account dat hem bekeek. Het patroon is bekend: ook vier advertentie-SDK’s in Android-apps sturen de locatie van gebruikers standaard door zodra de app die toestemming heeft, waarbij de opdrachtgever van de app verwerkingsverantwoordelijke blijft.

De controle op je eigen formulieren

Melurna wijst twee gewoontes aan die alle drie de bevindingen hadden voorkomen. Ze gelden voor elke site met een formulier, niet alleen voor Klaviyo.

• Zet expliciet method="post" op elk formulier met een wachtwoord of persoonsgegevens. Zonder dat attribuut hangt de veilige route af van JavaScript dat op het juiste moment draait. Met method="post" belanden de velden ook bij een native terugval in de body en niet in de URL. Vermijd daarbij action="#", want dat stuurt de ingevulde waarden naar de adresbalk van dezelfde pagina.
• Zet nooit persoonsgegevens of inloggegevens in een paginatitel of een URL. Analytics-, sessie-opname- en foutmonitoringscripts lezen die twee standaard uit, en browserextensies kunnen dat ook. Een tabtitel als "Contact | Klaviyo" en een pad zonder de waarde erin halen de gegevens uit het kanaal voordat iemand ze kan verzamelen.

Praktisch komt dat neer op drie dingen. Open je eigen aanmeld- en inlogpagina en controleer in de broncode of het formulier method="post" heeft. Loop in je tag manager na welke pixels op die pagina’s staan en wat ze meesturen. En wie tussen februari 2024 en november 2025 een Klaviyo-account aanmaakte, verandert daar het wachtwoord en zet tweestapsverificatie aan, zeker als datzelfde wachtwoord elders terugkomt.

Hier is niets gehackt. Het formulier deed exact wat de HTML-standaard voorschrijft en de pixels deden exact waarvoor ze zijn ingebouwd. Dezelfde mechaniek maakte eerder van een tracker in de betaalomgeving van de Belastingdienst een datalekmelding bij de Autoriteit Persoonsgegevens, niet omdat er was ingebroken maar omdat de gegevens langs de voordeur naar buiten liepen. Klaviyo bedient naar eigen zeggen 205.000 betalende klanten, en voor al die webshops geldt dat niet de kwaliteit van het slot bepaalt waar hun klantgegevens terechtkomen, maar wat hun pagina’s aan hun eigen trackers doorgeven. Zonder publieke melding was er voor de winkeliers die het aangaat ook geen moment waarop ze dat konden nagaan.