Telenet-klanten zagen door fout gegevens van andere klanten in MyTelenet-portal

Telenet-klanten konden maandag door een 'technisch probleem' de gegevens van andere klanten zien in het MyTelenet-portaal. De impact was volgens de provider 'zeer beperkt', onder meer doordat het volgens de provider slechts twintig minuten duurde.

Klanten die maandag aan het begin van de middag inlogden op MyTelenet, konden hier de gegevens van andere klanten zien. Daarover verschenen ook meldingen op het Tweakers-forum. De provider meldt aan onder meer HLN dat hier gegevens zoals namen, telefoonnummers en adressen te zien waren. Rekeningnummers of andere financiële gegevens waren niet zichtbaar.

De storing duurde zo'n twintig minuten, claimt Telenet, en was rond 13.30 uur opgelost. Klanten die tussen 13.00 uur en 13.30 uur waren ingelogd, zagen na 13.30 uur mogelijk nog wel de gegevens van andere klanten. Gebruikers die na 13.30 uur inlogden, zagen alleen hun eigen gegevens.

Het is niet duidelijk wat het technische probleem was en waardoor dit kon ontstaan. Telenet zegt het probleem intern verder te onderzoeken en heeft het ook gemeld aan de Gegevensbeschermingsautoriteit.

Reacties (24)

[Vink Mooi]

"Zeer beperkte impact" omdat het maar twintig minuten duurde, maar dat is niet hoe je een datalek moet beoordelen. De duur is irrelevant. Wat telt is: hoeveel unieke gebruikers waren in dat venster ingelogd, hoeveel profielen hebben zij gezien, en zijn die gegevens ergens opgeslagen of doorgestuurd? Dat weet Telenet zelf waarschijnlijk ook niet, want anders hadden ze het wel vermeld.

Wat hier eigenlijk staat is: Door een technisch probleem is de authenticatielaag even volledig omgevallen. Jouw sessie wees opeens naar iemand anders z'n account. Dat is geen randgeval of edge case,dat lijkt een fundamentele fout in sessiebeheer of caching, het soort fout dat in elke security-opleiding op dag één wordt behandeld.

En dan de mededeling aan de Gegevensbeschermingsautoriteit: dat is wettelijk verplicht binnen 72 uur bij een inbreuk met risico voor betrokkenen, dus dat is geen vrijwillige transparantie maar gewoon noodzakelijk. Complimenten zijn daarvoor niet op zijn plaats.

Als Telenet-klant zou ik willen weten: wat was de exacte oorzaak, hoeveel klanten zijn getroffen, en wat wordt er structureel aangepast? "We onderzoeken het intern verder" is geen antwoord.

[adje123]

We onderzoeken het intern verder

Tuurlijk is dat wel een antwoord. Je moet toch eerst onderzoek doen voordat je conclusies kan trekken/delen?

[indigo79]

Wat hier eigenlijk staat is: Door een technisch probleem is de authenticatielaag even volledig omgevallen. Jouw sessie wees opeens naar iemand anders z'n account. Dat is geen randgeval of edge case,dat lijkt een fundamentele fout in sessiebeheer of caching, het soort fout dat in elke security-opleiding op dag één wordt behandeld.

En nadat dat in je security-opleiding op dag één behandeld is, sluipt er uiteraard ook nooit meer een bug in de code die je schrijft. Memory-management, buffer overflows, input-verificatie... worden ook al tientallen jaren behandeld in elke serieuze IT-opleiding en toch duiken er elke dag dergelijke fouten op in veelgebruikte software die door professionals geschreven is.

Mensen maken fouten en sommige fouten sluipen door de mazen van het net. Het is belangrijker of er een serieuze softwarevalidatie is en wat we uit deze fout leren. Ik heb minder problemen met een serieuze fout die om een of andere reden toch door een in principe vrij goed validatiesysteem sluipt dan een kleine fout die in productie sluipt omdat er eigenlijk helemaal niets gevalideerd wordt. Die eerste zal sowieso zeldzamer zijn, die tweede is een tikkende tijdbom die deze keer meeviel.

[Kastermaster]

Eens. Ik begin een beetje moe te worden van dit soort verhalen, waarbij standaard gedownplayed wordt wat de daadwerkelijke risico's van dit soort fouten zijn. Aan de ene kant worden wij (eindgebruikers) bestookt met campagnes om veilig met onze data om te gaan. Aan de andere kant hebben de bedrijven die onze data in beheer hebben lak aan onze privacy en security. En als het mis gaat, krijgt de klant de problemen op zijn/haar bord.

Ik zou heel graag zeggen: doe geen zaken meer met dit soort bedrijven. Maar je hebt niet echt een keuze, zo massaal en wijdverspreid zijn de lekken. Er blijft dan bijna geen bedrijf meer over waarmee je zaken kunt doen.

Het wordt dus tijd voor een andere manier van databeveiliging, waarbij mijn gevoelige data niet meer in beheer van bedrijven komen. Ik heb daar wel een (vaag) idee over, maar weet niet hoe haalbaar en handig dit is: een soort centrale authenticatie-database (vergelijkbaar mer iDin). Eén instantie, met de volledige verantwoordelijkheid over jouw privacygevoelige data. Bij een lek is deze instantie verantwoordelijk voor het herstellen van schade, en het aanspreekpunt voor de user. Ideaal? Nee. Maar wie een beter idee heeft, is welkom.

[Blokker_1999]

Het is ook geen beoordeling van het datalek, het is een PR medewerker die de pers tewoord staat. En ja, ik verwacht dat doordat het probleem slechts 20 minuten bestond, dat het ook maar een klein deel van de klanten betrof. Maar of het nu 1 klant is of allemaal maakt uiteindelijk niet uit. Je hebt een datalek gehad en moet nu dezelfde procedure volgen.

De analyse van wie wat heeft kunnen zien zal daarna ook pas op gang zijn gekomen. Stap 1 is het lek dichten. De gevolgen onderzoek je pas later. En dat kan wel enige tijd in beslag nemen. Dus neen, op het moment dat de pers aan je deur komt kloppen kan je niet veel zinnigs zeggen.

En ik begrijp ook niet hoe jij er van maakt dat de authenticatielaag volledig is omgevallen. Want dat zal hier ook niet gebeurd zijn. Het is niet alsof iedereen ineens alle data van alle gebruikers kon inzien. Dat is pas authenticatie die omvalt. Dit is gelukkig minder ernstig, maar nog altijd ernstig uiteraard.

En als private onderneming zijn zij helemaal niet verplicht om klanten in te lichten over de kernoorzaak van het probleem of welke structurele veranderingen zij gaan aanbrengen. Leuk dat jij dat wenst te weten, maar wat ga je verder met die informatie doen? Wil je meer transparantie, ga dan op zoek naar bedrijven die beloven daar open over te zijn.

[amigob2]

Kan iemand mij uit leggen hoe dat kan.
Op wat voor manier kan software een fout maken om vervolgens de gegevens van een ander persoon te krijgen ?
Ik kan niet iets simples bedenken.

[cadsite]

Spoider in 'Telenet-klanten zagen door fout gegevens van andere klanten in MyTelenet-portal'

[barbarbar]

Waarschijnlijk een foutje in de cache config. De website wordt voor een deel door cache afgehandeld zodat alles sneller laad, dan hoeft niet alles via de webserver. Stel nou dat de pagina/url van de klantgegevens ook per ongeluk uit die cache komt, dan krijg je gegevens van iemand anders te zien.

[bzzzt]

Wat je ook voor oplossing gebruikt, een ingelogde gebruiker is simpelweg een 'id' wat op een bepaalde plek bijgehouden moet worden.
In web services is het vrij gangbaar om niet voor ieder verzoek een nieuw proces op te starten maar bestaande processen of threads te hergebruiken. Als een verzoek niet correct afgesloten wordt kan dat leiden tot het 'lekken' van een gebruikers id naar een andere context waardoor een verzoek uitgevoerd wordt voor de verkeerde gebruiker. Moderne frameworks en programmeertalen proberen dat op alle mogelijke manieren te voorkomen, maar er draait natuurlijk ook nogal wat software die niet gisteren geschreven is.

[skoozie]

Dit was laatst ook al bij bol.com
Zit er ergens een bug in de back-end software die beide bedrijven gebruiken?

en volgens @jrswgtr in dat nieuws bericht: Het zou ook kunnen dat er Varnish cache gebruikt wordt. Normaal gesproken worden persoonlijke pagina's daarvan uitgesloten maar een verkeerde aanpassing van de policy (vcl) er toch gecachede pagina's geserveerd worden.

[Reactie gewijzigd door skoozie op 17 maart 2026 09:21]

[GenomDalar1983]

Ik zie inderdaad een patroon aan "hacks" of "fouten" die de laatste tijd plaatsvinden

[Trexpaxs]

Ik gok dat ze bij bol en telenet zijn begonnen met vibe-coden met Ai
Maar dat is pure speculatie

[keejoz]

Iedereen doet altijd maar alsof devs geen slopcode schreven voor het AI tijdperk.

[Spoider]

Dit ruikt als een typisch geval van cache misconfiguratie. Ik heb dit in de praktijk gezien bij gevallen waarbij de cache entry bedoeld is voor een enkele gebruiker, maar verkeerd ingesteld is, waardoor het bij meerdere (of alle) gebruikers toegepast wordt. Dit kan gebeuren als de ontwikkelaar niet begrijpt hoe de cache werkt.

Gebruiker 1 bezoekt pagina -> pagina/data wordt in de cache gestopt -> gebruiker 2 bezoekt pagina -> pagina/data van gebruiker 1 wordt uit de cache gehaald en aan gebruiker 2 getoond.

[L00_Cyph3r]

Ik moet bij dit soort lekken ook altijd terugdenken aan de beruchte Steam cache datalek. Gelukkig was Valve wel open over wat het probleem was, Cloudflare is ook altijd open over het technische aspect van een lek/storing.

Steam artikel uit 2015: nieuws: Valve: 34.000 Steam-gebruikers getroffen door cachingproblemen

[Sebast1aan]

Telenet's admin software is al jaren zooo slecht, het is echt ongelofelijk.

[Sanghelios]

Wat een zootje daar.
Ze slagen er daar al jaren niet in hun software in orde te krijgen.
Is ook een reden dat ik er vertrokken ben. Verbruik klopte niet en ondanks dat ik uren had gestoken om het deftig uit te leggen/werken geraakte het maar niet in orde.
Gelukkig zijn ze wel erg goed in het verhogen van prijzen. Dat gaat meestal wel erg vlot.

[Tosti55]

Het lijkt wel of er meer bedrijven zijn tegenwoordig waar het niet op orde is i.p.v. andersom.
Heel spijtig dit allemaal en erg vervelend.

[Faloude]

Zie hier de Belgische Odido

[R_Zwart]

Totaal onvergelijkbaar. Bij Odido was er sprake van een fundamentele procesfout. Hier een softwarebug.

[adje123]

Ik zou willen dat dit ook bij Odido was gebeurd, zoals bij Telenet.

[Wim Cossement]

AI foutje? Arrays beginnen bij [0] maar de AI vond dit niet logisch en koos voor 1...

[jpsch]

Les 1 AI

Een verkeerd antwoord is beter dan geen antwoord.

[SoLt3c]

Lijkt mij een goed excuus om te tarieven weer te verhogen voor de "veiligheid".Uiteraard na de komende verhogingen eind april